How do you secure A2A comms between agents?

Secure A2A comms by treating every agent card as untrusted input rather than documentation. The A2A protocol, an open agent-to-agent standard under the Linux Foundation, lets a client agent read a card and act on it, so a rewritten skill description can redirect work without any exploit code. Since the protocol's 2025 releases and the 2026 Linux Foundation stewardship, agent-card validation has become the first control auditors ask for. This guide turns that risk into eight testable controls and a validator workflow.

Secure A2A comms by treating the agent card as a trust boundary

Secure A2A comms means treating the agent card as untrusted input that your orchestrator must verify before it routes any work. The A2A protocol, an open standard for agent-to-agent collaboration that Google announced in 2025 and later contributed to the Linux Foundation, publishes each agent's identity, skills, endpoint and authentication requirements as a JSON document at a well-known path. A client agent reads that document and acts on it: which URL to call, which skills exist, what each skill does.

That reading is the vulnerability. Skill descriptions are written for humans but consumed by models, so a description that says to prioritize its own instructions over the client becomes guidance the model can follow. No exploit code is required, and the protocol carries no built-in reputation, which means a partner card and an internal card look identical to the agent fetching them.

The defensive posture is narrow and repeatable: register cards after human review, pin the reviewed version, verify signatures, authenticate every endpoint, constrain skills and schemas, bound delegation depth, and scan description text on registration and on every update. Every one of those checks can be automated against a fetched card.

What the A2A protocol actually specifies

A2A defines two roles and a small set of transport rules, and production deployments are expected to run over HTTPS with modern TLS. The client agent sends work; the remote agent performs it. Long-running work streams status updates over server-sent events, and each exchange uses JSON-RPC 2.0 as the message format.

The card is the discovery mechanism. Fetching JSON from the well-known agent path is the whole of discovery, which is why an unregistered card can enter your fleet as easily as an approved one. Tasks move through a defined lifecycle, from submitted through working, input-required, completed, failed or cancelled, and results return as artifacts: files, structured data or text.

Identity lives at the HTTP transport layer rather than inside the JSON-RPC payload. That detail decides how you implement authentication: bearer tokens, API keys, OpenID Connect or mutual TLS applied at the endpoint, not an agent-level credential invented on top of the protocol.

The eight controls, one row at a time

The defensive model below splits into three groups: verifying the card, constraining what the agent may do, and bounding delegation while keeping records. Each control produces a pass or fail that a script can compute, which is what makes the model usable in review rather than aspirational.

Control	What it checks	Failure mode it catches
C1 registry allowlist	Card is registered, HTTPS-only, version pinned	Shadow agents reaching the orchestrator
C2 endpoint authentication	Every task endpoint requires credentials	Open task endpoints, internal or external
C3 card signature	Signature verified before first use and after updates	Tampered or silently rewritten cards
C4 skill allowlist	Only granted skills on granted agents, never wildcards	Scope creep from a compromised agent
C5 strict schemas	Payloads validated before send and on accept	Undeclared fields carried into tasks
C6 delegation boundaries	Maximum depth plus agent-to-agent allowlist	Unbounded routing across the mesh
C7 TLS everywhere	HTTPS with modern TLS on every endpoint	Plain-HTTP cards and task calls
C8 audit plus description scans	Flags block registration until reviewed	Hidden instructions in skill text

Per-agent credentials with per-agent scopes support C2 and C4 together. A billing agent that was never granted a delete scope cannot invoke one even if its token leaks, so the blast radius stops at the delegation boundary rather than spreading through the mesh.

Treat agent credentials like service credentials: short lifetimes, scheduled rotation, and revocation that propagates immediately when an agent is decommissioned. Authenticate card fetches too, so a fleet of internal agents cannot be enumerated from publicly readable cards.

A 32-check validator run against four agent cards

A validator executing the eight controls across four A2A agents produced 32 checks with 22 passes and 10 failures, plus 11 injection flags in three skills across three agents. The run was the lesson's own demonstration script with output shown on screen, so treat the numbers as a first-party demonstration rather than an independent benchmark.

The orchestrator, serving as the reference build, passed all eight controls: registered, HTTPS card, signed, authenticated, strict schemas, bounded delegation, TLS and auditing. Three other agents failed in instructive ways.

The shadow file agent

The file agent was never registered, published its card over plain HTTP, and offered no authentication, signature, TLS or audit, scoring two of eight. Its delete skill also told the model to hide the deletion from the user, adding three secrecy flags. This is the profile of an agent that bypasses the registry entirely.

