AI Security Best Practices for MCP Deployments

Authentication in MCP is optional by spec. A server with no authentication is technically compliant. That is not a bug in the implementation; it is a deliberate design choice that made adoption frictionless and left security entirely to the implementer. Predictably, many implementers skipped it. Think of it like a bank vault with no door: the architecture is sound, but someone forgot the most important part.

Trend Micro's 2026 research found 1,467 MCP servers publicly exposed on the internet with no authentication whatsoever, nearly triple the count from earlier research. That is not a tail risk. That is the current state of the ecosystem.

What unauthenticated access enables is not subtle. CVE-2025-49596, scored at CVSS 9.4, required nothing more than connecting to an exposed endpoint and sending commands. No password, no token, no challenge. Whatever downstream systems the MCP server was authorized to reach (databases, cloud APIs, internal services) were reachable to the attacker as well.

Credential management compounds the problem. IdenHQ's 2026 research found that only a small minority of organizations use their existing identity provider as the authorization server for their MCP infrastructure. Most rely on static API keys. A static key grants broad access with no scoping, no rotation, and no audit trail of who is actually holding it at any given moment. GitGuardian's State of Secrets Sprawl 2026 identified tens of thousands of secrets in MCP configuration files on public GitHub, with AI-assisted commits leaking at approximately double the base rate. Developers without security backgrounds copy API keys and database connection strings directly into config files, and those files end up in repositories.

Static keys have no natural expiration. A credential issued once can persist for years, accumulating exposure with every commit, fork, and repository transfer. The attack surface here is not exotic. It is mundane credential hygiene, consistently absent at scale.

MCP launched in November 2024 without an authentication framework. OAuth 2.1 did not arrive until mid-2025, by which point the ecosystem had already produced thousands of deployed servers. The NSA's May 2026 guidance frames this plainly: MCP was released with a flexible, underspecified design, much like early web protocols, giving implementers freedom while introducing meaningful ambiguity around safe usage. That ambiguity is still compounding.

The Threat Classes Specific to MCP and How Each One Works

Understanding the attack surface clarifies what adversaries can actually do with it. Several threat classes are particular to MCP's architecture in ways that make conventional security controls insufficient on their own. Worth knowing all of them, because each one exploits a different assumption.

Prompt Injection and Indirect Prompt Injection

Prompt injection embeds malicious instructions in external data an agent reads: a web page, a document, a database row, an API response. The instructions redirect the agent's behavior without the user ever knowing anything changed. Indirect prompt injection is particularly insidious because the attack requires no direct access to the model's interface at all. The attacker poisons a data source; the agent does the rest.

Zylos AI research covering production deployments found that nearly three-quarters showed evidence of prompt injection in 2025. In regulated environments, a successful injection that causes an agent to access out-of-scope data is not just a security event. It can trigger GDPR notification obligations, HIPAA breach reporting, or SOX audit violations, each carrying its own response timeline and organizational cost.

Tool Poisoning

Tool poisoning embeds malicious instructions directly in the tool description an MCP server sends to the agent. The model reads the description as authoritative and acts on hidden commands embedded within it. OWASP codified this as MCP03:2025 in its MCP Top 10 project. Lab benchmarking across real-world MCP servers found attack success rates exceeding 60% under testing conditions. The mechanism is straightforward: the tool description is trusted by design, and that trust is exploited. It is less like hacking a lock and more like convincing the locksmith the door was never supposed to close.

Rug Pull and Supply Chain Attacks

A rug pull occurs when a server silently changes a tool's definition after the developer has approved it. Most MCP clients verify tool definitions at install time but do not re-check when definitions change. That window between approval and re-verification is the attack surface.

Three real incidents illustrate the pattern. The postmark-mcp npm package squatting attack in September 2025 built trust across many versions before BCC'ing all outbound emails to an attacker's address. The Clawdbot exposure in January 2026 left thousands of MCP instances leaking credentials and conversation histories through unauthenticated gateways. A prompt injection targeting the GitHub MCP server hijacked agents into exfiltrating private repository data through a fully legitimate, properly authenticated tool. That last case is worth sitting with: the access controls worked, the tool was legitimate, and the attack happened anyway. It happened inside the execution layer where the access controls could not see it.

Session Hijacking and Cross-Tenant Exposure

MCP sessions are often long-lived and carry access tokens for downstream systems. A hijacked session can replay requests or impersonate a legitimate client without triggering access-layer detection. The Asana incident in June 2025 illustrates what cross-tenant exposure looks like in practice: a bug in its MCP-powered feature caused one customer's data to bleed into other customers' MCP instances for two weeks before the integration was taken offline. That was not a breach in the traditional sense. It was an isolation failure in the session layer, quieter and harder to catch.

