A2A security begins with message authority, not transport encryption

I think A2A security begins with message authority, not transport encryption. TLS can prove that a channel reached a certificate holder without being read in transit. It cannot prove that this task still represents the user’s intent, that the sending agent was allowed to delegate it, or that the receiving agent may perform the requested effect. An encrypted request with ambient authority is still an unsafe request.

The distinction matters because agent-to-agent work creates chains rather than pairs. An orchestrator receives a user instruction, delegates research to one agent, asks another to make a decision, and passes an artifact to a third agent with tools. Each hop can preserve a secure connection while losing the answer to “who authorized this?” OAuth authentication identifies callers, but the A2A security material leaves protocol-level scope enforcement to implementations. That gap is where authorization creep appears: broad scopes accumulate, the original principal disappears, and a sub-agent acts as though delegation were ownership.

I would make authority an explicit property of every consequential message. The envelope should identify the principal, acting agent, delegating agent, permitted operation, target resource, purpose, expiry, and full delegation chain. Each hop must attenuate scope rather than copy it. This is the runtime form of delegated authority that static IAM cannot express: a task carries a narrow, signed grant instead of borrowing a standing service role.

Current authority also means current trust. Agent Cards and registries can advertise endpoints and capabilities, but a signed description proves only who endorsed that description. It does not prove that the credential, issuer, or trust path remains acceptable now. The receiver should resolve revocation before processing the message, following the same ordering as revocation before capability discovery. Long-running tasks need token rotation and expiry tied to task duration and risk, not bearer credentials that outlive the work.

Replay resistance belongs in the same envelope. A valid old instruction is not a valid new instruction. Task identifiers help with idempotency, but the stronger pattern combines a unique nonce, a bounded timestamp window, and a signature or MAC over the payload, timestamp, nonce, and authority claims. The receiver records consumed nonces and rejects duplicate effects. Encryption protects the bytes on the wire; replay controls protect the meaning of “do this once, now.”

Prompt injection makes message authority more important, not less. A2A chains can carry hostile instructions through task text, retrieved artifacts, Agent Card metadata, or streaming content. I assume some untrusted content will reach a model. The enforceable question is whether that content can manufacture authority. It must not. A tainted artifact may influence a value or recommendation, but it should not widen scope, choose a new recipient, or create a write permission. That is the cross-agent form of treating injection as a permissions problem.

The audit record then falls out of the protocol rather than being reconstructed from logs. Store the message identity, principal, delegation chain, authority decision, nonce, task state, artifact hashes, and resulting effects in an append-only trail. This makes who acted, for whom, and with what authority answerable across organizational boundaries instead of only inside one gateway.

There is one precise concession: transport security remains mandatory. Without authenticated encryption, authority claims and artifacts can be observed or altered before the receiver evaluates them. The boundary of my claim is priority, not substitution — TLS secures the channel, while signed, scoped, fresh, replay-resistant authority secures the action. A2A systems need both, but only one tells the receiving agent whether it should obey.

I would therefore review an A2A design from the message inward: what authority does this task carry, how was it attenuated, when does it expire, how is replay rejected, and what evidence survives? Only after those answers are explicit would I treat encrypted transport as evidence that the system is secure rather than merely private in transit.