The Biggest Agentic AI Security Summit

The Secure, Governed AI Future.

October 13, 2026 | Virtual

The Biggest Agentic AI Security Summit

The Secure, Governed AI Future.

October 13, 2026 | Virtual

The Biggest Agentic AI Security Summit

The Secure, Governed AI Future.

October 13, 2026 | Virtual

//Question

How do you secure agent-to-agent (A2A) communication?

Posted on 07th September, 2026

Richard

Richard

//Answer

Apply four controls: cryptographic workload identity so each agent proves what it is, capability scoping so an agent can only request what its role permits, message provenance so the origin of every instruction is traceable across hops, and untrusted-input handling so no agent treats a peer's output as authoritative. Google's A2A protocol, released in 2025 and now under the Linux Foundation, provides the discovery and messaging layer. It does not provide the authorization model.

Identity comes first. Use mTLS with SPIFFE or an equivalent workload identity system so agents authenticate as workloads rather than by sharing a bearer token that any process on the host can read.

Capability scoping is where most designs are too generous. An agent's delegation token should carry a narrow audience, a short lifetime, and the specific capability being delegated, so a compromised research agent cannot invoke an execution agent's write capability just because both are inside the trust boundary.

Provenance is the control that makes incidents investigable. Every message should carry a signed chain showing which agent originated the instruction and which relayed it, or a poisoned instruction three hops upstream will look like a legitimate internal request at the point of execution.

Untrusted-input handling is the design principle underneath all of it. A peer agent's output is content, not command, no matter how trusted the peer is. Agent Cards that advertise capability should be signed and verified, since a spoofed card redirects work to an attacker-controlled endpoint.

Akto Argus enforces at the tool-call boundary within these workflows, applying policy to what an agent actually attempts rather than to who it claims to be.

Authenticate the agent. Then authorize the action anyway.

Comments