The Model Context Protocol is no longer only a developer convenience for connecting a local model to a few tools. The July 2026 specification formalized a stateless HTTP-oriented core, authorization hardening, an extension framework, cacheable capability lists, and header-based method/tool routing. Those changes improve production readiness—and they also make MCP something security teams need to inventory and govern as a first-class enterprise attack surface.
The MCP attack surface is a system, not one server
An MCP deployment can include desktop or hosted clients, remote servers, authorization servers, enterprise-managed authorization, tool catalogs, resources, extensions, gateways, secrets, downstream SaaS APIs, databases, browsers, and agent runtimes. A weakness in any of these layers can change what the agent sees or what it is able to do.
Client risk
A compromised or over-permissioned client can invoke many trusted servers on behalf of a user.
Server risk
A remote server may expose dangerous tools, weak authorization, vulnerable dependencies, or untrusted output.
Catalog risk
Tool descriptions and capability lists influence what an agent believes is available and appropriate.
Downstream risk
MCP often delegates into ordinary APIs where BOLA, BFLA, SSRF, and business-logic flaws still apply.
Why the 2026 protocol changes matter to defenders
The 2026-07-28 MCP specification moved the core toward stateless request/response operation and added headers such as Mcp-Method and Mcp-Name so infrastructure can route and authorize without parsing every JSON body. It also introduced authorization hardening, including issuer validation and tighter credential binding, while formalizing extensions such as Enterprise Managed Authorization.
For security teams, this creates an opportunity to apply gateway policy and observability at a clearer protocol boundary. It also means MCP traffic may appear at larger scale across ordinary HTTP infrastructure, making discovery and inventory more important.
Inventory MCP clients, servers, tools, and trust relationships
A useful MCP inventory is more detailed than a list of server URLs. Security teams need to know which client can reach which server, who authorizes the connection, which tools are exposed, what credentials the server can use, which downstream systems are reachable, and whether actions are read-only, reversible, or high impact.
| Inventory object | Record at minimum |
|---|---|
| MCP client | Owner, user population, runtime location, connected servers |
| MCP server | Operator, URL, environment, auth model, data classification |
| Tool / resource | Action type, downstream target, sensitivity, write capability |
| Credential | Issuer, audience, scopes, owner, lifetime, storage location |
| Extension | Capabilities added, trust boundary, update source |
Treat MCP servers and extensions as software supply chain
MCP makes it easy to add capabilities, which also makes it easy to add trust. A new server can bring dependencies, update mechanisms, network destinations, tool descriptions, authentication code, and downstream credentials. Review provenance and permissions before connection, and monitor changes afterward.
- Pin and review server packages or container images where practical.
- Separate development/test MCP servers from production identities and data.
- Use narrow egress and downstream credentials.
- Detect new tools, changed tool schemas, or expanded scopes.
- Remove abandoned servers and revoke their tokens.
- Treat third-party tool output as untrusted content even when the server is approved.
Prompt injection becomes more dangerous when tools are powerful
MCP does not create prompt injection, but it can increase its impact by connecting model decisions to real tools. A malicious webpage, document, ticket, database record, or tool response may influence the model to select a legitimate tool for an illegitimate purpose.
The durable defense is containment: policy outside the model, narrow tool semantics, constrained network access, and approval for destructive or externally visible actions. The environment should remain safe even when model reasoning is manipulated.
Use gateways to make MCP observable and governable
The current protocol gives gateways useful routing and policy signals. Organizations can use an MCP-aware gateway or equivalent control plane to authenticate connections, apply rate limits, log server/tool usage, restrict destinations, and enforce coarse policy before traffic reaches the server.
Gateways still do not know every business rule. Object ownership, tenant entitlements, sensitive-field policy, and state transitions belong in the downstream service or dedicated authorization layer.
Runtime behaviors worth monitoring
- A client connects to a new MCP server outside the approved inventory.
- A server suddenly exposes new or renamed high-impact tools.
- One user invokes a tool across many tenants, accounts, repositories, or records.
- A read-heavy workflow unexpectedly transitions to write, delete, send, or admin actions.
- An MCP server reaches new external destinations or cloud-management endpoints.
- Tool-call volume or error patterns change sharply after an update.
- Credentials begin appearing across multiple issuers, audiences, or environments.
A practical enterprise MCP security program
- Discover MCP traffic, servers, clients, extensions, and tool catalogs.
- Classify tools by data sensitivity and action impact.
- Centralize authentication and lifecycle management where possible.
- Enforce per-tool and downstream object/function authorization.
- Constrain credentials, filesystem access, execution, and network egress.
- Route remote MCP traffic through observable policy points.
- Monitor tool sequences and API behavior at runtime.
- Continuously review new servers, tool changes, and protocol upgrades.
Frequently asked questions
Why is MCP an emerging attack surface?
MCP connects AI clients to external tools, data, and actions. As deployments move to remote and enterprise-scale infrastructure, the attack surface spans clients, servers, OAuth, tool catalogs, extensions, credentials, and downstream APIs.
Did the 2026 MCP specification improve security?
Yes. The July 2026 release included authorization hardening, issuer validation, credential isolation changes, and infrastructure-friendly method/tool headers. Those improvements reduce protocol risks but do not eliminate unsafe tools, weak application authorization, prompt injection, or supply-chain risk.
What should enterprises inventory for MCP?
Inventory clients, remote servers, tools, resources, extensions, identities, credentials, downstream APIs, data classifications, and who owns each connection.
Is an MCP gateway enough?
No. A gateway can provide authentication, routing, rate limits, and observability, but downstream services still need object-, property-, and function-level authorization.
How is this different from MCP server security?
Server security focuses on hardening one server. An attack-surface view governs the entire ecosystem: clients, server discovery, enterprise authorization, tool catalogs, third-party servers, gateways, extensions, and downstream services.
Sources and further reading
- MCP Blog — The 2026-07-28 Specification — current specification changes including stateless core and authorization hardening
- MCP Blog — Enterprise-Managed Authorization — stable enterprise authorization extension
- MCP Blog — The New MCP Roadmap — August 2026 roadmap and enterprise direction
- OWASP MCP Security Cheat Sheet — defensive implementation guidance
Protect APIs with runtime context, not just static rules
Ammune helps security teams discover APIs, understand normal behavior, detect abuse and authorization anomalies, and apply runtime protection across modern API environments.