When your AI security scanner becomes the write primitive
On October 1, AWS published a bulletin for CVE-2026-97662 in security-agent-mcp-server, an open-source MCP server used by AI assistants to run local security scans over source code. The bug was not another chatbot trick. It was an argument injection flaw in a security tool that could create, overwrite, or truncate files outside the intended workspace.
That distinction matters. Agent security discussions often focus on the model, the prompt, or the external connector. This case lands in a less comfortable place: the defensive tool itself became a host write primitive.
The immediate fix is simple. Upgrade to security-agent-mcp-server 0.2.0 or later. The strategic lesson is harder. Any tool you hand to an agent, including a scanner, linter, evaluator, or code review helper, needs runtime boundaries that assume the tool can be misused.
What happened
According to the AWS security bulletin, the affected MCP server exposes local security scan operations to AI assistants. The vulnerable operation was the differential scan path. A crafted reference supplied to the scan could be parsed as a command-line option rather than as the revision value the server expected.
That parsing mistake let a context-dependent actor write outside the workspace directory. AWS says there is no workaround other than upgrading, and recommends running diff scans only against trusted repositories until patched.
This is not "RCE in every deployment". The reported impact is file creation, overwrite, or truncation outside the workspace, and exploitation depends on context. That is still enough to matter because developer and CI hosts are full of files whose integrity decides what runs next: shell startup files, tool configuration, lockfiles, hooks, caches, generated code, service manifests, and agent configuration.
The important part is not the exact flag or file path. It is the trust inversion. A security scan is often treated as safe because it is read-heavy and defensive. In an agent workflow, that assumption breaks down. The scanner is still a program that parses attacker-influenced input and performs host operations.
Why this is an agentic security issue
Traditional scanner threat models usually start with "the user runs the scanner against code". Agentic scanner threat models need a different starting point: "an autonomous assistant may decide when, how, and against which inputs to run the scanner".
That changes three things.
First, scan inputs are no longer just code. They can include branch names, references, paths, generated arguments, repository metadata, tool descriptions, and prior tool output.
Second, the caller may not understand the precise operation the tool will perform. The assistant may ask for a diff scan because it looks like the next helpful action, not because a human reviewed every parameter.
Third, scanners are commonly granted broad local access. They need source files, dependency manifests, temporary directories, caches, and sometimes credentials for private registries. A write bug in that position is more serious than a write bug in a low-privilege toy tool.
"Only trusted developers can run this" is not a sufficient control once an agent can invoke the tool on their behalf. The trust boundary moves from the user account to the tool call, the arguments, the repository, and the runtime profile around the server.
Map it to OWASP Agentic Top 10
This incident fits several parts of the OWASP Top 10 for Agentic Applications 2026. It is especially useful because it shows how a single MCP server vulnerability can cross multiple risk categories.
| OWASP area | How it appears here | Control to verify |
|---|---|---|
| ASI02 Excessive Agency | A scanner exposed through MCP can perform filesystem operations wider than the intended task. | Constrain each tool by action type, path, repository, and runtime profile. |
| ASI04 Agentic Supply Chain Vulnerabilities | The vulnerable component sits in the agent tool chain, not in the model. | Inventory MCP servers, versions, transitive dependencies, and forked copies. |
| ASI05 Memory and Context Manipulation | Attacker-controlled repository context can influence the tool arguments an agent generates. | Treat repository metadata, branch names, issue text, and tool output as untrusted input. |
| ASI07 Agent Communication Poisoning | A trusted assistant can relay a dangerous operation to a trusted local server. | Authorize the final tool call outside the model, not only the natural-language task. |
The newer OWASP Agentic Skills Top 10 also points in the same direction. Skills and tools are where agent intent turns into real operations. MCP defines how the assistant reaches a tool. The skill or tool implementation decides what actually happens on the machine.
The control pattern: scan in a disposable lane
Security teams should treat agent-invoked scanners as untrusted execution, even when the scanner is published by a trusted vendor and used for a defensive purpose.
The practical design is a disposable scan lane:
These controls sound like sandboxing, but the important word is accountability. Security teams need to know what an agent asked a tool to do, what the tool actually did, and which independent policy allowed it.
The uncomfortable lesson for security teams
Agentic AI is pushing security tooling into a new role. Scanners are no longer only batch jobs in CI or commands a human runs from a terminal. They are callable capabilities inside an agent loop.
That makes them part of the attack path.
The fix for CVE-2026-97662 is an upgrade. The fix for the class is architectural: no tool gets ambient write access just because its purpose is defensive. Security tools should be powerful, but they should not be trusted by default when an agent can aim them.
The next agent security review should include the defensive tools. Ask which MCP servers can read, write, spawn processes, reach the network, or touch credentials. Then decide whether those powers belong in the same lane as untrusted repositories and autonomous tool calls.
What to do this week
- Inventory every MCP server used by coding assistants, CI agents, security scanners, and local developer workflows.
- Upgrade security-agent-mcp-server to 0.2.0 or later if it is present.
- Search for wrappers, forks, templates, and base images that bundle vulnerable versions.
- Move agent-invoked scanning into an isolated user or container with read-only workspace mounts where possible.
- Add policy checks for path escapes, command-line option injection, and writes outside approved output directories.
None of this requires waiting for a broader standard to mature. It is standard application security discipline applied to the programs that agents can now call.