TL;DR
- MCP security covers the risks introduced when AI coding agents connect to external tools through the Model Context Protocol: what those tools can execute, what credentials they hold, and what data leaves the developer’s machine.
- The core problem is that MCP servers are configured locally and run as the developer. An agent config file is executable configuration, and almost nobody reviews it the way they review a dependency.
- Scanning an MCP config can itself be dangerous. Discovering what a server does often means starting it, which means running someone else’s command on your machine.
- We assessed Snyk’s agent-scan, a scanner built for exactly this problem, using it as a worked example of the risks. It scored 75/100, the highest of the codebases we have run through this process.
- The security finding worth studying: guard hook installation writes PUSH_KEY and TENANT_ID directly into shell command strings in client hook config. Credentials at rest, in files, on every machine.
- Four controls matter before enterprise deployment: inventory what agents connect to, contain what execution can reach, bound credential lifetime, and redact what leaves the machine.
Developer laptops now run software that nobody procured. An engineer installs an AI coding agent, adds three MCP servers from a README, and their machine begins executing third-party code with their credentials, their filesystem access, and their VPN session. No ticket, no review, no inventory entry.
This is not a hypothetical risk. It is the default configuration of most AI coding setups today. This post covers what MCP actually exposes, why scanning for it is harder than scanning dependencies, and what controls to require before approving agents for enterprise use, grounded in a real assessment of a scanner built for the job.
Understanding what MCP exposes on a developer machine
The Model Context Protocol is a standard that lets AI agents connect to external tools and data sources. An agent that can read your filesystem, query your database, or call your internal API does so through MCP servers, each of which is a process the agent starts and communicates with.
Three properties of that design create the security surface:
- Servers run locally as the developer: An MCP server started by an agent inherits the developer’s filesystem access, environment variables, network position, and any credentials in their shell.
- Configuration is executable: An MCP config entry contains a command and arguments. Adding a server means adding a command your agent will run, making the config files closer to shell scripts than to settings files.
- Discovery requires execution: An MCP server’s capabilities are not declared statically. Finding out what tools a server exposes generally means starting it and asking.
An MCP config entry is a command your agent will run. The server it starts inherits everything the developer has.
Alongside MCP servers, agents load skills: packaged instruction sets, often with accompanying scripts, that shape agent behavior. A malicious or compromised skill can direct an agent toward actions the developer never intended.
| Component | What it is | Risk when untrusted |
| MCP server | Local process the agent starts and queries | Runs arbitrary commands with developer privileges |
| Server config | Command, args, and env in a client config file | Executable content added without review |
| Skill | Instruction package shaping agent behavior | Redirects agent toward unintended actions |
| Agent client | The coding tool itself | Holds credentials, session tokens, repository access |
The comparison to dependency management is instructive but incomplete. An npm package runs at build time and is at least visible in a lockfile a reviewer can audit. An MCP server runs whenever the agent decides it needs one, from a config file in the developer’s home directory that appears in no inventory.
Why scanning agent configurations is harder than dependency scanning
Security teams reasonably ask why this cannot be handled by existing tooling. Three properties defeat the standard approach.
There is no manifest
Dependency scanning works because package-lock.json declares exactly what is installed. Agent configurations are scattered across client-specific paths, in different formats per client, with no central registry. Finding them requires knowing where each client stores its config.
Static analysis stops early
A config entry specifying npx some-package tells you the command but not the capabilities. To learn that a server exposes a delete_file tool, something has to start it and enumerate its tools. That is dynamic analysis, and dynamic analysis of untrusted code is the thing security teams work to avoid.
The scanner inherits the risk
Any tool that discovers MCP capabilities by starting servers is executing untrusted commands. The scanner becomes a potential attack vector, which is why consent boundaries and sandboxing are core design questions rather than nice-to-haves.
This is the tension the scanner assessment illuminates. The generated plan treats it as a first-class product requirement: interactive scans request consent before starting local MCP subprocesses, unattended scans require an explicit opt-in flag, and declined execution is recorded as an operational result rather than silently skipped.
Reading the assessment of a purpose-built MCP scanner
We ran Snyk’s agent-scan through Forge, which scans a codebase and scores it across eight dimensions of change friction. The tool is a security scanner for AI agents, MCP servers, and agent skills, built by Snyk from lineage that began as Invariant Labs’ mcp-scan.
It scored 75 out of 100, rated “Advanced”, the highest composite of the codebases we have assessed. That matters for interpretation: the findings below are not a weak codebase failing; they are what residual risk looks like in a security tool built by people who take the problem seriously.
| Dimension | Score | Rating | What it measures |
| Hidden Gems | 84 | Advanced | Reusable patterns worth extracting |
| Logic Narrative | 82 | Advanced | How readably the code tells its story |
| Trust Boundaries | 78 | Advanced | Where untrusted input crosses into the system |
| Semantic Clarity | 76 | Advanced | Whether names match domain concepts |
| Future Proofing | 74 | Established | Resilience to future change |
| Cognitive Load | 72 | Established | Mental effort a change requires |
| Data Weight | 68 | Established | How efficiently data moves |
| System Gravity | 55 | Developing | How concentrated the structural mass is |
Trust Boundaries, with a score of 78 and an Advanced rating, is the notable result. The scan credited typed Pydantic models guarding ingress points, deliberate secret-redaction handling through _mask_key and _extract_env_from_cmd, and dedicated test coverage for proxy and certificate behavior.
The highest composite we have assessed still surfaces a durable-credential finding.
The credential finding every enterprise should check for
The highest-severity finding is worth walking through, because the pattern appears in many enterprise agent deployments and is easy to miss.
Agent-scan includes a guard feature: it installs hooks into AI clients so agent activity routes through security checks. Installing those hooks writes configuration into each client.
The scan found that guard installation appears to encode PUSH_KEY, REMOTE_HOOKS_BASE_URL, and TENANT_ID directly into shell command strings that get written into client hook configuration. The finding includes references to OWASP-A02, CWE-522, and CWE-532.
Why this matters operationally, in the assessment’s own framing: it gives the push key more at-rest surface area than necessary, and makes credential lifecycle dependent on every downstream client config file being cleaned up correctly.
The difference determines whether rotating a compromised key is a single central action or a sweep across every workstation.
Three consequences follow for an enterprise fleet:
- Revocation becomes distributed. Rotating a compromised key means every installed hook on every workstation must be updated. Miss one and a live credential persists in a file.
- Exposure surface widens. Credentials in config files reach backups, sync services, screen shares, and support transcripts. Each is a path the threat model probably did not account for.
- Detection is unlikely. A push key in a hook command does not look like a secret to most scanning tools, because it is a legitimate part of a legitimate command.
The proposed remediation is credential indirection: store only a key reference or profile name in the hook config, resolve the actual secret at execution time from protected storage, and maintain redaction coverage across every display path. The work orders sequence it carefully. WO-004 documents the threat model, WO-014 introduces a credential provider seam, WO-015 renders secret-free hook commands, and WO-023 expands redaction coverage. New behavior stays opt-in until canary validation passes.
The threat model is documented before the credential seam is built. New behavior stays opt-in until canary validation passes.
Four controls to require before approving agent deployment
The assessment and its remediation plan point to four controls that should be required before AI coding agents are approved for enterprise use.
Inventory what agents are connected to
You cannot govern what you cannot enumerate. Scanning should discover installed agent clients, their configured MCP servers, and the skills they have loaded across the fleet. The plan’s discovery layer covers Claude, Codex, OpenCode, and VS Code variants, which is the right shape: per-client discovery, because each stores config differently.
The output belongs in the same asset inventory as any other software. An MCP server with filesystem and network access is not a preference setting.
Contain what execution can reach
Because capability discovery requires execution, the question of containment is unavoidable. The plan makes sandboxing a first-class path rather than documentation: at least two supported sandbox profiles, environment allowlists, filesystem limits, and optional network restrictions are applied before inspection runs.
Two design details are worth copying. Sandbox mode is opt-in rather than default, because a strict profile that blocks legitimate scans gets disabled. And denial messages must be actionable, so a blocked scan tells the developer which permission was needed. The plan sets a guardrail that fewer than 10% of canary scans fail solely due to sandbox defaults.
Bound how long credentials live
The credential finding generalizes. Any agent tooling that stores long-lived secrets on developer machines should move toward short-lived tokens resolved at execution time, with the durable credential stored in the OS keychain or equivalent protected storage.
The success criterion is concrete and checkable: zero newly generated hook configurations contain durable push credentials, verified by scanning generated artifacts in CI rather than by policy statement.
Redact what leaves the machine
Scanners read config files, skill contents, and server output, all of which can contain secrets, absolute paths, usernames, and hostnames. The plan requires redaction covering credentials, sensitive headers, local paths, server output, and scan errors before anything leaves the process.
One finding here is subtle and worth flagging. The scan noted that the logging setup carries a comment acknowledging that log messages can contain arbitrary scanned data. The recommendation is to make redaction an invariant of the logging boundary rather than something each caller remembers.
Credential and execution changes run opt-in alongside the existing path until the canary clears.
Sequencing agent security controls without blocking developers
The rollout runs five phases from August through December 2026, and its shape reflects a specific constraint: security tooling that disrupts developer workflow gets uninstalled.
| Phase | Window | Focus |
| 1. Baseline and policy freeze | Aug 25 – Sep 8 | Parity checklist, credential threat model, control mapping |
| 2. Credential hardening canary | Sep 9 – Oct 6 | Opt-in credential helper, revocation validation, redaction pack |
| 3. Public workflow seams | Oct 7 – Nov 3 | Contract tests, reduce private-helper coupling |
| 4. Runtime, CI, and sandbox beta | Nov 4 – Dec 1 | Python 3.12+ floor, CI audit, sandbox profiles |
| 5. GA and controlled expansion | Dec 2 – Dec 22 | Promote proven changes, migration guide, sunset notice |
The constraint that shapes everything: credential-boundary and MCP-execution changes remain opt-in until proven. Phase 2 runs the old embedded-credential mode and the new helper-mediated mode side by side, with rollback triggered by a credential lookup failure above 5% or any confirmed secret leak.
Parity is treated as a release gate throughout. Every phase requires that 100% of the existing scan, inspect, guard, JSON, and CI regression tests pass, because a security tool that changes the JSON output shape breaks the CI pipelines built on it.
Applying this to your own agent security review
The specifics come from a single scanner, but the review questions apply to any AI coding agent deployment.
- Ask where credentials live at rest. If agent tooling writes tokens into config files, you have a distributed revocation problem. Ask what rotation looks like across the fleet, not just on one machine.
- Ask what happens during discovery. Any tool that enumerates MCP capabilities starts processes. Ask whether consent is requested, whether unattended runs require explicit opt-in, and whether a sandbox path exists.
- Ask what leaves the machine. Scan payloads for file contents and server output. Ask what redaction covers and whether it is enforced at the boundary or left to each caller.
- Treat MCP servers as inventoried software. They execute code with developer privileges. Whatever review a new dependency gets, a new MCP server should get too.
- Judge security tooling by its residual risk. Agent-scan scored 75, the highest we have assessed, and still surfaced a durable-credential finding. A tool with no findings has usually not been examined closely.
Each control is checkable rather than aspirational: enumerate, contain, bound, redact.
AI coding agents are already deployed inside most engineering organizations, generally without procurement review. The practical question is not whether to allow them, but which controls to require before the configuration surface becomes unmanageable.
FAQs
What is MCP and why does it create new security risk?
MCP, the Model Context Protocol, is a standard that allows AI agents to connect to external tools and data sources. The risk comes from how it is deployed: MCP servers are configured in local files and run as local processes with the developer’s privileges, filesystem access, and credentials. Adding a server means adding a command your agent will execute. Because there is no central manifest and no procurement step, most organizations cannot currently enumerate what their developers’ agents are connected to.
Can existing dependency scanners cover MCP servers?
Not adequately. Dependency scanners rely on manifests like package-lock.json that declare what is installed. Agent configurations live in client-specific paths in varying formats with no registry. More fundamentally, an MCP server’s capabilities are not declared statically: discovering that a server exposes a destructive tool generally requires starting it. That is dynamic analysis of untrusted code, which is outside the scope of dependency scanning.
Is it safe to scan an untrusted MCP configuration?
Only with containment. Scanning a config often means starting the servers it defines, which executes third-party commands on the scanning machine. Safe practice requires explicit consent before local execution, an opt-in flag rather than a default for unattended runs, and a sandbox profile that applies environment allowlists and filesystem limits to configs you do not trust. Without those, the scanner is another way to run untrusted code.
What should we require before approving AI coding agents internally?
Four controls. Inventory: enumerate installed clients, configured MCP servers, and loaded skills across the fleet. Containment: a sandbox path for evaluating untrusted configurations. Credential bounding: short-lived tokens resolved at execution time rather than durable secrets in config files. Redaction: enforced at the logging and transport boundary, covering credentials, headers, paths, and server output. Each is checkable rather than aspirational.
How do we handle agent credentials across a developer fleet?
Keep durable credentials out of generated artifacts. Store the long-lived secret in the OS keychain or equivalent protected storage, put only a reference in any config file, and resolve short-lived access at execution time. This makes revocation central rather than distributed: rotating a key does not require touching every workstation. The verification is mechanical: scan generated configurations in CI and assert that no durable credential appears.
