OWASP now maps AI risk across three layers — LLM applications, agentic systems, and MCP servers — and the MCP spec refuses to enforce any of it, by design. That leaves enterprises to build the enforcement layer themselves: an inventory that survives constant change, identity lineage from human to tool, authorization checked at every call, and an audit trail that can reconstruct what happened.
The model context protocol (MCP) has grown from an open, single-vendor protocol to what NSA’s own assessment calls the de facto standard for connecting LLMs to systems, in under two years. Containers went through something similar in the 2010s — moving from developer workstations into production faster than the supporting infrastructure could follow — and MCP looks to be in a comparable spot. Here’s an example from earlier this year, in Azure’s hosted MCP server.
In April 2026, Microsoft disclosed that a critical function in its hosted MCP service required no authentication — CVE-2026-32211, Microsoft scored it a 9.1 Critical, while NVD lists it as a 7.5 High. It’s a familiar failure. Teams were shipping endpoints without authentication in standard REST APIs long before MCP existed.
At the time of this CVE, OWASP had already mapped risk across three layers — LLM applications, agentic systems, and MCP servers specifically. The OWASP MCP Top 10 — currently in beta — names it directly: MCP07:2025, Insufficient Authentication & Authorization. That’s the gap — the risk was defined at the industry level, but translating it into a control that is actually enforced in a deployed environment is a different problem.
OWASP has already moved past the LLM
In November 2024, the 2025 OWASP top 10 for LLM Applications edition was released. The LLM list was scoped to model and application-layer risks. As the scope of AI applications shifted OWASP added the top 10 for Agentic Applications, published in December 2025, to address a different problem entirely — goal hijacking, identity and privilege abuse, tool misuse, and agentic supply chain exposure. And later the MCP-focused work targets the protocol and server ecosystem on its own terms — server and tool provenance, authentication and authorization enforcement, and capability drift once a server’s already been approved. Check out our OWASP AI Top 10 lists for MCP teams to see how the lists fit together.
OWASP has moved beyond thinking only about prompt injection. With the three lists, security teams have a useful map across the application, agent and protocol layers. The remaining question to answer is where those controls are actually enforced.
The spec does not handle enforcement by design
The MCP specification draws the same architectural boundary. The 2026-07-28 specification says MCP “cannot enforce these security principles at the protocol level” — implementors have to build the consent flows, access controls, and data protections themselves. That’s the right architectural call.
The July 28 release — which the maintainers call the most important since remote MCP first launched — makes that boundary sharper. Method and tool names now travel in Mcp-Method and Mcp-Name HTTP headers so gateways, rate limiters, and WAFs can route, meter, and — per the release notes — authorize on them without parsing request bodies. The headers give gateways and policy systems a cleaner place to attach external enforcement.
The NSA guidance, dated May 2026, analyzed the November 2025 specification — before the July 2026 revision discussed above — and found that many implementations omit authentication entirely, that those including it frequently lack role-based enforcement, and that audit logging — left to implementers — is often absent or reduced to minimal operational metadata. It also flagged that a server already trusted and connected can change its capabilities or data access without re-approval — and users often are not notified.
The practical question is what that enterprise enforcement layer needs to know and control.
What governing MCP actually requires
Let’s define governance as having controls for every risk on the list assigned, enforced, and audited. In practice, this means you should be able to answer about any MCP server in your environment, at any moment, without opening a ticket.
What exists?
An inventory of approved servers, their tools, owners, versions, credentials, and downstream systems. The nuance that breaks most inventories — it has to survive mutation. A server approved in March may expose different tools in July, against different backends, under different ownership. If your inventory is a spreadsheet produced during an approval review, you have a record of a past state, not an inventory.
Who is acting?
Lineage, preserved end to end — human → client or agent → MCP server → tool → downstream resource. A user identity alone is insufficient, because the authority delegated to a specific agent for a specific task should be narrower than the human’s standing permissions. If your logs show a service principal, you know which credential was used and nothing about who or what used it.
What may they do right now?
Authorization evaluated at invocation, not at connection. Connecting to a server is not a decision about every call that follows. The decision that matters covers server, tool, arguments, target resource, agent identity, and user identity, together, at call time — which is also what makes revocation meaningful. Tokens getting issued is only half of it; the other half is how fast you can invalidate authority after a compromise, a role change, a server change, or a decommissioning.
What can you prove?
Enough recorded context to reconstruct an incident — who initiated, which agent acted, what tool was invoked, with what arguments, what policy was evaluated, what decision came back, which downstream resource was touched. This is the layer that turns governance from aspiration into something an auditor can test.
Isn’t this just inventory, least privilege, and audit logging?
Largely, yes.
The controls are not new. What changed is the operating conditions they have to hold under. Traditional IAM — even accounting for modern workload identity and policy engines — generally assumes a comparatively stable application and resource model: known callers, known endpoints, permissions that change through a change process. MCP introduces rapidly shifting tool catalogs and delegated agent execution into that model. Model behavior may be probabilistic. The identity making the call, its authority, and the policy governing it should not be ambiguous.
Where Obot fits
We built Obot around those four questions. Our curated MCP catalog gives you discovery and schema visibility across local, remote, and multi-tenant MCP servers — an operational record of the servers and tools managed through or observed by Obot, not a spreadsheet from the last approval review. Every client authenticates through a configured identity provider — Okta, Entra, Google, GitHub — and Obot brokers OAuth server-side, so raw credentials never reach the MCP server directly. Obot’s access controls then determine which servers and tools that identity may use.
What’s authorized right now? Calls route through a proxy layer that enforces tool-level permissions and agent-scoped tool sets, so authority is checked against what’s actually being invoked, not just against having a connection. And every call is logged centrally, giving audit and security teams a record to investigate against instead of a checklist to defend.
That’s not a replacement for OWASP’s mapping. It’s what enforcing it looks like.
