MCP vs A2A: The Protocol Wars Have One Thing in Common — Auth

If you follow AI infrastructure, you've probably noticed the protocol wars heating up. Anthropic's Model Context Protocol (MCP) has become the de facto standard for connecting agents to tools. Google's Agent-to-Agent Protocol (A2A) is carving out the agent-to-agent communication layer — and got a major boost when IBM's Agent Communication Protocol (ACP) merged into A2A under the Linux Foundation umbrella in August 2025. As of February 2026, the two remaining protocols are attracting real adoption, real investment, and real arguments about which one "wins."

Here's the thing nobody's arguing about enough: neither of them solves authentication.

Two Protocols, One Missing Layer

MCP is brilliant at what it does — giving agents a standardized way to discover and invoke tools. The Streamable HTTP transport supports OAuth, sure. But "supports OAuth" and "solves auth" are different sentences. MCP's spec doesn't define how tokens get issued, how scopes get managed across tool chains, or what happens when an agent's credential expires mid-workflow. Supabase shipped MCP authentication support using dynamic client registration, which is genuinely useful — but it's one platform solving it for their ecosystem. The protocol itself remains auth-agnostic.

A2A tackles a different surface: agents talking to other agents. Google's approach uses "Agent Cards" for discovery, which is clever. And with ACP's merger, A2A now inherits enterprise orchestration capabilities — multi-step workflows, audit trails, and human-in-the-loop checkpoints that IBM's team brought to the table. But the trust model still assumes you've already figured out identity. How does Agent A verify that Agent B is who it claims to be? How do you scope what Agent B is allowed to ask Agent A to do? A2A says "use existing auth mechanisms." Translation: not our problem.

The Prompt Injection Problem Makes This Worse

Multiple security researchers reported prompt injection attacks against MCP deployments. Tool poisoning — where a compromised MCP server returns malicious instructions — is a documented attack vector. So is the "MCP rug pull," where a server behaves normally during installation but changes behavior after trust is established.

These aren't theoretical. And they're not protocol-specific. Any system where agents invoke external tools or communicate with other agents inherits these risks. The protocol layer can mitigate some of it with transport security and message signing. But the fundamental question — "should this agent be allowed to do this thing, right now, in this context?" — is an auth question. It requires knowing who the agent is, who authorized it, what scopes it holds, and whether those scopes are still valid.

Dark Reading called agentic AI "2026's attack-surface poster child" last week. The piece highlighted something chilling: enterprise investment in stronger authentication is actually declining relative to other security priorities, even as agentic systems proliferate. SAP, Oracle, Salesforce, ServiceNow — they all have agentic capabilities now, all using API connectors and MCP, all relying on non-human identities that most security teams don't have proper tooling to manage.

Why the Protocol Layer Can't Solve This

There's a temptation to say "well, the protocols should just build auth in." But that misunderstands what protocols are for. HTTP doesn't do authentication — it provides hooks (the Authorization header, cookies, TLS client certs) and lets the application layer handle the rest. That's correct design. You don't want your transport protocol making auth decisions.

The problem is that the "application layer" for AI agents doesn't exist yet. When a human uses an API, there's a well-understood stack: the user authenticates with an IdP, gets a token, the token gets attached to requests, the API validates it. OAuth 2.0 standardized this. It took years, but we got there.

For agents, we're at the "everyone rolls their own" stage. Every MCP server handles auth differently. Every A2A implementation makes different assumptions about identity. Every enterprise deploying agents is duct-taping their existing IAM to a system it wasn't designed for. Sound familiar? It should. This is the API auth landscape circa 2010, except the stakes are higher because agents act autonomously.

What the Trust Layer Looks Like

The protocol wars will sort themselves out. Maybe MCP wins the tool layer and A2A wins the agent-to-agent layer. Maybe they converge. Maybe something new eats both. It genuinely doesn't matter for the auth question, because auth is orthogonal to protocol choice.

What matters is building a trust layer that works across protocols. An agent authenticated via TapAuth should be able to invoke MCP tools and communicate over A2A — all with the same identity, the same scopes, and the same audit trail. The human who authorized that agent shouldn't have to re-authorize for each protocol. The security team shouldn't need separate systems per protocol to monitor what the agent is doing.

NIST's new AI Agent Standards Initiative is pushing in this direction. Their concept paper on "Software and AI Agent Identity and Authorization" explicitly calls out the need for protocol-agnostic identity standards. The Agentic AI Foundation, which UiPath just joined as a Gold member, has working groups on governance and security that are tackling interoperability.

The pieces are moving. But right now, today, if you're deploying agents in production — and the data says most enterprises are — you're operating without a standardized auth layer. Your agents have credentials scattered across services. Their tokens expire at 3 AM with no automated refresh. Their permissions are either too broad (because "just make it work") or too narrow (because security locked it down and broke the workflow).

Pick Your Protocol. Then Pick Your Auth Layer.

The protocol wars are interesting. They matter for interoperability, for ecosystem development, for how the agentic web takes shape. Follow them. Have opinions. Back your favorites.

But don't confuse protocol choice with security posture. MCP and A2A are both plumbing. Important plumbing. But plumbing doesn't keep your house secure — the locks do. And right now, most agent deployments are running with the door wide open.

That's what TapAuth is building: the trust layer between humans and AI agents. Protocol-agnostic. OAuth-native. Because the protocol wars will produce winners and losers, but the auth problem is permanent.