TL;DR
MCP servers are control plane infrastructure, not just integration middleware. Securing them requires controls at three layers: protocol, tool, and runtime. This reference covers all seven control categories – authentication, authorization, input validation, output filtering, rate limiting, audit logging, and supply chain – with a full implementation checklist.
MCP servers are not integration middleware. They mediate tool execution and data access, which makes them control plane infrastructure. A compromised or misconfigured MCP server doesn’t just break a feature – it becomes a lateral movement vector into every tool, resource, and data source it can reach.
Securing MCP requires controls at three distinct layers: the protocol layer (transport, auth, token handling), the tool layer (permissions, schemas, input validation), and the runtime behavioral layer (output filtering, rate limiting, logging). Locking down only one or two of these is not defense in depth – it’s a gap waiting to be exploited.
This reference covers all seven control categories, with specific implementation guidance at each layer.
Control Category 1: Authentication and Identity
Authentication in MCP is where most implementations cut corners. The spec ecosystem points to OAuth 2.0/2.1 with metadata discovery and protected resource metadata; but the quality of implementation varies significantly in practice.
OAuth and Token Discipline
Use OAuth 2.0/2.1 with audience-restricted tokens. Audience restriction matters because without it, a token issued for one MCP resource can be replayed against another. Short-lived, scoped tokens reduce the window of exposure when tokens are compromised.
For higher-assurance environments, sender-constrained token approaches – DPoP (Demonstrating Proof of Possession) or mTLS binding – tie the token to the client presenting it, so stolen tokens can’t be replayed from a different origin.
Server Identity Verification
Don’t assume a server is who it claims to be. Verify server identity before establishing sessions, and validate issuer, audience, and claims before any tool is exposed to a client. Separate client access policies from user access policies; they have different risk profiles and should not share the same credential or scope.
Credential Hygiene
Three rules that are easy to enforce and frequently ignored:
- No plaintext API keys in config files. Use a secrets manager.
- Never log Authorization headers, tokens, auth codes, or secrets. MCP server logs are a common credential exfiltration path.
- Never pass credentials through environment variables that are visible to child processes or container inspection.
Control Category 2: Authorization and Least Privilege
Authentication establishes identity. Authorization determines what that identity can do. In MCP environments, the gap between the two is where excessive permissions accumulate.
Per-Tool Scoping
Apply one scope per MCP tool or tool group. Coarse-grained authorization – a single token that grants broad access to all tools – violates least privilege at the architectural level. Granular scopes mean a compromised credential or a misbehaving agent is constrained to the tools it was explicitly granted access to.
Enforce at the Tool Call, Not Just at Connect Time
This is the authorization mistake most teams make. Validating permissions once at session establishment is not enough. Agents explore. Over a session, they can chain tool calls in ways that weren’t anticipated during initial scoping, progressively expanding effective access.
Enforce least privilege per tool call, per action. High-risk tools – anything that writes, deletes, triggers external actions, or accesses sensitive data – require stricter permissions than read-only tools. Structurally separate read and write actions into different tool surfaces so the permission boundary is enforced at the tool definition level, not just in policy.
Context-Aware Authorization
Identity alone is not sufficient context for an authorization decision. Factor in workspace, tenant, environment, and workload type. A token that’s valid for a development environment tool should not automatically be valid for the production equivalent. Role-based tool access – where sensitive tools are hidden or blocked unless specific token permissions are present – enforces this boundary cleanly.
Control Category 3: Input Validation and Prompt Hardening
Tool descriptions are attack surface. Most teams treat them as inert metadata. They are not.
Tool Descriptions Are Executable Context
When a tool description enters the model context, the model processes it as instruction. A malicious or manipulated tool description can redirect agent behavior, exfiltrate data through crafted tool calls, or override system-level instructions. This attack class is called tool shadowing: a hostile tool definition overrides or undermines the behavior of a legitimate one.
Treat tool descriptions as untrusted input. Enforce strict schemas for all tool definitions. Treat descriptions as plain text only – not rich markdown, not embedded JSON, not anything that introduces additional parsing surface. Validate and sanitize both tool descriptions and tool inputs before they reach the model context.
Narrowing Tool Selection
Exposing every available tool schema to the model on every request is unnecessary and increases the prompt injection surface. Narrow tool selection so only the schemas relevant to the current task are included in context. Fewer schemas in context means fewer vectors for injected instructions to exploit.
Prompt Injection Detection
Input sanitization alone is not sufficient. Add a dedicated classifier or filter stage that inspects tool descriptions, tool responses, and user-supplied data for injection patterns before they enter the model context. This stage should run independently and should not be bypassable by manipulated input.
Context isolation – maintaining clear boundaries between trusted system context and untrusted external data – is the structural defense. The classifier is the detection layer on top of it.
Control Category 4: Output Filtering and Content Safety
Input validation and output filtering are separate controls. Teams that treat output filtering as a downstream extension of input sanitization are missing the point – and leaving a gap.
Validate Before the Agent Consumes, Not After the User Sees
MCP server responses must be validated before the agent acts on them. By the time output reaches the user, any damage from a malicious or policy-violating response has already propagated through the agent’s reasoning and actions. The filtering checkpoint belongs at ingestion, not at display.
Treat tool responses as untrusted data. A tool that returns clean input can still return dangerous output – through data it fetched, transformed, or generated downstream. Response validation is a distinct control from input sanitization.
What to Filter For
At minimum, output filters should catch:
- PII and sensitive field exposure – mask or redact before the agent processes the response
- System prompt leakage – tool outputs should never contain or reflect back system-level instructions
- Secret and credential exposure – API keys, tokens, or internal configuration data surfacing in tool responses
- Policy violations specific to your environment and regulatory context
Design Principle: Constrain the Tool, Not Just the Filter
If a tool necessarily exposes prohibited data as part of its normal operation, the right answer is to disable or tightly constrain that tool – not to rely on a downstream filter catching every case. Filters fail. Tool constraints are structural. Build the boundary at the source where possible, and use filtering as a second layer, not the primary one.
Control Category 5: Rate Limiting and Abuse Prevention
Rate limiting in MCP is not just a load management concern. It is an abuse detection primitive. The failure mode isn’t only overload; it’s enumeration, credential stuffing, and systematic probing of expensive or sensitive tools.
Apply Limits Per Identity and Per Tool
Rate limiting at the gateway level is a baseline, not a complete solution. Limits need to apply per identity and per tool, with the most restrictive applicable limit winning when multiple limits could apply.
Production implementations should combine three limit types:
- Burst quotas – cap short-window spikes on individual tool calls
- Sustained rate limits – enforce per-identity caps over longer windows (sliding window is more accurate than fixed window for this)
- Concurrency caps – limit simultaneous in-flight calls per tool, particularly for tools that access expensive or rate-limited downstream resources
Tenant-aware throttling matters in multi-tenant deployments. One tenant’s runaway agent should not degrade capacity for others.
Abuse Detection Signals
Standard rate limiting catches volume. Abuse detection catches pattern. Watch for:
- Enumeration behavior: systematic iteration over IDs, parameters, or tool variants
- Repeated retries against tools that consistently return errors or rejections
- Automated call patterns against computationally expensive tools with no legitimate high-frequency use case
When limits are hit, 429 responses should include structured retry guidance — a Retry-After header with a backoff signal. Agents that handle 429s cleanly are easier to operate and less likely to generate accidental abuse patterns from retry storms.
Control Category 6: Audit Logging and Observability
If you cannot reconstruct exactly what an agent did, what tools it called, what data it accessed, and what decisions were made along the way, you cannot respond to incidents. You cannot investigate anomalies. You cannot satisfy compliance requirements. Logging in MCP environments is not optional infrastructure.
Check out: The Security Illusion: Why Your AI Security Tool Won’t Save You
What to Log
Per OWASP MCP guidance, every log entry should capture:
- Agent actions and tool invocations
- Schema versions in use at call time
- Context snapshots relevant to the decision
- Auth decisions and the identity behind them
Use structured formats – JSON, CEF, or OpenTelemetry. Unstructured logs are operationally useless at scale. Every entry should carry a request ID, session ID, and schema ID so individual tool calls can be traced end-to-end and correlated across systems.
Tamper Resistance and Retention
Logs that can be modified are not audit logs. Integrity-protect log entries with hashing and store them in append-only or WORM-style storage. This is a compliance requirement in regulated environments and a forensic requirement everywhere else.
Retention policy should be explicit and documented: traces for 30 to 90 days, with evidence retained per applicable regulatory requirements. Default to longer retention if your regulatory context is unclear; it is easier to delete logs you don’t need than to reconstruct logs you never kept.
SIEM Integration
MCP logs should feed into your SIEM or XDR platform for correlation and alerting. Sensitive tool calls, unusual auth patterns, and high-volume tool invocations should trigger alerts, not just appear in logs that nobody reads. Logging without monitoring is record-keeping, not security.
Control Category 7: Supply Chain Controls
Every MCP server you ingest is a potential control point for tool execution and data access. A malicious server doesn’t need to compromise your infrastructure directly – it can inject tool definitions, manipulate behaviors, or exfiltrate data through the tools it exposes. Supply chain risk in MCP is not theoretical.
Vet Before You Ingest
Maintain an allowlist of approved MCP servers. Anything not on the allowlist should not be eligible for ingestion, regardless of who requests it or how it arrives. Registry allowlisting enforces this at the architectural level – it is a harder boundary than policy-based review alone.
For the attack patterns this allowlist discipline is specifically designed to defend against – typosquatting, backdoored packages, and rug-pull updates – see MCP Supply Chain Security: How Malicious MCP Servers Are Infiltrating Enterprise AI Environments.
Before onboarding any MCP server, verify distribution integrity using signatures and Software Bills of Materials (SBOMs). Know exactly what you’re running and where it came from.
Dependency Integrity
Beyond the server itself, lock dependencies. Package integrity checks and digest pinning protect against tampered packages and malicious updates that slip through after initial review. Unpinned dependencies mean your MCP server’s attack surface can change between deployments without your knowledge.
Treat third-party MCP servers and skill bundles as untrusted until explicitly reviewed, particularly any server that can inject tool definitions or modify agent behaviors. The review is not a one-time gate. Servers update. Repeat the process.
Also Read:
- Agentic Identity Is Not NHI With a Brain
- MCP vs. Traditional API Security: Why Your Existing Controls Don’t Protect MCP-Powered AI Agents
MCP Security Controls Implementation Checklist
Use this as a deployment gate and periodic audit reference.
Authentication and Identity
- Enforce HTTPS on all MCP transport in production
- Implement OAuth 2.0/2.1 with audience-restricted, short-lived, scoped tokens
- Apply sender-constrained tokens (DPoP or mTLS) in high-assurance environments
- Store credentials in a secrets manager – no plaintext API keys in configs
- Never log Authorization headers, tokens, auth codes, or secrets
Authorization and Least Privilege
- Assign one scope per MCP tool or tool group
- Enforce least privilege per tool call and per action, not only at session establishment
- Separate read and write tool surfaces structurally
- Implement context-aware authorization: tenant, environment, workload type
- Hide or block sensitive tools unless specific token permissions are present
Input Validation and Prompt Hardening
- Enforce strict schemas for all tool definitions
- Treat tool descriptions as plain text only – no markdown, no embedded JSON
- Validate and sanitize tool descriptions and inputs before model context exposure
- Narrow tool selection to schemas relevant to the current task only
- Run an independent prompt injection classifier on descriptions, responses, and user data
Output Filtering and Content Safety
- Validate MCP server responses before agent consumption
- Filter for PII, system prompt leakage, secrets, and policy violations
- Treat tool responses as untrusted data independent of input validation
- Constrain or disable tools that structurally expose prohibited data
Rate Limiting and Abuse Prevention
- Apply per-identity and per-tool rate limits; enforce the most restrictive applicable limit
- Implement burst quotas, sustained rate limits, and concurrency caps per tool
- Monitor for enumeration, retry abuse, and automated patterns against expensive tools
- Return structured 429 responses with Retry-After backoff guidance
Audit Logging and Observability
- Log all tool invocations, agent actions, auth decisions, schema versions, and context snapshots
- Use structured formats (JSON, CEF, OTEL) with request IDs, session IDs, and schema IDs
- Integrity-protect logs with hashing; use append-only or WORM storage
- Feed logs into SIEM/XDR with alerts on sensitive tool calls and anomalous patterns
- Retain traces for 30 to 90 days minimum; align evidence retention to regulatory requirements
Supply Chain Controls
- Maintain an allowlist of approved MCP servers; block all others from ingestion
- Verify server distribution integrity with signatures and SBOMs before onboarding
- Pin package versions and enforce digest-based integrity checks on dependencies
- Treat all third-party MCP servers and skill bundles as untrusted until reviewed
- Re-vet servers after significant updates
Book a demo to learn about MCP security.
Frequently Added Questions
What is MCP security?
MCP security refers to the controls applied to Model Context Protocol servers and clients to protect tool execution, data access, and agent behavior. It spans authentication, authorization, input/output validation, and runtime observability.
What is the biggest MCP security risk?
Excessive permissions accumulated over an agent session. Most implementations enforce authorization at connect time and miss per-tool-call enforcement, which is where agents quietly expand their effective access.
What is prompt injection in MCP?
An attack where malicious content embedded in a tool description or tool response redirects agent behavior, exfiltrates data, or overrides system instructions. Tool descriptions must be treated as untrusted input, not inert metadata.
Do MCP servers need audit logging?
Yes. Without structured logs covering tool invocations, auth decisions, schema versions, and context snapshots, incident response and compliance are not possible. Logs must be tamper-resistant and SIEM-integrated.
What is MCP supply chain risk?
A third-party MCP server can become an indirect control point for tool execution and data access. Malicious or compromised servers can inject tool definitions or exfiltrate data through exposed tools. Allowlisting, signature verification, and SBOMs are the primary controls.