Confused Deputy and OAuth Token Abuse

An MCP server holding OAuth tokens for multiple users can fail to isolate them, creating a confused deputy scenario where an attacker tricks the server into acting with another user's credentials. CVE-2025-6514 demonstrates the severity: the mcp-remote OAuth proxy blindly trusted server-provided OAuth endpoints, passing attacker-controlled values directly to the system shell. The result was remote code execution across Windows, macOS, and Linux, without any credential theft required.

Unverified Task Propagation in Multi-Agent Pipelines

As agentic architectures grow more complex, tasks pass between MCP servers without consistent validation of origin, scope, or intent. One compromised node in a pipeline can poison every downstream agent. A pipeline of five agents multiplies the blast radius of a single compromise proportionally. This is a structural property of how multi-agent systems currently propagate tasks, not a theoretical edge case.

How to Implement Authentication and Authorization at the MCP Layer

The current spec establishes a minimum floor: OAuth 2.1 with PKCE for all protected HTTP-based deployments, HTTPS on all endpoints, and discoverable authorization server metadata. That floor is mandatory for any deployment that merits the word "production." It is not, by itself, a complete posture.

Token Scoping and Resource Indicators

RFC 8707 Resource Indicators are the mechanism against token mis-redemption. The MCP client explicitly declares the intended audience of the access token in the request. The authorization server issues a token scoped and valid only for that specific MCP server, which prevents a token issued for one server from being replayed against another. That is a real attack vector in any deployment where multiple MCP servers share an authorization infrastructure, and it is easy to miss until it has already been exploited.

Step-Up Authorization

The November 2025 spec update introduced step-up authorization. When a request requires elevated access, the MCP server returns a 403 with the required scopes. The client re-initiates authorization, potentially prompting explicit user consent. This keeps least privilege as the default while allowing controlled escalation for higher-risk actions, rather than granting broad access upfront to avoid friction. The friction, it turns out, is doing something useful.

Session-to-Identity Binding

The NSA's guidance notes explicitly that MCP does not define how a session maps to a verifiable identity. That gap must be filled at the enterprise deployment layer. Every MCP action should be attributed to a named user or service account, not an anonymous token. SSO integration makes this tractable. SCIM handles lifecycle: when an employee leaves or a service is deprovisioned, their MCP access revokes automatically rather than persisting as an orphaned credential waiting for someone to notice it.

Just-in-Time Credential Provisioning

JIT provisioning generates short-lived credentials at the moment of a tool call and expires them immediately after. This directly addresses the secrets sprawl problem: there is no long-lived key sitting in a config file to be leaked, because the key stops existing once the call completes. The exposure window is bounded by the duration of a single tool call. For teams still running on static keys, the practical migration path is to enumerate every key in use, scope each to the minimum required permissions, rotate on a defined schedule, and move the highest-risk ones to JIT first.

Auth0's Auth for MCP reached general availability in May 2026. Okta released an MCP server enforcing least-privilege access at each tool call. Both signal that IdP vendors now treat MCP as a first-class integration surface, which means the tooling to implement this properly exists and is production-ready. There is no longer a reasonable excuse for deploying without it.

Enforcing Least Privilege at the Tool-Call Level, Not Just the Server Level

Access to an MCP server is not the same as controlled access to what the agent can do inside it. A server exposes dozens of tools. In a typical deployment, access to the server implies access to all of them. That is not least privilege. It is least privilege applied at the wrong layer, which means it is not really least privilege at all.

Policy Enforcement at Tool-Call Depth

The control needs to live at the tool call itself. Define which tools a given user, role, or agent is permitted to invoke, not just which servers they can reach. Separate read and write permissions explicitly: an agent that summarizes documents should not share tool access with one that sends emails or modifies records. These are categorically different risk profiles and should be treated accordingly.

RBAC at the Platform or Gateway Layer

The NSA guidance is direct on this: RBAC is not part of the MCP protocol. It must be implemented at the platform or gateway layer. The practical approach is to map organizational roles (analyst, engineer, finance team) to specific tool allowlists. An analyst who needs to query a data warehouse should not inherit access to tools that provision cloud infrastructure simply because both happen to live on the same MCP server.

Permissions in Multi-Agent Pipelines

Each agent in a pipeline should carry only the credentials and tool permissions it needs for its specific step, not the full permissions of the orchestrating agent. This is partly a permissions problem and partly a blast-radius problem. If a downstream agent cannot exceed the scope of the task it was handed, a compromised upstream agent cannot leverage the downstream agent to escalate. The confinement is structural, which matters because structural controls hold even when detection fails.

Tool Allowlisting as a Supply Chain Control

