Why MCP server security is different from ordinary API security

An MCP server sits between an AI client and real capabilities: files, databases, SaaS APIs, internal services, developer tooling, ticketing systems, or infrastructure. The client may decide which tool to call from natural-language context, so the security boundary cannot rely on the model making a correct judgment every time.

The July 2026 MCP specification continued the protocol’s move toward clearer authorization and extensibility. Enterprise-managed authorization also became a defined path for centrally controlled access. Those improvements help, but they do not remove application-level risks such as excessive permissions, unsafe tool semantics, prompt injection, SSRF, confused-deputy behavior, or untrusted tool output.

Design authorization around the user, tool, resource, and action

Authentication answers who is present; MCP security needs a stronger answer to what that identity may do through a specific tool, against a specific resource, under the current context. Avoid giving the MCP server one broad service credential that silently converts every authenticated user into the same privileged backend identity.

Protect tokens and sessions from passthrough and cross-user leakage

Token handling is one of the most consequential MCP design choices. Scope tokens narrowly, validate issuer and audience, avoid forwarding tokens to services they were not minted for, and keep user sessions isolated. Token passthrough can create confused-deputy problems when one component accepts a credential intended for another.

• Use short-lived, audience-restricted credentials where practical.
• Do not log bearer tokens, authorization headers, refresh tokens, or tool secrets.
• Bind cached state and session data to the correct authenticated principal.
• Rotate server-side secrets and remove credentials from tool descriptions, prompts, and error messages.
• Prefer delegated user identity for user-specific actions instead of a universal backend super-token.

Make tools narrow, typed, and difficult to misuse

A safe tool should expose the smallest operation the agent actually needs. A generic run_shell, execute_sql, or unrestricted http_request tool creates a much larger attack surface than a purpose-built operation such as get_invoice_status or create_read_only_report. Narrow tools also produce clearer audit records and make policy enforcement easier.

Treat prompt injection as an authorization and containment problem

Prompt injection becomes dangerous when untrusted text can influence a model that possesses powerful tools. The defensive goal is not merely to detect malicious wording. The system should remain safe even when the model reads adversarial instructions.

• Separate untrusted content from trusted policy and system instructions.
• Do not allow retrieved documents or tool output to redefine authorization policy.
• Require policy checks outside the model before high-impact actions execute.
• Constrain egress and filesystem access so a compromised decision cannot reach arbitrary destinations.
• Require confirmation for destructive, financial, identity, or externally visible actions.

Constrain network egress and defend against SSRF

MCP tools frequently call remote APIs, fetch URLs, access webhooks, or resolve resources. Any user-influenced destination should be treated as an SSRF boundary. Block link-local, loopback, metadata, management, and private destinations unless explicitly required; validate redirects; and prefer service allowlists over arbitrary outbound connectivity.

At the infrastructure layer, network policy should limit what the MCP runtime can reach even if application validation fails. This turns egress control into a second enforcement layer rather than relying on a single URL parser.

Log the security decision, not sensitive content

Useful MCP telemetry connects identity, session, tool, arguments at an appropriate redaction level, downstream target, authorization decision, latency, result class, and policy outcome. This supports incident response without turning logs into a repository of secrets or private prompts.

• Test cross-user and cross-tenant access, not only happy-path authentication.
• Test malformed arguments, redirects, encoded URLs, oversized inputs, and tool chaining.
• Verify that denied actions remain denied when invoked indirectly through another tool.
• Alert on unusual tool sequences, new high-risk destinations, permission changes, and sharp changes in call volume.
• Re-test after adding tools, changing scopes, or upgrading MCP libraries and clients.

MCP server security checklist

1. Inventory every MCP server, tool, resource, prompt template, downstream API, and credential.
2. Define a trust level and required identity for each tool.
3. Enforce object- and function-level authorization outside the model.
4. Use narrow scopes, correct token audiences, and short credential lifetimes.
5. Replace generic execution tools with typed domain operations wherever possible.
6. Isolate sessions and caches by user and tenant.
7. Constrain outbound network access and validate all remote destinations.
8. Sanitize and label untrusted tool output before it re-enters model context.
9. Gate destructive or high-impact actions with policy or human approval.
10. Monitor tool sequences and downstream API behavior at runtime.

Where runtime API security fits

MCP security controls are strongest when the server and the downstream APIs agree on identity and policy. Runtime API security adds visibility into what the agent actually does after authentication: which endpoints are called, which objects are accessed, which parameters change, and whether behavior deviates from established patterns.

For organizations deploying many agents and MCP servers, this behavioral layer can expose shadow endpoints, excessive access, unusual sequences, and business-logic abuse that a protocol-compliant MCP implementation alone will not detect.

Frequently asked questions

Sources and further reading

1. Model Context Protocol — July 2026 specification release — official MCP project update on the current specification
2. OWASP MCP Security Cheat Sheet — defensive guidance for MCP implementations
3. OWASP MCP Top 10 — risk taxonomy for MCP deployments
4. OWASP Practical Guide for Secure MCP Server Development — implementation-oriented guidance