How AI agent infrastructure gets compromised
Traditional applications have a clear trust boundary. The user sits at one end. The backend sits at the other. Authentication happens at each hop. The flow is user → app → backend, and every input gets validated before it crosses a boundary.
MCP changes the shape. The flow is now AI context → MCP server → backend systems. The AI's context is a control plane: whatever influences the context influences which tool the server invokes. User input is one source of that context. Retrieved documents, prior tool outputs, and injected instructions are others. The trust boundary is no longer at the application; it is at the model's context.
This paper describes what Red Asgard audits on an MCP deployment. The companion operational kit is at redasgard.com/mcp-security; the longer published analysis is in our blog article.
What an MCP deployment exposes
The protocol surfaces three primitives.
Tools. Functions the AI agent can invoke: execute_shell, query_database, read_file, send_email. Tools are endpoints with the calling convention of a function and the trust model of an internal API. The caller is an AI whose context can be manipulated by external data sources.
Resources. Read-only data the server exposes to the agent. Files, database rows, API responses. The server decides which resources the agent sees. We audit which resources are exposed, what access controls gate them, whether the resource set is enumerable through list_resources, and whether sensitive content is filtered before it enters the agent's context.
Prompts. Server-provided templates that the agent can ask the model to follow. A compromised prompt is a compromised agent. We audit template integrity (who provides the template, who reviews changes), the server's attestation chain, and whether the client binds prompts only after explicit user consent.
Each primitive has its own attack surface. The most common compromise paths attack the tools.
Transports. MCP defines stdio, SSE, and HTTP transports. stdio is a local IPC channel between two processes on the same machine; the trust boundary is OS-level user separation, and authentication is implicit in process ownership. SSE and HTTP are network transports; both require explicit authentication, transport encryption, and access control. We check which transport each server uses and whether the auth posture matches the transport's exposure.
What we look for
A reviewer hunting through an MCP deployment carries a working pattern catalog.
Missing or weak authentication. Public research has consistently found that a meaningful share of internet-exposed MCP servers accept unauthenticated connections, and that of those requiring credentials, many rely on long-lived static secrets (API keys, personal access tokens) that rarely rotate. Knostic's July 2025 study identified over 1,800 publicly exposed MCP servers. Astrix Security's October 2025 analysis of more than 5,000 open-source implementations found that over half rely on long-lived static secrets when they require authentication at all; the remainder require none. We start by asking whether the server requires auth at all, and if so, what rotation discipline exists.
Command injection in tool implementations. Tools that shell out, that pass parameters to interpreters, that build queries by string concatenation. HiveTrail's research found that command-injection patterns appear in nearly half of audited open-source MCP servers. Every tool that builds a downstream call from agent-supplied input is a candidate for injection.
SSRF via URL-fetching tools. A tool that takes a URL parameter and fetches it serverside is, by default, an SSRF primitive. HiveTrail's research describes unrestricted URL fetches as widespread in open-source MCP servers without quantifying at the same precision as their command-injection finding. The attack lands at cloud metadata endpoints, internal management interfaces, link-local addresses. Mitigation requires an explicit allowlist; mitigations that rely on denylist regex routinely fail.
Context manipulation. Anything that gets injected into the model's context is a potential adversarial input. Retrieved documents, tool output reinjected into the conversation, retrieved web pages, transcribed user input. A tool that fetches a webpage and the agent re-summarizes its contents is exposed to instructions embedded in that webpage. The model cannot reliably distinguish "data I am reasoning about" from "instructions I should follow."
Prompt injection via tool descriptions. When an agent enumerates tools through list_tools or its equivalent, the server-provided tool descriptions enter the model's context. A malicious server can embed instructions in tool descriptions, names, or parameter documentation that the agent reads before it ever invokes a tool. The attack surface is the metadata layer, not just tool outputs.
Auto-chained tool calls without explicit approval. Some MCP clients require explicit user confirmation before each tool call; some chain tool calls automatically based on the model's reasoning. The threat models differ. An auto-chaining client compounds context manipulation: one poisoned tool output can drive the next tool call without a human in the loop. We name the client's approval mode and constrain the auto-chain authority where present.
Capability sprawl. A tool described as "read a file" that accepts a path parameter usually has no path validation. A tool described as "query the database" usually accepts arbitrary SQL. A tool described as "send an email" usually has no per-recipient throttling. The tool's name is the contract; the tool's implementation is the actual authority.
Cross-server and cross-agent attacks. An agent connected to multiple MCP servers can be steered to use server A's output as input to server B. A malicious server in the chain can poison data that another server then trusts. Multi-agent systems amplify the attack surface; one compromised agent can issue tool calls through every server its peers trust.
Credential exposure. MCP servers usually hold the production credentials for the systems they front: database connection strings, cloud API tokens, SSH keys, webhook secrets. Compromising the MCP server is compromising those credentials. Most MCP servers are open source on GitHub or npm, so the supply-chain risks documented in our supply-chain paper apply directly to the binaries running in production. We treat every MCP server as a credential-handling service.
What public research shows
The case literature is the reference.
Knostic (July 2025). Over 1,800 MCP servers exposed to the public internet. Manual testing of a sample found that all accepted unauthenticated connections and exposed internal tool listings.
Astrix Security (October 2025). More than 5,000 open-source MCP implementations analyzed. Over half rely on long-lived static secrets when they require auth at all; the remainder require no auth.
HiveTrail. Roughly half of audited open-source MCP servers contain command-injection vulnerabilities. Many allow unrestricted URL fetches.
Trend Micro. Hundreds of MCP servers operating without client authentication or transport encryption, exposing more than a thousand tools in aggregate.
The pattern across all four is consistent: the protocol does not require defenses, and production deployments do not add them.
The specification problem
The MCP specification treats authentication as transport-dependent and does not mandate it in the base protocol. In practice, optional security features tend to remain optional. The pattern is familiar from early OAuth implementations, CORS configurations, and API key management: when the spec does not mandate protection, production deployments do not add it.
This is not a criticism of the protocol designers. MCP solves real interoperability problems. But "spec-compliant" and "secure" are not synonyms here. The deployment is responsible for the defenses the spec leaves optional.
Defensive primitives
A deployment that wants to survive the patterns above relies on a small set of defenses. These are the building blocks documented in our MCP Security Kit.
Authentication required by default. No anonymous connections. Per-actor credentials. Rotation discipline. Hashed comparison with timing-attack resistance.
External policy gate. Tool calls are evaluated by a separate component before execution. The policy is deterministic, not derived from the model's context. Default action is DENY.
Strict schemas for tool inputs. Every tool parameter has a typed schema, a length bound, and an explicit allowed character set. Inputs that fail the schema are rejected, not coerced.
Fail-closed behavior. Validation errors, policy errors, timeouts, and unexpected exceptions all map to DENY. The deployment never silently allows a call because an enforcement component failed.
Allowlists for filesystem, database, and URL operations. The tool description names the operation; the policy gate enforces the boundary. Denylists drift; allowlists fail safely.
Per-tool rate limits and global egress controls. A compromised agent that bypasses the policy gate should still hit a wall on call frequency or on outbound network reach.
Structured logging of every tool call. MCP tool calls are invisible to most SOCs by default. There is no equivalent of HTTP access logs or API gateway logs without explicit instrumentation; the model invokes the server directly and the call leaves no trace in the layers a SOC already monitors. Logging is the missing control plane. The minimum fields: identity (actor, session), tool name, sanitized arguments, policy decision, status, latency, and a reference to the model output that produced the call. SIEM-shaped, queryable, correlatable. Without these, you cannot detect attacks in progress, investigate after incidents, or baseline normal behavior.
None of these defenses are novel. The deployments that get exploited usually skipped one or two of them. The kit at /mcp-security ships the templates.
What we audit on an MCP deployment
Our AI Security service covers MCP assessments. A typical engagement audits:
- Server inventory: which MCP servers exist, what they expose, how they are reachable
- Transports: stdio vs SSE vs HTTP, whether the auth posture matches the transport's exposure
- Authentication: which servers require it, what scheme is used, how credentials are rotated
- Tool implementations: every tool, its inputs, its downstream call pattern, its injection and SSRF surface
- Policy enforcement: whether an external gate exists, what it enforces, whether it fails closed
- Schemas: every tool parameter, its validation, its boundary
- Logging: what fields are emitted, where they go, whether the SOC can correlate them
- Context-manipulation exposure: which agents read what data, which data sources are adversarial
- Credential handling: what secrets the server holds, how they are protected at rest and in use
The deliverable is the audit report described in our methodology, adapted for AI agent infrastructure: findings ranked by severity, reproducible evidence for every Critical and High, residual-risk section, and a fix-confirmation pass after patches.
What clean means
A clean MCP audit means the deployment's authentication, policy enforcement, schemas, and logging are in place and the obvious tool-level attack surface is closed. It does not mean the agent is safe under prompt injection from data sources we did not audit. The model cannot reliably enforce security policy; its context is by definition adversarial in the worst case. Policy lives outside the model. We say so explicitly.