Security · 2026-03-20

A2A Trust Negotiation: How Two AI Agents Prove Identity to Each Other Without a Human

By J. W. Bouckaert

Two agents need a trust decision

Multi-agent systems are no longer theoretical. Procurement agents negotiate with supplier agents. Compliance agents verify counterparty agents. Scheduling agents coordinate with logistics agents. In every one of these interactions, two autonomous systems must answer the same question before a single byte of business logic executes: "Should I trust you?"

The internet was built on a trust model that assumes a human at one end. TLS authenticates servers to clients. OAuth authenticates clients to resource servers. SAML authenticates users to service providers. In every case, the implicit assumption is that a human being initiated the request, a human being will evaluate the response, and a human being bears ultimate responsibility for the transaction.

Remove the human, and the entire trust model collapses.

When Agent A calls Agent B's API, what exactly is being authenticated? Agent A has a bearer token—but who issued it, under what authority, with what constraints, and for how long? Agent B cannot answer any of these questions with a bearer token alone. It can verify that the token is cryptographically valid. It cannot verify that the entity presenting it should be doing what it is about to do.

The gap is structural, and it sits at the center of every multi-agent deployment in production today.

Limits of mutual TLS

The first response from most infrastructure teams is mutual TLS (mTLS). Both agents present certificates. Both certificates chain to a trusted root. Authentication is bilateral. Problem solved.

It is not.

mTLS proves that both endpoints possess valid certificates issued by a trusted certificate authority. It does not prove:

• Delegation authority. That the agent holding the certificate was authorized by a human principal to perform the specific operation being attempted.
• Behavioral compliance. That the agent's current behavior is consistent with its authorized scope and historical baseline.
• Scope intersection. That both agents are authorized for the specific transaction type being negotiated, in addition to holding valid network-layer credentials.
• Temporal validity. That the delegation behind the certificate is still active—not merely that the certificate itself has not expired.
• Trust reciprocity. That the trust relationship is bilateral. Agent A trusting Agent B's certificate says nothing about whether Agent B should trust Agent A's delegation authority.

mTLS is a transport-layer primitive. It authenticates network endpoints. It does not authenticate delegated authority, behavioral intent, or bilateral trust. Using mTLS alone for agent-to-agent trust is the equivalent of using a padlock to verify someone's employment contract.

The five-phase A2A protocol

PasskeyBridge's Agent-to-Agent protocol addresses this gap with a five-phase handshake that establishes bilateral trust, negotiates scoped authority, and re-checks that trust whenever the session is renewed.

Phase 1: Initiation

The caller sends an initiation request to the A2A endpoint. The request contains:

The nonce is required on every step that changes a negotiation. PasskeyBridge stores only its SHA-256 digest, with a five-minute expiry, and rejects any request that reuses a nonce it has already consumed. The caller does not sign the request: PasskeyBridge signs each step it records, as described below.

Phase 2: Attestation

Both agents' delegation certificates are retrieved and validated. The system verifies:

1. Delegate state. Both delegates are active. A delegate whose trust score fell below its revocation floor (0.20 by default) has already been deactivated and fails here.
2. Principal binding. Each delegating account holds a passkey credential in the organization. No PII is retrieved or transmitted.
3. Certificates. Both delegates' certificates are verified, as they are at every step of the handshake.
4. No recent hard signal. Neither delegating account has had a hard signal, such as a SIM swap, in the last five minutes. If the signals cannot be read, the check fails.

If any of these checks fail, the negotiation terminates with a specific error code. The failure is logged to the audit trail with the failing condition, the involved delegate IDs, and a timestamp. It never records raw names, phone numbers or email addresses.

Phase 3: Trust coefficient calculation

This is the core mathematical primitive of the protocol. The Combined Trust Coefficient (CTC) is computed as:

CTC = geometric_mean(initiator_trust, responder_trust) - jitter_penalty + fingerprint_bonus + sim_freshness_factor

