Security · 2026-03-20

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

By J. W. Bouckaert

The problem no one planned for

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, not merely that both possess 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 maintains continuous attestation throughout the session lifetime.

Phase 1: Initiation

Agent A transmits an initiation payload to the A2A endpoint. The payload contains:

The nonce is critical. It is SHA-256 hashed and stored with a five-minute expiration window. Any replay of the initiation payload within that window—or beyond it—is rejected. The nonce source is the platform's quantum random number generator pool rather than a pseudorandom function, eliminating the possibility of nonce prediction by an adversary who has compromised the PRNG state.

Phase 2: Attestation

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

1. Certificate validity. Both delegation certificates exist, are active, and have not expired.
2. Principal binding. Both certificates are cryptographically bound to an authenticated human principal (via SHA-256 hash—no PII is retrieved or transmitted).
3. Scope availability. Both agents have at least one scope in common with the requested negotiation scope.
4. Trust floor. Both agents' individual trust scores meet the minimum threshold for negotiation (currently 0.20—below this, the agent is in auto-revocation state and cannot participate in any A2A interaction).

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—never with PII.

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. Network round-trip jitter above 150 milliseconds triggers a proportional trust reduction, up to a maximum penalty of 0.20 at 1,000 milliseconds. High jitter is a known indicator of man-in-the-middle interposition, network manipulation, or geographic anomaly. The penalty degrades gracefully—it does not cliff at a threshold.

Fingerprint bonus. If an NF-08 Atomic Fingerprint (thermodynamic device fingerprint) is bound to the session, a 0.05 bonus is applied. This rewards sessions that have an additional hardware-anchored identity signal beyond the delegation certificate.

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 are conservative defaults. Tenants can override them per their risk appetite—but the CTC calculation itself is immutable.

Phase 5: Continuous re-attestation

The negotiated session is not static. Three conditions trigger automatic re-attestation:

1. TTL expiry. Every negotiation has an expiration timestamp. When it passes, re-attestation is mandatory.
2. Hard signal. If a Hard Signal (SIM-swap detection, SS7 intercept alert, certificate revocation) is received for either agent's principal, the negotiation is immediately invalidated—not re-attested, invalidated. Hard signals bypass the re-attestation path entirely and trigger a parametric cascade.
3. Score drift. If the geometric mean of both agents' current trust scores drifts more than 0.10 from the cached CTC, re-attestation is triggered. This catches gradual behavioral degradation that would not trigger a hard signal but indicates that the negotiation's trust basis has shifted.

Re-attestation recalculates the CTC with current scores, current jitter, and current signal freshness. The session's trust state, transaction limits, and permitted scopes may change—in either direction. A session that was read-only may be upgraded to full access if both agents' trust scores have improved. A session that was full access may be downgraded if one agent's behavior has triggered trust decay.

The cryptographic foundation

Every phase of the protocol is signed with hybrid post-quantum cryptography.

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.

The nonce consumed during initiation is stored as a SHA-256 hash with a five-minute TTL. The hash cannot be reversed to recover the nonce. The TTL ensures the nonce table does not grow unboundedly. Source IP hashes are stored alongside consumed nonces to detect replay attempts from different network origins—but the IP itself is never stored, only its irreversible hash.

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.
• Re-attestation events. Every re-computation, with the trigger (TTL, hard signal, or drift) and the resulting parameter changes.
• Invalidation events. If the session was terminated early, the triggering signal and cascade disposition.

None of these records contain personally identifiable information. The agents are identified by delegate IDs (UUIDs). The principals are identified by SHA-256 hashes. The audit trail proves exactly what happened, when, and why—without ever recording who, in the PII sense, was involved.

Keeping PII out of the audit trail is an architectural requirement. An audit trail that contains PII is an audit trail that creates regulatory liability. An audit trail built on irreversible hashes satisfies the same evidentiary requirements—proof of authorization, proof of behavioral compliance, proof of revocation—without triggering GDPR Article 33 breach notification obligations if the audit database is compromised.

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 must propagate across all dependent sessions, delegates, and tunnels within the threat window—not at the next token refresh, not at the next polling interval, but within the latency of a single database write.

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