Snyk Agent Scan

Evidence shows: default interactive scans require explicit user consent (y/n) for each stdio MCP server, showing command and arguments; provides --dangerously-run-mcp-servers flag but explicitly warns to use only in trusted environments; documentation states scanning executes commands in MCP configs and recommends sandboxing; data flow transparency: documentation states skills, agent applications, tool names, and descriptions are shared with Snyk, but claims no usage data is stored or logged; sensitive data handling: detects hardcoded secrets and credential handling issues, but does not explain how discovered sensitive data is handled; dependency security: pyproject.toml pins rich version and overrides several transitive dependencies for security fixes, but no evidence of dependency vulnerability scanning; external effects: scanning executes MCP server commands, potentially causing external effects, but controlled via user consent and warnings; rollback: no rollback or undo mechanism provided; source attribution: publisher unverified, but documentation provides GPG signature verification steps. Deductions: rollback mechanism absent, data flow transparency partial (no API call details), sensitive data handling partial (no post-scan data disposition).

Evidence shows: README and documentation are consistent; CLI parameters and commands clearly defined; dependencies listed in pyproject.toml, but no guarantee of dependency availability; failure messages: documentation mentions error handling (e.g., user_declined error), but no detailed failure message examples. Deductions: dependency availability unverified, failure message details insufficient.

Evidence shows: clearly lists supported agents and OS matrix, and detection scope; capability boundaries: documentation states which agents and scopes are scanned and which are not; trigger precision: CLI parameters allow specifying config files, directories, or skills, and provide options like --no-skills; environment fit: supports multiple OS and Python versions, provides uvx and binary run methods. Deductions: capability boundaries not fully detailed for all agents, trigger precision not exhaustive.

Evidence shows: clear information architecture with README, docs directory, CHANGELOG; detailed install notes including uvx and binary methods; naming stability: CLI output marked experimental and subject to change; examples and FAQ: multiple examples and demo provided; known limitations: documentation mentions specific limitations for some agents (e.g., Amp project-scope skills not scanned); license: Apache-2.0, LICENSE file present; versioning and changelog: CHANGELOG.md exists, version in pyproject.toml; maintenance responsibility: documentation states no external contributions accepted, but issues welcome. Deductions: naming stability deducted due to experimental output, maintenance responsibility lacks clear update path.

Evidence shows: output usability: provides JSON and rich text output, documentation explains JSON schema; marginal value: provides security scanning functionality, detects multiple risks, has technical report; cost-benefit: requires Snyk API token, may involve cost, but no pricing information provided. Deductions: cost-benefit lacks specific cost information, output usability lacks output examples.

Evidence shows: claim traceability: README and documentation describe features in detail, but no specific test results; cross-source corroboration: provides technical report and blog links, but no independent verification; fact-inference separation: documentation distinguishes feature descriptions and warnings, but does not explicitly separate facts and inferences. Deductions: claim traceability lacks test evidence, cross-source corroboration lacks independent verification.