Understanding the Shifting Protocols That Secure AI Agents

New AI protocols are being adopted faster than most security teams can meaningfully assess their authentication and authorization models. MCP, A2A, and AP2 are reshaping how agents interact, but the identity layer underpinning them remains uneven and, in some cases, immature.

Each of these protocols promises to standardize a slice of the agentic AI ecosystem. Some of them (MCP, specifically) have seen unprecedented adoption because they really do work. Today, underneath the branding wars and tech partnerships, a genuine architecture is forming where enterprise AI use cases are finally valid and monetizable.

However, the authN/authZ model is still in its infancy, and the whole proposed stack is in dire need of demystification. If you, like me, are tired of struggling to track the rapid expansion of new AI protocols and just want some straight answers about what’s working (and what isn’t), you’re in the right place.

Let’s look at the “greatest hits” of AI protocols, dissect the underlying auth standards, and generate an honest assessment of where all this is really going.

MCP Makes Agents “Agentic”

When the whole AI gold rush kicked off, the definition of an agent was far more ambitious than today. In fact, it was borderline AGI: a fully autonomous, thinking agent that could freely act and reason on its own. Today, “agentic” is applied a bit haphazardly to any LLM and tool combo you can think of. You can thank the Model Context Protocol (MCP) for that: Claude Desktop plus MCP equals agent in 2026.

Since its release as an open protocol in late 2024, MCP has become the de facto standard for connecting AI models (i.e., LLMs) to external tools and data sources, and its adoption is nothing short of explosive. We’re talking OpenAI, Google, Microsoft, and countless developers across a burgeoning ecosystem filled with tens of thousands of servers. Admittedly, MCP is still a hyper-dev-focused concept, and many servers are built by and for engineers (i.e., self-made for personal use) rather than end customers.

As genuinely cool as the so-called “USB-C of AI” may be, the security picture is less tidy. Many MCP servers act as thin wrappers around powerful tools, expanding the attack surface and introducing risks such as remote code execution and tool poisoning (a variant of prompt injection). Because the ecosystem is decentralized and lightly vetted, enterprises must evaluate not only the model but also every connected tool endpoint. The auth spec, which has mandated OAuth 2.1 with PKCE from the start, is maturing. But basing your brand new protocol’s security on what’s essentially the nightly build of OAuth leaves room for unpredictability. 

A2A Gives Agents to Other Agents

Google’s Agent-to-Agent (A2A) protocol launched in April 2025, and it’s like an “agent teamup” add-on to MCP. While MCP connects agents to tools (vertical), A2A standardizes how they discover and collaborate with each other (horizontal) across different frameworks (CrewAI, LangChain, LlamaIndex, etc.). In practice, an orchestrator agent delegates subtasks to specialists; if the task is generating a vacation package, one handles flights, another lodging, the next one activities, and so on.

From a security perspective, A2A is tougher to critique because it mostly relies on what you’ve already got. It supports Bearer tokens, API keys, mTLS, and other methods declared via Agent Cards. It’s pragmatic and reflects the uneven boundaries that agents in these scenarios will traverse. But it also means the weakest link in the chain is the effective security posture for the entire workflow. 

AP2 hands agents your wallet

When agents start spending money, it ups the ante considerably. That’s both in terms of risk and potential revenue for companies that buy in. AP2, the Agent Payments Protocol, launched in September 2025 with over 60 backers, including Mastercard, PayPal, AmEx, and Salesforce. AP2 tackles the fundamental problem of an online ecosystem that expects “hands-on keyboard” users, not agents acting on their behalf.

The root of the issue is that payment systems were designed for humans clicking “buy.” When an agent acting semi-autonomously initiates a transaction, existing assumptions about authorization and accountability basically collapse. 

AP2’s solution is cryptographic “mandates” (W3C Verifiable Credentials). Intent Mandates capture what the user authorized, Cart Mandates record what’s being purchased, and Payment Mandates carry transaction context to payment networks. The protocol extends both MCP and A2A rather than being standalone. This approach is architecturally sound but means AP2’s security inherits the strengths and weaknesses of whatever sits above or beneath it. 

The Overlooked Auth Layer

Every protocol above ultimately depends on OAuth. That’s for good reason: OAuth already supports M2M communication, scoped access, token-based delegation, and fine-grained authorization (FGA). The practical challenge is that OAuth is genuinely difficult to implement correctly without a lot of time, expertise, and debugging. And agentic use cases push it into unfamiliar territory.

Function-level scoping (controlling access to individual tools, not just endpoints) doesn’t map cleanly to traditional role-based access control (RBAC). Similarly, client registration called for developers to invoke niche methods to resolve the new agentic frontier: first DCR, now CIMD. Both have proven useful in various contexts, but there’s still room for improvement.

Dynamic Client Registration (DCR)

Dynamic Client Registration (DCR) automates the OAuth handshake so agents can obtain credentials at runtime. Previously, it was the only viable option for MCP anything, and it remains a solid choice if you can control the environment where it happens. But DCR’s open registration endpoints present a genuine attack surface that’s vulnerable to abuse. It’s also prone to accumulating stale entries that become security debt or simply take up unnecessary space.

Client ID Metadata Documents (CIMD)

Client ID Metadata Documents (CIMD) represent the emerging alternative. A client’s identity becomes an HTTPS URL pointing to hosted JSON metadata. Trust is established through domain ownership, with no persistent registry and no open endpoint to abuse. The latest MCP auth spec adopts CIMD as the recommended default, with DCR preserved for appropriate scenarios. Most production deployments, as far as the enterprise is concerned, will likely run both.

CIMD isn’t without tradeoffs. It requires metadata hosting, caching strategies, and domain verification. That means it’s more complex to implement, but it’s still better aligned than DCR with open ecosystems where unknown clients are the norm. 

Stay Skeptical About Securing Agentic Identities 

The agentic protocol stack, auth and all, is here. It’s early, but it’s maturing quickly and will reshape how AI interacts with the world. MCP for tools, A2A for collaboration, AP2 for commerce, and auth layers for the essential security plumbing. Each role is clear, but every touchpoint introduces trust scenarios that most organizations haven’t even started building for.

Don’t wait for the protocols to stabilize before thinking about how you’ll secure them. The adoption curve is exponentially outpacing the security tools available, and that’s exactly the kind of gap threat actors gleefully exploit. Ignore the alphabet soup of acronyms, announcements, and accelerationist hype; instead, understand the stack underneath it.

Test auth at every layer. Be deeply skeptical of any protocol that doesn’t rely on proven security modalities. And don’t trust an agent that can’t prove exactly who it is, who it’s working for, and what it’s been authorized to do.