Geometric mean. The choice of geometric mean over arithmetic mean is deliberate. If Agent A has a trust score of 0.95 and Agent B has a trust score of 0.30, the arithmetic mean (0.625) would grant the session near-full access. The geometric mean (0.534) correctly reflects that the session is only as strong as its weakest participant, while still crediting the stronger agent's trust contribution.

Jitter penalty. Round-trip jitter above 150 milliseconds, as reported by the caller with the negotiate request, triggers a proportional trust reduction, up to a maximum penalty of 0.20 at 1,000 milliseconds. Jitter can rise when traffic is relayed or proxied, or when an agent runs far from where it claims to. The penalty scales linearly, with no cliff at a threshold, and an absent value is read as 50 milliseconds, which carries no penalty.

Fingerprint bonus. If either delegating account has an active NF-08 spatial binding (a device enrolled with PasskeyBridge's spatially bound attestation), a 0.05 bonus is applied. This rewards sessions that carry a hardware-anchored identity signal beyond the delegate record.

SIM freshness factor. If a carrier signal has been verified within the last 300 seconds, a small bonus (up to 0.03) is applied based on signal freshness. A signal verified 10 seconds ago provides more confidence than one verified 290 seconds ago.

The resulting CTC maps to a trust state:

Phase 4: Scope negotiation

The CTC determines the ceiling. The scope intersection determines the floor.

The negotiated session receives only the scopes that both agents share. If Agent A has ["payments:write", "inventory:read", "verify"] and Agent B has ["inventory:read", "verify", "shipping:write"], the intersection is ["inventory:read", "verify"].

The trust state further constrains this intersection:

• Full access permits all intersected scopes.
• Read-only filters the intersection to scopes containing "read" or equal to "verify."
• Verify-only filters to only the "verify" scope.
• Auto-revoked permits nothing.

Transaction limits are derived from a piecewise-linear tier table keyed to the CTC:

These limits are fixed in the coefficient calculator. They are written into the negotiation and its signed proof, and the service on the other side of the transaction enforces them, because that service is the party that sees the transactions.

Phase 5: Renewal and invalidation

The negotiated session is short-lived and does not extend itself:

1. TTL expiry. Every negotiation has an expiration timestamp. To continue past it, the caller renews the negotiation, which extends it by 10 seconds to one hour.
2. Score drift. A renewal is refused, with action_required: "re-attest", when the geometric mean of the two delegates' current trust scores is more than 0.10 from the recorded CTC. This catches gradual behavioral degradation that would not trigger a hard signal. The agents then run a new handshake.
3. Deactivation. If either delegate has been deactivated, the renewal revokes the negotiation.
4. Hard signal. A hard signal such as a SIM swap triggers a parametric cascade that revokes every open negotiation in the organization. The negotiation is invalidated outright, with no re-attestation step.

A new handshake computes the CTC again from current scores, reported jitter and signal freshness, so the trust state, transaction limits and permitted scopes can change in either direction. A pair whose scores have recovered can regain full access, and a pair whose scores have fallen loses it.

The cryptographic foundation

Every step that changes a negotiation (initiate, attest, negotiate, renew) is signed by PasskeyBridge with hybrid post-quantum cryptography, and the change is committed together with its proof. If signing fails, the step writes nothing.

ML-DSA-65 (Module-Lattice-Based Digital Signature Algorithm, NIST FIPS 204) provides the post-quantum layer. ML-DSA-65 is a Category 3 lattice-based signature scheme that remains secure against both classical and quantum adversaries. It was selected over ML-DSA-44 (Category 2) to provide a security margin appropriate for financial and identity transactions.

HMAC-SHA-256 provides the classical layer. In a hybrid scheme, both signatures must verify for the payload to be accepted. If a future quantum computer breaks the classical layer, the lattice signature still holds. If a theoretical advance compromises the lattice scheme, the classical HMAC still provides integrity assurance.

Each consumed nonce is stored as a SHA-256 digest with a five-minute expiry, so the raw nonce is never kept and expired rows can be cleaned up.

OAuth cannot be retrofitted with these properties

The reflexive question from enterprise architects is: "Can we add these properties to our existing OAuth infrastructure?"

No.

OAuth's authorization model is fundamentally unilateral. A client requests authorization from a resource server. The resource server grants or denies it. There is no bilateral negotiation. There is no geometric trust computation. There is no continuous re-attestation. There is no parametric scope degradation based on runtime behavioral signals.

Attempting to bolt these properties onto OAuth would require:

• Replacing the token model with delegation certificates that encode behavioral baselines and parametric constraints.
• Adding a bilateral handshake that both parties must complete before any scoped access is granted.
• Implementing a continuous trust scoring engine that evaluates every API call against a behavioral model.
• Building a real-time cascade mechanism that can revoke a session across multiple subsystems inside a single request.
• Signing every token with hybrid PQC signatures that survive both classical and quantum cryptanalysis.

At that point, you have not extended OAuth. You have replaced it with a fundamentally different protocol. Which is precisely what the A2A negotiation protocol is.

The audit trail

Every A2A negotiation produces a complete audit record:

• Initiation timestamp, involved delegates, requested scopes. Who asked for what, and when.
• Attestation results. Which checks passed, which failed, and why.
• CTC computation signals. The individual trust scores, jitter measurement, fingerprint binding status, SIM signal freshness, and resulting coefficient.
• Negotiated session parameters. Trust state, permitted scopes, transaction limits, expiration.
• Renewals. Each renewal, with the extension and the new expiry.
• Invalidation events. If the session was terminated early, the triggering signal and cascade disposition.

None of these records contain raw names, phone numbers or email addresses. The agents are identified by delegate IDs (UUIDs). Each delegate row names its principal by account ID, and the agent's own token is stored only as its SHA-256 digest. The token is a random secret generated at creation (two random UUIDs), so an unkeyed digest of it cannot be reversed by guessing inputs. Network origins in agent activity are keyed digests too. These are pseudonymous identifiers: under GDPR Recital 26, account IDs and keyed digests remain personal data, because the platform holds the information needed to link them back to an account. The audit trail proves what happened, when, and why, using pseudonymous identifiers and keyed digests rather than direct identifiers.

Keeping direct identifiers out of the audit trail is an architectural requirement. An audit trail built on pseudonymous identifiers and keyed digests still provides proof of authorization, proof of behavioral compliance and proof of revocation, while limiting what the records reveal on their own. Pseudonymization reduces exposure; the trail is still personal data and is handled as such.

Consequences for multi-agent architectures

The A2A trust negotiation protocol establishes three principles that every multi-agent architecture will eventually require:

Trust must be bilateral. Unilateral authentication—where one party proves identity and the other accepts or rejects—is insufficient for peer-to-peer agent interactions. Both agents must prove delegation authority, and the resulting trust must reflect the weaker participant.

Authority must be scoped and decaying. Static API keys and long-lived bearer tokens are architectural liabilities in multi-agent systems. Every negotiated session must encode what is permitted, how much is permitted, and for how long—with continuous recalibration based on behavioral signals.

Revocation must be immediate and cross-system. When trust fails in a multi-agent network, the failure has to reach every dependent delegate and negotiation within the threat window. In PasskeyBridge a hard signal deactivates the organization's delegates and revokes its open negotiations inside the request that carried it, rather than at the next token refresh or polling interval.

All three are operational requirements already implemented in PasskeyBridge's production infrastructure: the A2A handshake endpoint, the Combined Trust Coefficient calculator, the parametric cascade engine, and the hybrid PQC signature layer.

For every platform that deploys autonomous agents, the open question is whether they will implement these requirements before or after an incident demonstrates why they are necessary.

Start free · Test the API