Your Agent Can Prove Who It Is. It Still Can't Prove It Was Allowed.

A supplier's agent arrives at your systems on a Tuesday morning. It is software owned by another company, running on their infrastructure, following their instructions, and it carries a cryptographically signed card confirming it is exactly what it says it is, issued by exactly the company it names. The signature checks out. The card is valid. Everything about the introduction is in order.

Can it read your customer table?

There is no standard answer to that this week. There won't be one next week either, which is an odd thing to have to write, because this was the week the agent industry finally stopped arguing about how any of this plugs together.

The connection problem got solved

Google Cloud published findings from its second annual State of AI infrastructure report on 24 August, drawn from 1,402 IT leaders. Seventy-nine per cent named security, governance or operations as their biggest challenge in scaling inference. Model quality didn't top the list. Neither did cost.

A second number in the same research is the one I'd put in front of a board: 35% of senior IT decision-makers said insufficient security for multi-system access was a primary reason they hadn't deployed agents at all. So a third of the market isn't moving slowly because the technology has disappointed them. They're stuck on the Tuesday morning question.

That research landed days after the other half of the problem got tidied away. On 17 August, Google's Agent2Agent protocol became a hosted project of the Agentic AI Foundation at the Linux Foundation, joining Anthropic's Model Context Protocol under one roof. The foundation now holds five projects it describes as a single stack: AGENTS.md for instructions and context, goose for runtime, MCP for reaching tools and data, agentgateway for traffic and policy, and now A2A for agents handing work to each other.

Nobody's ownership changed. Google had already donated A2A to the Linux Foundation back in 2025, and both protocols keep their own maintainers, specifications and release schedules. What moved was stewardship, into a narrower home built for exactly this.

If you have been holding off on agent architecture until you could see which standard would survive, that wait is over, and it was never really a contest anyway. Forbes drew the line between them in two sentences that are hard to improve on. MCP standardises how an agent reaches a database, an API or a file system. A2A standardises how one agent asks another to complete a task and return the result. One reaches down into your resources. The other reaches sideways across organisational boundaries. They now sit under governance no single vendor controls, which is a genuinely good outcome and worth saying plainly before the rest of this article gets more difficult.

Identity is not permission

A2A version 1.0, released in March, introduced cryptographically signed agent cards. A signature confirms the card genuinely belongs to the organisation named on it. That's authentication, and it now works to a standard most enterprise security teams would recognise from their existing identity stack.

Authorisation is a different question. The specification leaves it open on purpose.

You can watch the boundary appear in something as unglamorous as two HTTP status codes. An A2A server should return 401 when credentials are missing or invalid. It should return 403 when the credentials are perfectly good but the client is asking for something it isn't permitted to have. The first gate is standardised. The second gate is yours, and always was.

The spec doesn't pretend otherwise. It says that once a client is authenticated, the server becomes responsible for authorising the request. It says access can be controlled per skill, as advertised in the agent card. It says agents must grant only the permissions needed for the operation at hand, and it recommends logging task and session identifiers together, propagating trace context so a request can be followed end to end, and auditing significant state changes.

Look at what those actually are. They are instructions to have a policy. They are not a policy, and a recommendation is only ever as good as whoever chose to implement it.

This was a deliberate choice. A2A leans on OAuth 2.0 and OpenID Connect for authentication and slots into the identity infrastructure enterprises already run, which is sensible engineering and saved everyone a decade of arguing. The consequence for you is that when a partner's agent crosses your boundary, how far it travels is a decision your organisation makes, writes down, and has to defend later.

For a sense of how much work is left in that gap, look at what the industry did the moment it had to settle authorisation for something with money attached. Google Cloud and PayPal took A2A into commerce. They did not give A2A the payment authority. Product discovery, pricing and order fulfilment travel over A2A, and a second protocol built on top of it, AP2, handles the authorisation to spend. One communication standard turned out not to be enough, so a separate standard had to exist for permission.

The failure that compounds

Sitting behind the permissions question is a second one, and operations leaders should find it the more uncomfortable of the two.

A2A treats agents as opaque to each other by design. They don't share internal memory, tools, or direct resource access. There is real upside in that: a remote agent behaves like an ordinary HTTP application, so your existing security models apply without modification. The cost is that an agent partway down a chain has no way of seeing what the agent before it based its answer on. Only the output travels.

Mahesh Shanmugasundaram, lead AI solutions architect at Seekr, put the failure mode to TechStrong AI last week. In an A2A chain, each agent treats the previous agent's output as fully trusted input rather than as a claim that might want checking. Bake that assumption in, he argued, and cascading failure gets structurally worse than teams anticipate. A small error introduced near the front of the chain resurfaces four steps later looking considerably more authoritative than it did when it started.

