Gartner predicts 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in January. The firm named agentic AI oversight its top cybersecurity trend for 2026, flagging identity registration and policy-driven authorization for machine actors as a specific area enterprises are underprepared for.
That's the backdrop for every Model Context Protocol (MCP) deployment decision a CTO is making right now. The protocol connecting these agents to real systems has an authentication story that's still being written, in the form of spec revisions arriving every few months.
How MCP's auth model actually got here
The official MCP specification changelogs show five distinct stages, not one big security fix:
Version | What changed on auth |
2024-11-05 (launch) | No authorization framework. Auth was left entirely to implementers. |
2025-03-26 | Added a comprehensive authorization framework based on OAuth 2.1. |
2025-06-18 | Classified MCP servers as formal OAuth Resource Servers; required Resource Indicators (RFC 8707) to stop malicious servers from obtaining tokens meant for other services. |
2025-11-25 | Added OAuth Client ID Metadata Documents (CIMD) as a recommended registration method, alongside Dynamic Client Registration (DCR). |
2026-07-28 | Deprecated DCR in favor of CIMD; required clients to validate the iss parameter (RFC 9207); called the largest revision since launch. |
MCP shipped with zero authentication requirements and has spent every revision since adding rigor back in. Any server built in the first year likely carries assumptions the spec has already moved past. The direction is consistent: toward formal OAuth patterns and away from lightweight, implementer-chosen registration.
What OWASP and the NSA are warning about
The OWASP MCP Top 10 ranks token mismanagement and secret exposure as its highest-priority category: Hard-coded credentials and secrets stored in model memory can expose entire connected environments, often retrievable through prompt injection.
The NSA's May 2026 guidance makes a point worth sitting with, as mapped against the OWASP list: Only two of OWASP's ten risk categories live in the text an agent reads and acts on. The other eight, including credentials, scope, and identity, sit in infrastructure the protocol places no built-in constraints on at all. MCP standardized how agents discover and call tools. It never standardized how you prove who's calling or what they're allowed to touch.
The blast radius is real
Palo Alto Networks' Unit 42 measured what happens at realistic scale: Connecting five MCP servers to a single AI agent produced a 78.3% attack success rate in their testing. Five connected servers isn't an edge case, it's a normal week for any team past a single proof of concept.
The mechanism is cascading trust. Once an agent treats one server's output as trustworthy context, a compromised server can inject instructions that ride along into every subsequent tool call, including calls to servers that were never themselves compromised.
Two deployment scenarios, two different postures
Internal tool, behind the firewall. Lower exposure, but not zero. Microsoft's own internal MCP governance, described in its Inside Track blog, issues short-lived, least-privilege tokens even for internal-only traffic, on the reasoning that internal isn't the same as trusted.
Remote server or multi-tenant SaaS exposing an endpoint to customers. Highest stakes. Microsoft's Azure guidance recommends an identity-aware gateway that rejects any call lacking a valid, audience-bound token, plus a registry that pins tool definitions so a “rug pull,” a trusted dependency silently changing behavior, gets caught by drift detection instead of discovered in production.
Dos and don'ts
Do:
Treat every MCP server as an OAuth Resource Server that validates tokens, the spec's own direction since June 2025
Scope tokens narrowly and keep them short-lived; Microsoft's guidance specifically warns against granting “full mailbox access where read-only would do”
Validate the iss parameter now, ahead of it becoming mandatory
Don't:
Assume DCR is a safe long-term bet; it's formally deprecated as of July 2026
Cache credentials at server startup instead of pulling them at call time; a token living in process memory can't be meaningfully revoked
Wire up a new MCP server without registering it somewhere governable
Centralized or per-server: The enforcement question
Per-server enforcement | Identity-aware gateway | |
Consistency across servers | Depends on each developer | Uniform by construction |
Detecting a compromised server | Only if that server logs well | Gateway can pin tool definitions, alert on drift |
Best fit | A single internal tool | Any deployment past a handful of servers |
Microsoft and the NSA converge, independently, on the same answer: Push identity, scope, and audit logging to a layer in front of every server, rather than trusting each one individually.
Build for the direction, not the snapshot
The MCP authorization model has changed in every revision since launch, and more hardening is already signaled. What's stable is the direction: Formal resource-server patterns, explicit issuer validation, and centralized governance over ad hoc trust. For a CTO deciding how to wire up the next MCP integration, that gap between deployment speed and identity governance is the actual project, not a footnote to it.
Nilay Dhamsania is an AI Strategist and Director at Intuz
Welcome to the VentureBeat community!
Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise.
Read more from our guest post program — and check out our guidelines if you’re interested in contributing an article of your own!