A New Agent to Agent Communication 'Protocol' Enters The Ring

For a while now we've had Model Context Protocol and there's been a lot of valid criticism laid at is feet. The running joke appears to be 'should it just die'? Well what if it did? What other standards exist that would allow for complex agent integrations to exist?

Have you ever used multiple agents in tandem over the internet and thought "wow, this is probably really insecure but Imma do it anyway"?

Now imagine you had absolutely no control over the 'other agent', but in order to Get Stuff Done, that's what you had to do. This is the world in which we are ushering by encouraging the latest fad of Agentic Agents doing Agently things.

This is the lens that I would like to explore these standards through... what happens when we implement them badly? Because we will.

How was the internet built anyway, Unc?

The world of the internet has for the longest time been defined in humble text files. Everything from TCP/IP to DNS and even protocols for brewing coffee remotely exist in these text files. They start out as theoretical pieces, that slowly crystallize over time into real software that you and I use today. I personally find them fascinating to study, both new and old.

The Internet Engineering Task Force (IETF) has been the custodian over these definitions since well before the World Wide Web was even but a twinkle in Tim Berners-Lee's eye. The Request For Comments or RFC document is the delivery mechanism for much of the fundamental engineering that makes up the internet as we know it.

On March 2, 2026, a new draft RFC landed: "AI Agent Authentication and Authorization"

Arguably, it is one of the more important attempts at defining how the constellation of authn/authz ideas should and might coalesce in the future. While it isn't pitched as a standard (yet), it is being floated to consolidate the ecosystem and elicit discovery of any gaps.

It is written by people from AWS, Zscaler, Defakto Security and Ping Identity, so one could presume it comes with some experience behind it.

Although, we should never underestimate the ability of nerds to get over-excited about specifications. I have lived the SOAP life and am old enough to remember the WS-* years. XSLT anyone? That felt like a proper fever dream. I don't want that again. Is this going to be the same?

TL;DR

Thankfully what is going on bears no relation to WS-* as best I can tell. I put 'protocol' in inverted commas in the title above, because this paper basically argues that we have all the pieces of the A2A puzzle already, and we simply need to start using them. That said, there are a lot of new concepts (to me, at least). I will list them first with sources and then dive into what the acronyms mean.

The foundational pieces proposed are:

• WIMSE/SPIFFE identifiers
• OAuth 2.0 identity chaining via Transaction Tokens (for delegation)
• mTLS with short-lived SVIDs for authentication

Exhausted yet? Me too. But let's press on, because where there are complex systems, there are opportunities for flaws, bugs and exploits.

A2A: Service Discovery for a Gen Alpha World

Parallel to this draft RFC is a specification called A2A protocol (Agent 2 Agent). This was built by Google in April 2025 and is now living in the Linux Foundation.

A2A doesn't talk about identity much at all. Every agent publishes an 'Agent Card' on .well-known/agent.json listing its skills and other endpoints. It lists any supported authorization flows, and clients optionally may obtain short-lived OAuth/OIDC tokens that are scoped per task.

However, authentication isn't defined in this standard in strict terms, only allowing for optional mechanisms, leaving authn an open question.

To summarize, A2A is about defining a schema for agent discovery (the agent card) and a task lifecycle protocol but leaves the identity issue alone, which is where the RFC becomes relevant.

Sounds kind of spiffy!

As with all things on the net, we need an address. A "Uniform Resource Identifier" if you will. To this end, two standards have emerged, WIMSE "Workload Identity in Multi-System Environments" and "Secure Production Identity Framework for Everyone" (SPIFFE).

The URI is important as a way for multi-agent systems to distinguish each other, and SPIFFE also takes care of identifying particular workloads, and their execution contexts. This becomes important later.

All we really need to know at this point is that an agent operating in this version of standards hell, must have a WIMSE, and that WIMSE may be a SPIFFE.

Let's Take a Deep Breath (LTDB) and remind ourselves that Acronyms Suck Sometimes.

