Authentication inside one company
Within a single trust domain the problem is well understood. Agents get service identities, OAuth 2.1 handles delegation with per-user attribution, secrets live in a vault, and an identity provider you control is the authority on who everyone is. This is a mature stack and it works.
It works because of one property that is easy to miss: there is a single authority both sides already trust. Your IdP can vouch for the caller because your IdP issued the caller's identity.
Why those patterns do not transfer
Between two organisations, no such shared authority exists. Each side has an identity provider; neither side's IdP has any standing with the other. The usual workarounds each fail in a specific way:
- Shared API keys. A bearer secret proves possession, not identity. It cannot distinguish the counterparty from anyone who obtained the key, and rotating it means coordinating with every holder.
- Mutual TLS. Genuinely useful, and worth doing — but a certificate attests to domain control. It does not establish that the operator is a licensed insurer, nor what data classes this particular agent may request.
- Federated OAuth. Designed for a user consenting to share their own resources. Agent-to-agent exchange frequently has no human in the loop at all, and the thing being authorised is institutional, not personal.
- Allow-lists of IPs or domains. Operationally brittle, and they answer "did this come from there?" rather than "who is accountable for this?"
The four failure modes
When agents operate without dedicated, verifiable identity, the failures are consistent enough to name:
| Failure | What it looks like |
|---|---|
| Attribution collapse | An incident occurs and no reliable chain of custody exists. Nobody can say which agent, acting for whom, under what authority. |
| Over-privileged agents | The agent inherits a human's full permissions because that was the only credential available, and now holds far more access than its task requires. |
| Shadow agents | Agents provisioned outside any governance process, invisible to the register the risk function believes is complete. |
| Session contamination | Several agents share a service account, so none can be individually deprovisioned, throttled or revoked. |
Each is manageable internally, where you can go and fix the offending system. None is manageable when the offending system belongs to a counterparty.
What cross-company authentication requires
Five properties, and the difficulty is that they must hold simultaneously:
- Mutual. Both parties verify. One-way authentication means the party answering has no idea who is asking.
- Institutional, not just cryptographic. The credential must trace to a verified legal entity and, where relevant, a checked regulatory licence — not merely to a key someone generated.
- Scoped. Identity alone is insufficient. The credential must carry what this agent may do, so authorisation does not collapse into "authenticated, therefore permitted".
- Revocable network-wide. Withdrawal must take effect everywhere at once, without each counterparty having to act.
- Recorded. The authentication decision itself is evidence, and belongs in the audit record alongside the exchange it permitted.
Properties two through five are why this cannot be solved with a better token format alone. They need a registry — a party neither counterparty controls, doing verification neither can do for itself. That is agent attestation.
What MCP and A2A actually cover
The two protocols converging as the default stack divide the problem horizontally and vertically. MCP handles the vertical: how an agent reaches tools, data and context. A2A handles the horizontal: how agents coordinate with one another. Both are being governed openly and both are improving quickly.
Neither, however, expresses institutional trust. Recent analysis of the governance gaps in agent interoperability protocols makes the point directly: these specifications describe how parties communicate, not how they establish that the other party is entitled to. That is a deliberate scoping decision by the protocol authors, not an oversight — but it does leave a layer that someone has to supply.
MCP and A2A are the transport and coordination layers. Attestation, policy and audit are the trust layer above them. Adopting MCP does not create the trust problem, and it does not solve it either — it just makes it urgent, because connecting to an external agent is now a few lines of configuration.
The handshake
What mutual, scoped, recorded authentication looks like in practice, before any payload moves:
The last line is the one that distinguishes this from a login. The decision to trust is itself recorded, so a later dispute can establish not only what was exchanged but on what basis the exchange was allowed.
Is mutual TLS enough on its own?
It is a sound transport control and worth having. It proves the far end holds a key for a domain. It does not establish which legal entity operates that domain, whether their licence is current, what this specific agent is scoped to do, or leave a record a third party would accept. Attestation layers those on top rather than replacing mTLS.
How is an agent identity different from a service account?
A service account is an internal construct meaningful only inside the directory that issued it. An attested agent identity is externally verifiable: it carries the verified entity behind the agent, its scope, and its current revocation status, and any counterparty can check all three without access to your systems.
What about human accountability - who authorised the agent?
Attribution is part of the record. An exchange captures the attested organisation, the agent, the declared purpose and, where the workflow requires it, the consent or authority the request was made under. The point of the ledger is that "an agent did it" is never a complete answer.