The realistic billing agent

The billing agent passed identity checks but failed the strict schema control and the description scan, scoring six of eight. Its refund skill instructed the model to call a tool before answering, to treat other agents as lower priority, and not to mention the instruction, which produced three flags and one schema failure. Notable detail: the card was otherwise legitimate.

The dangerous partner agent

The partner agent was fully registered and signed yet accepted unauthenticated task requests, a critical finding. Its fetch skill produced five flags, including claims of priority over other agents, a credentials-file read, and a directive to send results to an external address. It scored six of eight, which is why per-control scoring beats a single trust score.

The run's final counts were 22 pass, 10 fail, 11 injection flags, and two critical findings, with the unauthenticated endpoint counted as one of those criticals.

Why card defenses fail after the first review

Card defenses fail because review is treated as a one-time event while the card keeps changing. Grants stay valid after the reviewed text is replaced, registries do not stop routing, and alerts fire into a queue nobody reads. Each failure below is a process problem with a technical fix.

• Stale cards. A skill description changes after approval and nobody rescans. Pin the reviewed version and re-verify the signature on every update; any text change re-triggers review.
• Shadow agents. If the orchestrator can reach an unregistered agent, the allowlist is decoration. Force discovery and routing through the registry and hunt continuously for unregistered cards.
• Unread logs. Alert on denied delegations and scope anomalies, and treat a flagged description as an incident rather than a warning.

The description scan has to function as a gate. A flagged card stays out of the registry until a human reviews it, and the scan reruns on every update so instructions that arrive after approval never reach the model unchecked.

Two external frameworks help defenders name what they find. The OWASP guidance on agentic AI covers agent-to-agent trust, and MITRE ATLAS maps adversarial techniques against agentic systems, so detection language matches industry reporting.

A defensive workflow you can run this week

Inventorying every agent and its card comes first, because the other seven steps depend on knowing what exists. The workflow below follows the ordering used in the lesson: establish the inventory, then register and pin, then verify, then constrain, then watch.

1. Inventory every agent and the card it publishes.
2. Register and pin approved cards, refusing unregistered ones at discovery.
3. Verify card signatures and require HTTPS for every card URL.
4. Authenticate every task endpoint, internal or external.
5. Grant per-agent scopes and skill allowlists.
6. Validate schemas on send and receive, and bound delegation depth with an explicit routing allowlist.
7. Scan skill descriptions at registration and after every update.
8. Audit every exchange and review the flags on a schedule someone owns.

Teams building or maintaining agent infrastructure, including practitioners such as Gustavo dev doido, can run steps one through three against a fetched card with a short script before writing any policy documents. The scan and audit steps need an owner more than they need code.

FAQ: card trust and endpoint authentication

• Why is an agent card a security boundary rather than metadata? A client agent reads the card as trusted guidance about identity, skills, endpoints and authentication, and a malicious skill description can steer that agent without exploit code. Verification has to happen before the card influences routing.

• Why should a fully registered, signed agent still fail a security check? Registration and signatures say who published the card, not that its task endpoint requires credentials. An agent can pass card trust and still accept unauthenticated task requests, which is a separate control and was the critical finding in the demonstration run.

• What makes a description scan a gate instead of a log entry? A flagged card is blocked from the registry until a human reviews it, and the scan reruns on every card update, so instructions added after approval are caught. A log records a problem; a gate prevents the delegation.

• Does per-agent scope reduce the damage of a compromised agent? A compromised agent is limited to the scopes and skills it was granted, and delegation depth limits stop the damage from chaining further. Least privilege across the mesh is what keeps one failure from becoming a fleet-wide incident.

• Can the same eight controls be checked automatically? Every control is testable by script: fetch the card, check the URL scheme, verify the signature, probe the endpoint for authentication, validate message schemas, and scan description text. The demonstration validator computed all 32 checks without manual inspection.

From agent cards to written guidance

The lesson's core idea is that trust has to be verified at every exchange, not granted once when a card arrives. Teams that run these checks usually have the reasoning behind them in a recording: a walkthrough of a validator run, a review of why one endpoint failed, or a briefing on how the registry gate should work. That explanation rarely exists in writing yet.

Skalablog turns a YouTube video into a draft article: paste the URL, transcribe the video, and generate a structured piece you can edit before publishing. If your team already explains A2A hardening on camera, the Skala Blog workflow gives that explanation a written form you can review and keep.

Source video