So imagine we have a lovely little robo-helper, let's call him Agent Bob. He publishes his own Agent ID card at his address, and lists ways in which he can help or be helped. All that is left is that elusive piece: how do we know that Agent Bob, or his neighbour-robo-helper, let's call her Agent Alice, is who they say they are?

Enter Mutually Assured D̶e̶s̶t̶r̶u̶c̶t̶i̶o̶n̶ Transport Layer Security

So according to this draft, it is mTLS to the rescue for determining authenticity. If Agent Bob is to engage Agent Alice's help, they will need to be introduced in holy matrimony via an x.509 certificate binding ceremony known as mTLS or Mutual Transport Layer Security.

However it's not as simple as agreeing on an x.509 certificate. Remember I mentioned that SPIFFE identifies workload execution? It does this in order to reduce risks of compromised certificates, by issuing "Short-Lived SPIFFE Verifiable Identity Documents" or SVIDs. These SVIDs need to be validated before any Agentic Action may be, um, actioned upon.

At this point I am throwing a chair at the next person who makes a new acronym.

But wait! There are more acronyms!

The astute reader may note that in order for any of this to work, agents would need real-world credentials as we already know them, to do anything important behind the scenes! And you'd be right, dear astute reader.

How would existing enterprisey systems provision new identities from places like Entra ID or Active Directory? Via SCIM, of course, which will need an extension also defined as an IETF draft to define an 'Agent' resource type, and allows us to assign human owner(s) to our robo-clanker-pals.

If this wasn't whimsical enough...

Further to the question of how humans might bind their identities to those of agents, is the WIMSE Applicability for AI Agents specification. This specification defines requirements around automating credential management and maintaining the principle of least privilege when it comes to access tokens and workflow management.

Where the battleground of ideas truly lies though, is in defining OAuth extensions that would support you as a human to quickly authorize an agent to act on your behalf.

There are multiple competing drafts for these OAuth extensions from China Mobile and Huawei. This makes some sense that mobile phone manufacturers and technology companies in general would love for us to authorize agents in the same way that we authorize Facebook to login to stuff, they can then set about deriving huge economies of scale and do more vertical integration shenanigans, for example.

China Mobile's solution appears to define three operational modes where agents could:

• operate on a human's behalf
• operate on their own behalf
• operate on another agent's behalf

It also covers integration with Model Context Protocol (MCP) servers or other forms of agentic API proxies.

This raises concerns about long chains of delegation that the average human simply has zero visibility over.

Where there is complexity there are bugs to be found

I think the main areas of implementation that will start to appear in 2026+ will be along these lines.

It's agents all the way down

What happens when Agt. Bob asks Agt. Alice to ask Agt. Cody to ask Agt. Derek to do something on my behalf? Transaction Tokens and identity chaining are proposed as answers to this problem, but there's little activity on implementing any of this. Implementations will have to sort out this UX problem as much as the technical one. How do we avoid confusing the everyday user? How do we get past consent fatigue issues for example?

Provisioning is only a small slice of the agent lifecycle

Lifecycle governance: the SCIM extensions cover provisioning, but what happens in terms of runtime enforcement beyond that? Conditional access and behavioural anomaly detection for agents is still an open question.

Federated identity

Cross-domain federation via WIMSE/SPIFFE token exchange in theory allows for agents on disparate cloud providers to work together; however, those CSPs have very little incentive to work together. As soon as they do, they might invite a customer churn scenario that I'll discuss below.

Human out of the Loop scenarios

Despite a lot of legal pull towards 'Human in the Loop', the tech companies seem to be converging on 'Human very much out of the Loop' type ideas.

(HvmootL? I made that one up... guess I get the chair!)

Doing Agent to Agent trust well, without human bootstrapping, is the 'how do we do OpenClaw, but secure this time?' question.

These standards all assume a human always initiates the OAuth dance. We simply can't have a secure OpenClaw without truly solving this problem. For this to work, agent workload attestations of some kind are needed to replace the human consent steps.

This is scary territory when you think about it for any length of time, the mind boggles what this would even be used for?!

I guess, to help with that thought experiment, here are some ideas to get you started.

