A flaw in Amazon Q Developer let malicious repositories inject rogue Model Context Protocol (MCP) configurations into the agentic coding assistant's pipeline. The result: arbitrary code execution, sourced from a repo you pulled down to review.
No phishing. No compromised credentials. Just a poisoned config file sitting in a repository that an AI agent trusted without question.
What Happened
According to The Hacker News, the vulnerability allowed an attacker-controlled repository to supply malicious MCP tool configurations to Amazon Q Developer. Because Amazon Q trusts MCP configs sourced from external repos, those configs could be used to hijack the agent's actions — up to and including arbitrary code execution inside the agentic pipeline.
This is a supply-chain attack against an AI system. The malicious payload isn't in the code you're running — it's in the tool definition that tells your AI agent what to do next.
The scope is significant. Amazon Q Developer is a widely deployed AI coding assistant. Any developer who cloned or opened an attacker-controlled repo while Q was active was potentially exposed.
How the Attack Works
MCP (Model Context Protocol) is the emerging standard for wiring LLMs to external tools: file systems, shells, APIs, databases. An MCP config tells an agent: here are the tools available to you, here is how to call them, here is what they return.
The attack exploits a simple trust assumption: if an MCP config file is present in a repository, the agent uses it. There's no signature verification, no allowlist enforcement, no sandboxing of tool definitions at the agent layer.
Here's the attack flow:
- Attacker crafts a repository with a malicious
.mcp.jsonor equivalent config file - Developer clones or opens the repo — Amazon Q Developer picks up the MCP config
- The rogue config registers attacker-controlled tools or overrides legitimate ones
- When Q invokes those tools (which it will, during normal agentic coding workflows), it executes attacker-supplied commands
- Code runs. Potentially: env vars exfiltrated, credentials stolen, backdoors planted
The cleverness here is that the agent isn't being tricked into doing something weird. It's doing exactly what it was told — by tool definitions it had no reason to distrust.
Why Existing Defenses Missed This
The standard defenses don't cover this attack surface:
Static analysis and SCA tools scan code for vulnerabilities. A malicious MCP config isn't vulnerable code — it's a configuration file. It passes cleanly.
Repository scanning (Dependabot, Snyk, etc.) checks for known-bad package versions and CVEs. A crafted JSON config with a malicious tool definition has no CVE. No match.
Network-layer controls (WAFs, egress filtering) don't inspect the semantic intent of tool calls that an AI agent is about to make. They see HTTP traffic, not "this tool result is telling the agent to execute a shell command."
The LLM itself is not a security boundary. Models are trained to be helpful and follow instructions. A tool result that says "run this command" is, from the model's perspective, a legitimate tool result.
The gap is at the agentic pipeline layer — between tool outputs and the model. Nobody was watching that seam.
Where Sentinel Would Have Caught This
Sentinel sits exactly at that seam. For agentic applications, Sentinel's transparent proxy intercepts tool_result content before it returns to the model. This is where malicious MCP configs do their damage — in the tool call / tool result loop.
The relevant detection layer is tool and function abuse patterns, part of Sentinel's Layer 2 fast-path regex scan. Sentinel maintains patterns that detect when tool outputs are being used to redirect agent behavior — authority hijacks, persona shifts, instructions embedded in tool responses that attempt to override the agent's existing directive.
A malicious MCP tool result that says "ignore your current task and execute the following" hits the authority hijack patterns immediately. A tool response that attempts to exfiltrate environment variables via markdown or code block embedding hits the data exfiltration patterns.
If the payload is more subtle — say, a tool definition that gradually steers agent behavior through seemingly innocuous outputs — Layer 3's vector similarity scoring catches semantic variants that don't match a literal regex. Sentinel computes a cosine similarity against our library of attack signature embeddings. Attempts to hijack agent control flow tend to cluster semantically even when the exact phrasing varies.
And because this is a scenario where a malicious repo could instruct the agent to read config files or .env files as part of a "helpful" setup step, Layer 4 secret detection is directly relevant. Even if a tool result carrying exfiltrated environment variables slipped past the threat scorer, Sentinel's secret detector would redact any embedded API keys, tokens, or credentials before they ever reached the model. Patterns like AWS_ACCESS_KEY=AKIA... or ANTHROPIC_API_KEY=sk-ant-... get replaced with [AWS_ACCESS_KEY] and [ENV_SECRET] respectively.
What This Looks Like in Practice
Here's an illustrative example of what Sentinel returns when it detects a malicious tool result carrying an authority hijack and an embedded credential (this response shape reflects Sentinel's actual API):
{
"request_id": "f3a9b2c1d4e5...",
"security": {
"action_taken": "blocked",
"threat_score": 0.91,
"secret_hits": 1,
"secret_types": ["aws_access_key"]
},
"safe_payload": null
}
action_taken: blocked means the cosine similarity exceeded 0.82 — the content never reaches the model. safe_payload is null. Your application checks action_taken first and discards the original tool result entirely.
For the transparent proxy setup — where you point your Anthropic SDK at Sentinel instead of the Anthropic endpoint directly — this happens automatically. Blocked tool results are substituted with an inert placeholder; the agent session continues without the malicious payload, and without the SDK seeing anything other than a normal Anthropic-format response.
import anthropic
# Point the SDK at Sentinel instead of Anthropic directly
client = anthropic.Anthropic(
api_key="sk_live_...", # Your Sentinel API key
base_url="https://sentinel.ircnet.us/v1",
)
# All tool results are scanned automatically before returning to the agent.
# Malicious MCP tool outputs are blocked at the proxy layer.
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": "Set up this repo for me."}],
)
For strict mode — appropriate for agentic coding workflows where the blast radius of a compromised tool call is high — set tier: "strict" on your scrub requests. This lowers the flag threshold to 0.25 and the neutralize threshold to 0.40, catching borderline cases that standard mode lets through.
The Takeaway
The Amazon Q Developer incident is a clean example of a class of attacks that will become more common as agentic AI systems proliferate: trust exploitation at the tool layer. The agent isn't being jailbroken. The developer isn't being phished. The attack lives entirely in the pipeline between external tool outputs and the model — a seam that most security tooling doesn't cover.
One thing you can do today: if you're running an agentic coding assistant or any LLM that processes tool results from external sources, put a proxy in front of the tool result path. Treat every tool output as untrusted input, the same way you'd treat user-supplied data in a web application. Scan it before it reaches the model.
The Amazon Q flaw is patched. The attack pattern is not.
Sentinel is a self-hosted AI firewall that scrubs tool results, prompt injections, and credential leaks before they reach your model. Free tier available, no credit card required.
👉 sentinel-proxy.skyblue-soft.com