Maintain a registry of approved tool definitions with cryptographic hashes. Reject any tool description that does not match the approved hash at connection time. This is the core principle behind the ETDI proposal from Bhatt et al. in 2025, and it directly defeats rug pull attacks: the attack depends on clients that do not re-verify after initial approval. Re-verification breaks that assumption entirely.

The Five Eyes joint guidance from CISA, NSA, and four allied agencies (published in May 2026) identifies privilege escalation as a primary risk category for agentic deployments. Least-privilege enforcement at the tool level is the direct mitigation they point to.

Detecting Active Threats During Agent Execution, Not After the Fact

Perimeter controls cannot catch everything. A correctly authenticated, properly authorized agent can still be manipulated through its inputs. Prompt injection exploits the model, not the access layer. Tool poisoning embeds the attack in the tool description, which arrives after authentication succeeds. The access controls worked; the attack happened anyway. Runtime detection exists to cover what the access layer structurally cannot.

Prompt Injection Detection

Inspect content retrieved from external sources before it enters the model's context: web pages, documents, database results, API responses. Pattern-based detection catches common injection signatures. Semantic analysis is necessary for more sophisticated attempts that avoid obvious patterns. Treat instruction-like content appearing in data payloads as a risk signal regardless of the source's apparent legitimacy. A trusted internal document can contain injected instructions just as easily as an external web page, and internal trust is exactly what makes those injections more dangerous.

Tool Definition Integrity at Connection Time

Before the agent acts on a tool description, compare it against the approved hash in the registry. A mismatch is a rug pull signal. Quarantine the tool and alert rather than letting the agent proceed. This needs to be a runtime check, not just an installation check, because rug pulls occur after installation. That distinction is the whole point.

Intent Drift Detection

Monitor whether the agent's actions during a session remain consistent with the stated task it was given at the start. Divergence is a signal that the agent was manipulated mid-session through accumulated injected instructions. This matters most in long-running agentic pipelines, where the original task context can erode across dozens of tool calls and the drift is gradual enough that no single action looks anomalous in isolation. By the time something obvious happens, the damage is already done.

Exfiltration Detection

Watch for outbound data volumes or destinations inconsistent with the tool being called. An email tool sending an unusually large payload to an external address is a behavioral anomaly regardless of whether the tool call was authenticated and authorized. The GitHub MCP prompt injection incident involved a fully legitimate tool used for illegitimate data exfiltration. Behavioral monitoring catches what access controls structurally cannot: the misuse of legitimate capability.

The Five Eyes guidance names behavioral misalignment as a distinct risk category for agentic systems. Runtime detection is the control layer that addresses it.

Building an Audit Trail That Can Answer for Every Tool Call an Agent Made

Conventional application logs are not built for agents. When an AI agent takes an action, a standard log will record that an API was called. It will not necessarily record which user triggered the agent session, which tool was invoked, what parameters were passed, what version of the tool description was active at the time, or what the agent did with the result. That is not an audit trail. It is a partial record, and a partial record is often worse than none, because it creates the illusion of accountability without the substance.

What a Complete MCP Audit Record Captures

A complete record needs: the identity of the user or service account that initiated the session; the specific tool called, the server it lives on, and the exact parameters passed; the tool description version active at the time of the call; the outcome (what the tool returned and what action the agent took as a result); and timestamps at each step of a multi-agent pipeline, not just at session start and end. Each element exists to answer a specific question that a security investigation or compliance audit will eventually ask. Think of it as a receipt for every decision the agent made — without it, you are left arguing with a vending machine that has no record of what it dispensed.

The tool description version deserves particular emphasis. If a rug pull is alleged after the fact, the ability to demonstrate what description version was active at the time of each tool call is the difference between a defensible record and an ambiguous one. Without it, you cannot prove the agent acted on the approved definition, and in a regulated environment, that ambiguity is not a technicality. It is a liability.

Tamper-Proof Logs as a Compliance Requirement

A prompt injection that causes unauthorized data access is a compliance event under GDPR, HIPAA, and SOX (not just a security incident). Each framework imposes its own documentation requirements, and those requirements assume the records themselves are reliable. Logs that can be modified after the fact do not satisfy that requirement. Append-only, cryptographically signed log storage is not an enterprise luxury; for any deployment operating in a regulated environment, it is a baseline obligation.

The audit trail is also the mechanism by which the other controls prove themselves. Authentication logs show that sessions were bound to verifiable identities. Tool-call logs show that allowlists were enforced. Intent drift records show that behavioral monitoring was active. Without the audit layer, you have controls you cannot demonstrate. With it, every action an agent took (and the authorization state that governed it) is attributable, reviewable, and defensible.