MCP Security Best Practices: A Checklist for Secure AI Deployments
Learn MCP security best practices with a practical checklist for securing AI deployments, protecting MCP servers and tools, and reducing security risks.
Arpashree
The Model Context Protocol (MCP) that connects the AI agents with the tools, APIs, and Data they work with has emerged as a connective. This has prompted rapid adoption of MCP across the AI ecosystem, from companies such as Anthropic and OpenAI to numerous open-source projects that have been developed. This type of growth costs resources. Each tool that an agent can call, each session it maintains, and each external integration it engages increases the attack surface that defenders must "think about. The way each agent comes about is autonomous and typically not from trusted input, which means that using the traditional perimeter approach is not enough. This guide explores MCP threat modeling, authentication and authorization controls, execution sandboxing, supply chain risks, monitoring, automated testing, and a practical checklist of points for your actual deployments.
Why MCP Needs a Dedicated Security Checklist
The Model Context Protocol standardizes how AI agents discover and call external tools, but it doesn't enforce security at the protocol level, leaving authentication, access control, and validation almost entirely up to individual server implementations. That gap shows up starkly in practice: recent research found only 8.5% of MCP servers currently implement OAuth 2.1, the protocol's mandatory authentication standard for remote deployments, and just 18% implement any access scoping for tool permissions at all. For the full explanation of how MCP works and why it introduces these gaps, see our MCP security explainer. This piece is the practical checklist that follows from it.
Authentication and Authorization
Enforce OAuth 2.1 on Every MCP Server
The MCP specification mandates OAuth 2.1 with PKCE for any remote, HTTP-based server exposing tools or resources to AI agents, no exceptions. This provides delegated authorization with explicit scope control, short-lived tokens, and cryptographic verification that simpler methods like static API keys or session cookies can't match, particularly around granular revocation when a session ends.
Never Accept Passthrough Tokens
An MCP server must validate that every inbound token was issued specifically for it, checking the audience claim rather than trusting a valid signature alone, and must never forward a client's token unmodified to a downstream API. If the server needs to call another service, it obtains its own token through a separate delegation flow, such as RFC 8693 token exchange. Skipping this step is the single most common shortcut that undermines an otherwise reasonable MCP server, since it breaks the audience-binding guarantee that makes OAuth security meaningful in the first place.
Require Per-Client Consent (Avoid Confused Deputy)
The confused deputy problem occurs when a server with more authority than the entity requesting an action gets tricked into misusing that authority, typically because token passthrough lets a downstream service incorrectly trust a forwarded token as if the server itself had validated the request. MCP proxy servers using a static client ID against a third-party authorization server are especially exposed, since an attacker can exploit an existing consent cookie tied to that static ID to intercept an authorization code. Requiring explicit, per-client consent, with exact redirect URI matching rather than pattern matching, closes this path.
Least Privilege and Access Control
Scope Tool Access to the Task at Hand
An MCP server should expose only the tools a given agent's task actually requires, not the full set of capabilities the server happens to support. Broad, undifferentiated tool access is what turns a single successful manipulation into a wide-reaching compromise, since an agent tricked into calling one tool outside its intended scope can only do damage proportional to what it was granted in the first place.
Apply RBAC and Review Permissions on Every New Server
Role-based access control should govern which agents and users can invoke which tools, and that mapping needs review every time a new MCP server is connected, not just at initial rollout. Permissions granted at onboarding tend to persist unreviewed long after the original justification for them has changed, which is exactly the drift that turns a reasonable initial configuration into an unreasonable one over time.
Avoid Long-Lived or Static Credentials
Static, long-lived credentials, whether API keys embedded in configuration or tokens with no expiration, remain valid long after they should, giving an attacker who obtains one a durable foothold rather than a narrow window. Short-lived, automatically rotated credentials limit the blast radius of any single credential exposure, since a stolen token that expires in minutes is a fundamentally smaller problem than one that never expires at all.
Input and Schema Validation
Treat Tool Descriptions and Responses as Untrusted Input
A tool's description and its response content are both attacker-controllable in ways that are easy to overlook, since they arrive through a channel that looks like configuration rather than user input. A malicious or compromised MCP server can embed instructions inside a tool description or a response payload that an agent processes as trusted context, making indirect prompt injection through the tool layer itself a realistic and increasingly common attack path.
Enforce Schema Validation on Every Tool Call
Every tool call, in both directions, should be validated against a strict, typed schema rather than accepted as loosely structured JSON. This catches malformed calls before they execute and limits how much an attacker can manipulate a tool's behavior through unexpected parameter values or unanticipated field combinations.
Sanitize Content Before It Enters the Model Context
Content retrieved from a tool, a document, or an external API needs to be sanitized before it's added to an agent's working context, since anything that reaches the model's context window is a potential injection vector regardless of how legitimate its original source appeared. Sanitization at this boundary is one of the few controls that catches an attack regardless of which upstream tool or server the malicious content originated from.
Transport and Session Security
Enforce TLS/HTTPS Everywhere
Every MCP connection over a network, not just ones handling obviously sensitive data, should run over TLS. Servers must also validate the Origin header on incoming connections to prevent DNS rebinding attacks, a check that's easy to skip and correspondingly easy for an attacker to exploit when it's missing.
Secure Session ID Generation and Handling
Where a server maintains stateful sessions, the session identifier needs to be globally unique and cryptographically secure, generated as a UUID, JWT, or cryptographic hash rather than a predictable value. Session metadata should be stored server-side, sessions should be invalidated after inactivity or explicit termination, and every session ID header needs validation to prevent fixation or injection. Note that the protocol itself is moving away from this model: the 2026-07-28 specification revision introduces a stateless architecture that removes the initialization handshake and session ID header entirely, so new deployments should track which transport model they're actually running rather than assuming the older session-based guidance still applies.
Use Streamable HTTP for Stateless, Load-Balanced Deployments
Streamable HTTP supports both stateful and stateless operation, and the stateless mode is generally the safer default for horizontally scaled deployments, since it removes session affinity requirements entirely, letting any request land on any server instance without a shared session store to secure or synchronize. This also shrinks the attack surface tied to session hijacking, since there's no persistent session state for an attacker to target in the first place.
Supply Chain Security
Pin Versions and Verify Publishers
An MCP server pulled from a public registry should be pinned to a specific, reviewed version rather than tracking "latest" automatically, and its publisher identity should be verified before the server is trusted with any meaningful tool access. Unpinned dependencies and unverified publishers are exactly the pattern that let a legitimate-looking package turn malicious after the fact, without anyone noticing the update.
Vet Community/Third-Party MCP Servers Before Connecting
Community and third-party MCP servers vary enormously in security maturity, and a server's popularity or apparent usefulness says nothing about whether it's been reviewed for the access it requests. Vetting should include reviewing what permissions the server asks for relative to its stated function, checking for a track record of maintenance and disclosed vulnerabilities, and treating an unfamiliar server as untrusted until that review is complete.
Monitor for Anomalous Outbound Traffic
A compromised or malicious MCP server's most reliable tell is often its network behavior rather than its declared functionality: unexpected outbound connections, unusual destination domains, or data volumes inconsistent with the server's stated purpose. Monitoring this traffic catches supply chain compromise that static review of a server's code or manifest would miss entirely.
Runtime Monitoring and Observability
Log Every Tool Call with Full Execution Context
Every tool call should be logged with its full context: which agent invoked it, with what parameters, what the tool returned, and when. Partial logging, capturing only the final outcome rather than the full call chain, leaves exactly the evidence gap that makes a later investigation into a suspected compromise far harder than it needs to be.
Alert on Behavioral Anomalies
Baseline what normal tool usage looks like for a given agent and server, then alert on meaningful deviation: an unusual call frequency, an unfamiliar parameter pattern, or a tool being invoked in a context that doesn't match its typical usage. Anomaly-based alerting catches novel attacks that signature-based detection, built around known patterns, will always miss by definition.
Maintain Audit Trails for Compliance
Audit trails need to be tamper-evident and retained long enough to satisfy whatever regulatory or contractual obligation applies, since a log that can be altered after the fact, or that's purged too early, provides no real assurance during an actual incident investigation or compliance audit.
Human Oversight for Sensitive Actions
Require Approval Workflows for High-Risk Tool Calls
Any tool call with a significant, hard-to-reverse effect, a financial transaction, a data deletion, or a production configuration change should route through a human approval step before execution rather than running autonomously by default. This is the single most reliable backstop against the specific failure mode where an agent's own reasoning, not an external attacker, leads it to take a damaging action it was technically permitted to take.
Allowlist Known-Safe Operations
Not every action needs human review, and requiring approval for every tool call quickly makes a system unusable. Maintaining an explicit allowlist of low-risk, well-understood operations that can run without a human in the loop keeps oversight focused on the calls that actually warrant it, rather than diluting attention across a flood of routine, low-consequence approvals.
Continuous Testing
Static configuration review and a one-time security audit both miss vulnerabilities that only surface once an MCP server is actually running under adversarial conditions. Continuous, automated red teaming against MCP servers and the agents connecting to them catches what static review can't, on an ongoing basis rather than a point-in-time check. See our AI red teaming guide for the full methodology.
MCP Security Maturity: Where to Start
Treating every practice above as a flat, unordered checklist makes it hard to know where to begin, which is exactly the gap a maturity model is built to close. The Cloud Security Alliance's Agentic MCP Security Best Practices Guide defines a four-level MCP Security Maturity Model, mapping specific controls to each level across authentication, tool integrity, session management, supply chain validation, execution isolation, and behavioral monitoring, and cross-referencing each threat category against OWASP's Agentic Security Initiative risks and MITRE ATLAS techniques. The practical value of a staged model like this is sequencing: an organization with no MCP authentication in place shouldn't be trying to implement behavioral anomaly detection first. Foundational controls, OAuth 2.1 enforcement, least-privilege scoping, basic logging, come before the more advanced practices further down this checklist, and trying to skip ahead typically means the advanced controls have nothing solid underneath them.
MCP Security Best Practices Checklist (Quick Reference)
Enforce OAuth 2.1 with PKCE on every remote MCP server; never accept or forward passthrough tokens
Require per-client consent with exact redirect URI matching to prevent confused deputy attacks
Scope tool access narrowly per task, apply RBAC, and review permissions on every new server connection
Avoid long-lived static credentials in favor of short-lived, automatically rotated tokens
Treat tool descriptions and responses as untrusted input, and sanitize content before it enters model context
Enforce schema validation on every tool call in both directions
Run TLS everywhere and validate the Origin header to prevent DNS rebinding
Use cryptographically secure session IDs where sessions are stateful, or move to stateless Streamable HTTP for load-balanced deployments
Pin MCP server versions, verify publisher identity, and vet third-party servers before connecting
Monitor outbound traffic for anomalies that static review would miss
Log every tool call with full execution context and maintain tamper-evident audit trails
Require human approval for high-risk tool calls while allowlisting known-safe operations
Run continuous, automated red teaming rather than a one-time security review
Use a maturity model to sequence adoption, foundational controls first, rather than treating this list as unordered
How Akto Helps Enforce MCP Security Best Practices
Discovery and Inventory of MCP Servers
Akto continuously discovers MCP servers across an environment, including those configured locally by individual developers outside formal review, giving security teams the inventory this entire checklist depends on before any of the remaining controls can be applied.
Automated Testing Against These Practices
Akto's red teaming probes test discovered MCP servers directly against this checklist's risk categories, including authentication weaknesses, confused deputy exposure, and tool misuse, mapping findings to the OWASP MCP Top 10 and MITRE ATLAS for audit-ready reporting rather than an unstructured list of technical findings.
Runtime Enforcement and Guardrails
Beyond testing, Akto's AI Agent Gateway enforces guardrails on live MCP traffic, screening tool calls and responses in real time rather than relying solely on point-in-time review, closing the gap between a server passing an audit and actually behaving safely under production, adversarial conditions.
Final Thoughts on MCP Security Best Practices
MCP's flexibility is exactly what makes it valuable, and exactly why it doesn't enforce security on its own. Every practice in this checklist exists because the protocol leaves the decision to individual implementers, and the data on how few servers currently implement even baseline authentication shows how often that decision gets made poorly. Treating these practices as a sequenced program, anchored to a maturity model rather than a flat list, is what turns a checklist into an actual security posture.
FAQs on MCP security best practices
What are the most important MCP security best practices?
Enforcing OAuth 2.1 authentication, eliminating token passthrough to prevent confused deputy attacks, scoping tool access to least privilege, and validating every tool call against a strict schema form the foundational layer everything else builds on.
How do you prevent token passthrough in MCP deployments?
By ensuring the MCP server validates every inbound token's audience claim and never forwards a client's token unmodified to a downstream API. When the server needs to call another service, it obtains its own token through a separate delegation flow such as token exchange, rather than reusing the token it received.
What is the confused deputy problem, and how do you prevent it?
It occurs when a server with more authority than the requester gets tricked into misusing that authority, typically because a downstream service incorrectly trusts a passed-through token. Preventing it requires eliminating token passthrough entirely and requiring explicit per-client consent with exact redirect URI matching.
How should least privilege be applied to MCP tool access?
Each agent should only have access to the specific tools its current task requires, not the full set a server exposes. Role-based access control should govern this mapping, and permissions need review every time a new server is connected, since access granted at onboarding tends to persist unreviewed long after it's justified.
Why should tool descriptions be treated as untrusted input?
Because both a tool's description and its response content are attacker-controllable, and a compromised or malicious server can embed instructions in either that an agent processes as trusted context, making the tool layer itself a realistic indirect prompt injection vector.
What transport security is required for MCP (TLS, Streamable HTTP)?
TLS should be enforced on every network connection, with Origin header validation to prevent DNS rebinding attacks. Streamable HTTP supports both stateful and stateless operation, and the newer, stateless mode is generally preferable for load-balanced deployments since it removes session affinity and the associated hijacking surface.
How do you secure MCP session IDs against hijacking?
Session IDs should be cryptographically secure and globally unique, stored server-side, invalidated after inactivity, and validated on every request to prevent fixation. Note that the protocol's newer stateless specification removes session IDs entirely for servers that adopt it.
What supply chain practices should apply to third-party MCP servers?
Pin server versions rather than tracking the latest automatically, verify publisher identity before granting meaningful tool access, review what permissions a community server requests relative to its stated function, and monitor outbound traffic for anomalies that indicate compromise.
What should be logged for MCP audit and compliance purposes?
Every tool call with full execution context: which agent invoked it, what parameters were passed, what the tool returned, and when. Logs need to be tamper-evident and retained long enough to satisfy applicable regulatory or contractual requirements.
When should human approval be required for an MCP tool call?
For any action with a significant or hard-to-reverse effect, such as a financial transaction, a data deletion, or a production configuration change. Lower-risk, well-understood operations should be allowlisted to run without approval, keeping human review focused on the calls that actually warrant it.
What is an MCP Security Maturity Model, and how do you use one?
It's a staged framework, such as the Cloud Security Alliance's four-level model, that sequences security controls from foundational to advanced across domains like authentication, session management, and behavioral monitoring. It's used to prioritize implementation order rather than attempting every practice simultaneously.
How often should MCP servers and permissions be reviewed?
At minimum, every time a new server is connected, plus on a recurring scheduled basis independent of new connections, since permissions granted for a legitimate initial reason often outlive that justification without anyone revisiting them.
Do these best practices apply to self-hosted and managed MCP deployments alike?
Yes, though responsibility shifts: a managed provider may handle transport security and infrastructure hardening, but access scoping, tool permission review, and monitoring for anomalous behavior remain the deploying organization's responsibility regardless of hosting model.
How does continuous red teaming fit into MCP security best practices?
It catches vulnerabilities that static configuration review misses, since many MCP-specific risks, including confused deputy exposure and tool misuse, only manifest under actual runtime conditions rather than being visible in a server's configuration alone.
How can platforms like Akto help enforce MCP security best practices?
By continuously discovering MCP servers across an environment, running automated red teaming against this checklist's risk categories with findings mapped to OWASP MCP Top 10 and MITRE ATLAS, and enforcing runtime guardrails on live traffic rather than relying solely on point-in-time review.
Important Links
Experience enterprise-grade Agentic Security solution