1. Multi-cloud cost arbitrage... but now with automated workload migration: e.g. an agent monitoring AWS cloud expenditure autonomously negotiates with a GCP broker agent to migrate workloads based on real-time pricing. While this sounds great, this is the scenario I alluded to earlier: CSPs probably don't want to enable this idea at all because it would turn their pricing into a true commodity auction where agents are buyers. This kind of 'forex for cloud workloads' seems like an existential threat to them, rather than a feature IMO.

2. Incident response swarms: a detection agent identifies lateral movement and spins up forensic collection agents across those environments and isolates them within seconds of detection, in preparation for a human team of DFIR specialists to get involved.

Who would actually want any of this?

While the above might sound cool to some, I'm still on the fence if we truly want that. This new draft RFC draft-klrc-aiagent-auth-00 emphasises trust domains and that agents in different trust domains should not automatically trust each other. However the gap is that at some point in this post-agentic world people now want cross-domain trust to occur. How that gets established is an implementation detail, and this is where security vulnerabilities live.

Now consider that the very people consuming this otherwise high quality set of standards could very well vibe-code large portions of their proprietary implementations. The initial quality ramifications may lead to some catastrophic scenarios.

Standards implemented badly are the norm

Consider what happens if this dance is incorrectly implemented: Agent Bob is compromised, it has a valid workload attestation. Via that attestation, it establishes trust with Agents Alice, Cody and Derek across 3 different trust boundaries.

In an enterprise scenario this could result in some bad outcomes, e.g. the microsoft teams <=> salesforce agent trust is abused leading to exfil via a third agent that had teams trust. All horrible stuff. It's not new, but it could happen a lot faster.

What I suspect is going to happen is a mass influx of agents into everything. I remember when the first internet fridge hit the scene and how absurd that sounded? Smart fridges are a whole product category now.

I don't necessarily want any of this to happen but two things are true.

1. The fad of IoT devices is the example we need to recall.
2. Agent and API integration just became very cheap to achieve.

Cars is probably the worst scenario I can think of. It's already happening too, car manufacturers are thinking about getting the right hardware into the cars to run AI workloads today

McLaren just announced their intention to sprinkle agentic fairy dust into their 'entire engineering lifecycle', so its probably only a matter of time there too.

If tech companies actually usher in an HvmootL Agent-to-Agent reality like this, these problems really do need to be solved.

Let's take this to an absurd outcome, imagine A2A protocols are in place, and your car still can install apps from an appstore like it has been able to for a while.

You have an agent embedded in the infotainment unit, and one for commanding the body control module too. Now imagine they're internet enabled and can optionally order you a pizza while you are driving, that agent has access to a payment token. Heck there could even be connectivity direct to the DMV to allow you to pay your vehicle registration and license renewal.

A single dodgy application installation could theoretically leverage that entire chain of trust to lock your doors, steal your identity, and demand you authorize a payment to a ransomware team. It's a sobering thought.

OK so we've seen all these standards that exist independently of MCP, does that now mean that MCP is redundant? Should it just die and let the IETF drafts take over?

Where is MCP in all this?

Not quite, at least, not for this reason. MCP attempts to solve a different layer of the problem, tool integration, not identity.

To their credit the people presiding over the Model Context Protocol haven't been sleeping on this issue either. MCP's auth story has gone through several revisions in a short space of time. Understanding why these changes happened is worth a quick detour.

The original MCP auth design had a fundamental architectural problem: MCP servers were expected to act as both the OAuth Authorization Server and the Resource Server.

If you've done any OAuth work, you'll immediately see why this is bad. It's like asking the bouncer at the club to also be the one printing the fake IDs.

The MCP server was responsible for issuing tokens, managing client registrations, handling token revocation, and validating those same tokens on incoming requests. This makes every MCP server a high-value target and a compliance nightmare. Suddenly what was supposed to be a lightweight wrapper around your API needs a secure database, stateful session management, and a full security audit.

The June 2025 update to MCP addressed this by formally classifying MCP servers as OAuth Resource Servers. So they validate tokens but never issue them. A separate Authorization Server (your existing IdP — Okta, Auth0, Entra ID, whatever you already have) handles the actual token minting.

