Key takeaway: MCP security is not mainly a prompt-filtering problem. Once an agent can call tools with real credentials, the useful threat model is identity + authorization + untrusted input + execution.
On October 1, AWS disclosed CVE-2026-97662 in
security-agent-mcp-server: a crafted diff reference could be
interpreted as a command-line option and write outside the intended
workspace. AWS fixed it in 0.2.0 and recommends least privilege and
isolation.
Primary source: https://aws.amazon.com/security/security-bulletins/2026-121-aws/
Recent reporting on cross-agent trust failures points at the broader problem: one agent can become input to another, and "internal" is not the same as trusted.
The old diagram is wrong
USER → APPLICATION → API → DATABASE
Agentic systems increasingly look like:
USER → AGENT → MCP CLIENT → MCP SERVER → TOOL → API/CLI → DATA/INFRA
Every arrow can carry authority. Every component can transform attacker-controlled content. Several may silently inherit a human's privileges.
Five questions before another MCP goes live
- Whose identity executes the tool call? A developer token is not an agent identity.
- Can untrusted content influence tool arguments? Repository text, tickets, email, web content and tool output count.
- Where is authorization enforced? A model deciding not to call a tool is not authorization.
- What can the runtime reach? Filesystem, metadata services, internal APIs and credentials matter.
- Can you reconstruct the chain? Prompt → decision → tool → arguments → identity → target → result.
OWASP recommends separate agent identities, short-lived scoped credentials, non-admin roles and deny-first tool permissions: https://owasp.github.io/DevSecOpsGuideline/2-Process/2-2-Develop/2-2-5-AI-Agent-and-MCP-Security/
Microsoft's preview MCP firewall is notable because it treats MCP as an identity-aware enforcement surface: https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-configure-mcp-firewall
Product-security implication
Testing the model alone misses the system. Review instructions, tool schema, identity, OAuth scopes, MCP implementation, runtime, network reachability, organizational restrictions and downstream authorization together.
The winning control is not "trust the agent." It is making agent authority explicit, narrow, observable and revocable.
FAQ
Is MCP itself insecure? No. Risk depends on identities, tool permissions, validation, isolation, trust relationships and exposed actions.
Is prompt injection the main risk? It is one vector. Authorization failure, credential overreach, unsafe arguments, execution bugs and transitive trust matter too.
What first? Map identities and tool privileges, then test whether untrusted content can cause actions beyond intended authority.
About 0day Factory
0day Factory researches how real attack paths emerge across software, infrastructure, identity, security controls and organizational boundaries.