An Agent Card is a business card for a remote agent. It tells other agents how to find and call it. In A2A-style systems, this card is usually published by the remote agent so other agents can discover it. It should not decide whether your agent is allowed to delegate work.
If an origin agent calls a remote agent just because it found a card, discovery has become authorization. That can send user context and task data to a remote agent before anyone has approved that delegation.
The safer pattern is to review Agent Cards before they become callable. Approved agents go into a registry. Runtime delegation goes through a broker that enforces the registry decision.
System description
An origin agent may discover remote agents through Agent Cards, but it cannot call a discovered agent directly. Approved agents are added to a capability registry first. At runtime, the origin delegates through a broker, and the broker only calls agents that are already approved in the registry.
Architecture choice
The registry lookup and the remote call can live inside each origin agent or in a shared broker.
Local registry
Each origin agent keeps its own approved-agent list. Use this when:
The remote agent pool is small
One team owns the origins and the remotes
Revocation does not need a shared control point
Trade-off: approvals and revocations can drift between origins.
Brokered delegation
A shared broker performs the registry lookup and makes the remote call. Use this when:
Many origin agents share remote agents
Revocation must work in one place
Audit needs one delegation trail
Trade-off: the broker becomes a critical service. If its registry cache is stale, revoked agents may keep receiving calls.
Golden path
Start with this path:
Discover the Agent Card → approve the agent into the registry → delegate only through the broker → treat the response as remote inputRelated patterns:
For the broader threat model of an origin agent's tools, loops, and memory: The AI Agent Attack Surface
For the gateway that mediates an origin's outbound calls: AI Agent Gateway
For approval when the trust unit is a tool definition rather than another agent: Designing a Safe Approval Flow for MCP Tool Descriptions
Minimal system context
User: the person asking the origin agent to do something
Origin agent: the agent the user works with
Agent Card: the remote agent's published self-description, used for discovery
Operator review: the step where a human decides whether a card becomes a registry entry
Capability registry: the list of approved remote agents the origin may call
Delegation broker: the service that performs the registry lookup and the remote call
Remote agent: the outside agent that does the delegated work
Audit log: the record of who called whom, with what result
Core design
Agent Card
The Agent Card is discovery metadata which tells you that some remote agent exists and how it claims to be reached. It is text from the remote operator, not authorization. A card enters the system through operator review.
Capability registry
The registry is the approved-vendor list where each entry stores an agent_id, the agent's signing key, an approved endpoint, the capability labels the agent may serve, an owner, and a status (active, deprecated, revoked).
The broker reads from the registry at every delegation. A card that has not made it into the registry is not callable, no matter how convincing it looks.
Delegation broker
The broker is the enforcement point which accepts a delegation request from the origin agent and resolves the agent_id against the registry. Before calling the remote agent, it confirms the registry entry is active and the registered key still matches. It then mints a scoped delegation token.
If the registry is unreachable or the registry entry's status is revoked, the broker refuses the delegation.
Delegation token
The broker mints a short-lived, single-use bearer token for one invocation, and this token names the target agent_id and the capability it covers. The remote agent authenticates the call with this token; the origin's user credentials never travel with the request.
Delegation payload
The broker builds the payload from the task and the capability label. The payload does not include the origin's conversation history or credentials. Fields outside the capability schema are rejected.
Remote response
The remote agent's reply is remote input; the broker labels it with the source agent_id and hands it back to the origin agent's untrusted-input path. The origin treats it as remote input, not as instructions from its own system.
Audit record
Each delegation is logged: who made the call, which registry entry was used, whether the broker allowed or denied it, and when. Records survive long enough to investigate a behavior change discovered later.
Key trade-offs
An approved-agent list adds friction. New remote agents do not receive work until someone reviews the card.
The broker sits on the critical path. If it is down, remote delegation should stop rather than bypass policy.
Registry caching helps latency, but weakens revocation. Use short TTLs and a deny-list for revoked agents.
Delegation logs may contain sensitive operational data. Define retention, access, and redaction rules before enabling broad logging.
Threat model
Baseline assumptions
Agent Cards are untrusted text from the remote operator
Remote agents are semi-trusted: they may pass an initial review and change behavior or hosting later
The origin's authority and the user's data are higher-value than the discovery metadata
The LLM inside the origin will follow any text it sees, including text in a card or remote response
Standard infra controls (TLS, service authentication, secret management) are in place. This model focuses on the discovery-to-delegation boundary
A note on risk
This table is not a checklist. Focus on preventing the highest-impact failures first. Detection and response are acceptable where prevention is impractical.
Asset | Threat | Baseline Controls | Mitigation Options | Risk |
|---|---|---|---|---|
Selection decision | Card poisoning: A card contains hidden instructions that steer the origin's LLM toward picking a specific remote agent or leaking the user's task | None | 1. Route selection through the registry; card text never reaches the planning prompt 2. Pass only registry-derived labels and 3. Render the full card to a human reviewer at registration | High |
Remote identity | Impostor agent: A card mimics the name or endpoint of an approved agent | Stable | 1. Bind registry entries to a signed public key, not a name or endpoint 2. Verify the remote signature on every invocation against the registered key 3. Trigger name-collision review before a similarly-named agent enters the registry | High |
Discovery surface | Unapproved listing: An attacker publishes a card in a shared discovery channel and waits for an origin to delegate without registry review | None | 1. Block delegation to any 2. Require operator review between discovery and registry inclusion 3. Disable any auto-ingest path from discovery into the registry | High |
Delegation payload | Overbroad payload: Origin forwards full user context or tool credentials alongside the task | Per-invocation payload | 1. Build the payload from the task and capability label, not the origin's conversation history 2. Reject extra fields at the broker; block known credential fields and configured restricted data classes 3. Bind the request to the calling tenant | High |
Origin authority | Confused deputy: Remote agent reuses the origin's identity or a forwarded user token to reach resources the calling user is not entitled to | Bearer auth between agents | 1. Mint a scoped delegation that names the target agent and capability; do not forward the origin's user token 2. Make the delegation short-lived and single-use 3. Require remote-agent calls to use the delegation token; reject forwarded user tokens at downstream services | High |
Delegation credential | Token replay: A delegation credential leaks and is replayed against the same or a different capability | Bearer token in transit | 1. Single-use, consumed at first invocation 2. Audience binding to one 3. Mutual TLS or signed request between broker and remote agent | Medium |
Origin reasoning | Remote output injection: A remote agent returns text that steers the origin's next tool call or user-facing response | Labeled remote response | 1. Pass remote output through the origin's untrusted-input handler 2. Restrict the tools available to the origin in the turn after a remote response | High |
Revocation | Revocation lag: A revoked agent keeps receiving calls because the broker cache has not refreshed | Periodic registry sync | 1. Push revocation events to the broker and refuse delegation when the registry connection is unhealthy 2. Cap broker cache TTLs in minutes, not hours 3. Maintain a deny-list that overrides cached entries | High |
Audit chain | Audit gap: Delegations are logged inconsistently, so a behavior change is hard to investigate later | Per-hop request logs | 1. Log every delegation with the caller, registry entry id, allow / deny decision, and timestamp 2. Retain records long enough to span typical disclosure windows 3. Alert on deny rates that spike or drop unexpectedly | Low |
FAQs
Do I need a broker if my remote agents are all internal?
A local registry inside each origin is enough when the agent pool is small and one team owns both the origins and the remotes. A broker becomes important once multiple origins share the same remote agents, because revocation and audit then need one place to enforce them. The pattern in this post still applies; you are just collapsing the broker and the origin into the same process.
How is this different from approving an MCP tool?
An MCP tool is a function exposed to the origin agent through a server it has already connected to. The trust unit is the tool description and schema. A remote agent is a separate service that can reason and act outside the origin agent’s process. A2A is different because the origin can discover remote agents at runtime. That discovery step creates the new trust boundary.
Verification checklist
Registry is the only callable list
A fetched Agent Card cannot be called unless an approved registry entry exists
A registry entry marked
revokedblocks the next delegationThe endpoint used by the broker comes from the registry, not the card
Identity is bound to a key
Changing the remote signing key blocks delegation until re-approval
A new agent whose name matches an existing entry triggers a review prompt
Payload is bounded
A payload with extra fields is rejected at the broker
The origin's user token is not present in the remote request
The origin's tool credentials are not present in the remote request
Response is treated as remote input
Remote output is labeled with the source
agent_idRemote output enters the origin through the untrusted-input handler, not as system or developer text
Audit and fail-closed
Every delegation attempt is logged with an allow/deny outcome
If the registry is unavailable, delegation is denied
If a broker cache contains an agent later marked
revoked, the deny-list or revocation event overrides the cached entry
Implementation & Review
The full threat model matrix, architectural diagrams, and a printable verification checklist for this pattern are available in the Secure Patterns repository. Use these artifacts to guide your design reviews and internal audits.