He called it a game of telephone. That undersells it slightly. In the playground version, everybody in the circle knows the message has been through several mouths and adjusts their confidence accordingly. Here the final answer arrives clean, well-formatted and sure of itself, with none of the seams showing.

The permissions problem and the trust problem look like separate concerns. They meet in the same place. Both are judgements the standard declines to make on your behalf, and both depend entirely on whether the basis for the judgement can be reconstructed afterwards. Without a record of which agent read what, and under whose authority, you cannot replay a permissions incident. Without a record of which claim went unverified at which step, you cannot trace a wrong answer back to where it went wrong.

Washington is circling the same hole

Regulators have noticed. That is worth knowing about and worth not depending on.

NIST's National Cybersecurity Center of Excellence put out a draft concept paper in February on applying identity and authorisation standards to software and AI agents. It asks the right questions: how an agent proves its authority, how that authority ties back to a named person, what verifiable records look like. Comments are still under review.

In July, Senator Mark Warner introduced the AI AGENT Act, S. 5051. The bill defines a "custodial user agent" as one expressly authorised to act for a user in a transparent, documented, scope-limited and revocable manner, and would generally require such agents to keep real-time records of what they do on someone's behalf. It also directs NIST to identify existing protocols, or develop new standards, for verifying that a user actually delegated authority and for keeping auditable records of agent actions.

Two caveats. It is a bill, and most bills quietly stop being bills. More usefully: even as drafted, it would not expressly require a verifiable evidence chain running across all the separate systems a real task crosses, from the moment a user starts it to whatever happens at the far end. The precise artefact you would want to produce in a dispute is the one still missing from the draft.

Nobody is turning up this quarter to sort this out for you.

The case for not worrying too much

Some counterweights, because these numbers deserve a harder look than they have been getting.

The adoption figures everyone quoted this week come from the foundation's own tally rather than independent measurement. More than 250 members. More than 150 organisations backing A2A. Over 10,000 public MCP servers. Those show direction, and direction is useful information. They are not market share, and Forbes attached that caveat at the time.

An endorsement is also not an implementation. Hosting an A2A endpoint tells you nothing about whether a vendor supports protocol bindings, version negotiation, multi-tenancy or signed cards. A logo on a supporting-organisations page tells you nothing about which revision of the spec the agent on the other end of your handshake is actually running.

Fragmentation hasn't fully resolved, either. IBM folded its Agent Communication Protocol into A2A last year, but Cisco's AGNTCY still covers overlapping ground on discovery and identity, which is precisely the territory this article has been walking through.

None of that is an argument for waiting. It is an argument for reading this week's announcements as a signal about where things are going, not a report on where they currently are.

What to do on Monday

The preparation that matters here sits outside the protocol entirely, which is the good news, because it doesn't expire when the specification version bumps.

• Decide which skills you'll expose. Name the specific capabilities you are willing to let an external agent invoke. Your technical surface area will be considerably wider than that list, and it should be. This is a business decision and it needs a named owner.
• Write down what data each of those skills can reach. Classification, then the access policy attached to that classification. If nobody in the building can tell you which category a dataset falls into, you are not ready to open cross-boundary delegation to it, however tidy the standards have become.
• Build the place the record lives. Delegation requests in, authority carried, results out. When something goes wrong, the question that decides who is responsible is which system enforced the boundary and what evidence it left behind. That evidence either exists or it doesn't, and you find out at the worst possible moment.

Then take three questions into any conversation with a vendor selling you agent interoperability. Which A2A revision do you implement, and do you negotiate versions with older clients? Do you reject unsigned agent cards, and how do you establish that a signing key really belongs to the organisation asserting it? And when our agent hands work to yours, which system enforces the access boundary, and does the exchange leave an audit record our compliance team can actually read?

The first two questions interrogate someone else's engineering. The third one tells you who carries the can.

Where this leaves you

Connecting things is now largely a solved problem, stewarded in the open, by a foundation no single vendor controls. That removes a real reason to delay, and plenty of organisations have been using standards uncertainty as cover for not having done the harder work underneath.

Because the harder work is still sitting there. Which agent may read which data, on whose authority, and what gets written down when it happens. Those three answers live on the data side of your business. They were your responsibility before this week and they are your responsibility after it, and no amount of protocol convergence is going to produce them for you.

The organisations that move fastest from here won't be the ones with the newest protocol support. They'll be the ones who already know what their data is and who it belongs to, because for them every new doorway is just a doorway.

At U4RIA, we believe AI is a tool to help humans, not replace them. Like what we're about? See what your business is truly capable of. Experience U4RIA.