To make this work, MCP servers now expose Protected Resource Metadata (RFC 9728), which is basically a machine-readable sign on the door that says "if you want a token to talk to me, go talk to that authz server over there." This solved the discovery problem, and clients no longer had to guess where to authenticate.

This same update also made Resource Indicators (RFC 8707) mandatory for MCP clients. This one is subtle but important because without RIs, a malicious MCP server could potentially trick a client into obtaining a token scoped for a different MCP server and then replay it.

Resource indicators bind the token to its intended audience, so a token minted for mcp.example.com can't be redeemed at mcp.evil.com. If you've ever seen a token confusion or token mis-redemption attack, this is the mitigation.

The November 2025 revision then made PKCE (Proof Key for Code Exchange) mandatory for all clients, no exceptions.

The reasoning here is that MCP clients are often what OAuth calls "public clients" — agents running in containers, serverless functions, CLI tools, browser extensions — environments where you simply cannot securely store a client secret.

PKCE protects the authorization code exchange by requiring the client to prove it was the one that initiated the flow, even if an attacker intercepts the authorization code in transit. This same revision also introduced Client ID Metadata Documents as the preferred client registration method, moving away from Dynamic Client Registration (which had the uncomfortable property of letting any client register itself with zero paper trail).

All of this substantially shores up the authorization side of the equation. But here's the rub: authorization is downstream of identity!

All of these mechanisms assume that someone has already authenticated. That a human clicked "Authorize" in a browser window somewhere. The harder question of how a non-human client proves it is who it claims to be, when there's no human in the loop to click that button, remains unanswered by MCP. This is precisely the gap that the IETF draft and the WIMSE/SPIFFE work are trying to fill.

MCP still not great as a forward thinking standard

In my view the reasons for finding a better solution for MCP lie in a few key areas.

The obvious stuff is just how badly designed it is from a prompt security perspective, and its surface area is single-handedly driving the need for agentic/prompt WAF type products to exist. MCP tools simply return unstructured text making malicious MCP servers a wonderfully effective attack vector.

While MCP design goals are pretty small in scope, because the ecosystem tries to treat it like the 'everything server', the principle of least privilege takes a punch to the guts. There is no enforceable permission model in MCP, it's basically all or nothing, with some hinting to 'inform decisions'.

In theory OAuth scopes could do this but the mapping between MCP tool names and OAuth scopes is at large, that's up to the developer and consumer to pre-arrange, it's not a protocol level concern.

This is driving other MCP governance products to attempt to address the issue, all with variable degrees of success.

Perhaps the worst one from an integration perspective is that there is no inherent agreement on versioning or capability negotiation, so the chances that your agents start misbehaving one afternoon because the MCP started acting differently are pretty high.

In Summary

OK if you made it this far you are officially my [hero|heroine] for surviving the Agentic Onslaught of Acronymonious Anachronisms so I shall reward you with a quick recap.

To answer the initial question I don't think MCP is going anywhere but I do think the rate of change and the (perhaps misguided) quest to yeet humans out of the loop as much as practical could render it obsolete or force it to start defining or embracing existing identity strategies that support a non-human identity layer.

Whether we should nudge these standards to allow more 'humans out of the loop' or not is highly debatable. However, the current state of agent identity is best defined as a "bunch of protocol drafts in a trenchcoat" — it does make a refreshingly sane argument that we don't really need Yet Another Protocol™, just extend some existing ones. OAuth 2, SPIFFE and mTLS would form the cornerstones of Authorization, Identity Management and Authentication respectively. For service discovery, Google has come to the party with the A2A protocol. There's some peripheral standards tweaking happening to make it easier to distinguish existing OAuth delegations of authority from agent-to-agent, agent-autonomous and human-to-agent, and for provisioning agent identities in the first place.

However none of this is production-ready and is theoretical until people start to implement code. The closest thing I could find to such a thing is Google's A2A SDKs in a variety of languages, and I might dissect those and their security ramifications in an upcoming blog post, so stay tuned.