The agent card is not a warrant

The newest agent protocols make discovery feel almost ordinary. A client retrieves a document, learns what a remote agent calls itself, sees the skills it offers, and decides whether to send work. What used to require a bespoke integration can begin with a well-known URL and a machine-readable description.

That is real progress. The Agent2Agent discovery model gives remote agents an Agent Card containing identity, endpoint, capabilities, authentication requirements, and skills. It gives software a common way to answer a useful question: what does this service say it can do?

The danger is answering a different question by accident. A card is a claim made by a service about its own capabilities. It is not a warrant to exercise those capabilities for this caller, on this subject, under these conditions. Discovery can tell an orchestrator that an agent offers invoice reconciliation. It cannot establish that the orchestrator may disclose a particular invoice, that the agent may contact the vendor, or that either system may approve a payment.

Description is not delegation

Machine-readable descriptions encourage a subtle compression. A skill has a name, examples, input modes, and output modes. The client can match a task to those fields and produce a technically valid request. Because the match is explicit, the resulting action can appear authorized by construction.

But a capability description says nothing about the source of authority. An agent that can cancel reservations may be permitted to cancel its operator's reservations, only reservations created through one account, or none without a fresh confirmation. The verb is the same in every case. The institutional meaning depends on identity, relationship, purpose, time, and scope.

A2A keeps credentials outside protocol messages and declares authentication requirements in the Agent Card. That is an important boundary, reflected in its core concepts. Yet authentication only establishes who presented a credential. Authorization still has to connect that identity to the particular act. A valid bearer token and a matching advertised skill can coexist with an impermissible request.

Discovery answers who might do the work. Authority answers who may cause this work to be done.

This distinction becomes sharper when one agent selects another. The initiating agent may have broad access to understand a problem but narrow authority to change anything. If it chooses a specialist based only on advertised skill, it can transform informational access into operational delegation. The second agent sees a valid caller. The first agent sees a capable service. Neither view proves that the human or institution authorized the handoff.

Cards can change while trust persists

Agent Cards are designed to evolve. Skills are added, authentication requirements change, and clients may cache the document. The discovery guidance recommends normal HTTP controls such as cache lifetimes and ETags. That is sensible engineering, but it also means the description used for selection has a version and a time.

A trusted relationship formed around yesterday's card can silently encounter a broader service tomorrow. A skill may keep its identifier while its implementation, provider, or downstream tools change. A cached card may omit a newly required restriction. A live card may advertise a new extension that an older client interprets too generously. Interoperability does not remove version drift; it gives drift a common transport.

The latest A2A specification permits Agent Cards to be signed and recommends verification when signatures are present. Its security requirements also distinguish public cards from authenticated extended cards. A signature can establish who made the description and whether it changed in transit. It cannot establish that every advertised capability is suitable for a given use, or that a card remains approved by the relying institution.

Selection therefore needs its own policy: which issuers are trusted, which card versions were reviewed, which skills are allowed for which task classes, which extensions are understood, and when a changed card requires renewed approval. The card belongs in the evidence for a task because it explains what the selecting agent believed was available at the moment of delegation.

Make the handoff explicit

A defensible handoff should bind four things that discovery leaves separate: the requesting principal, the selected remote identity, the exact task, and the authority under which the task may proceed. It should preserve the card or its digest, not merely the agent's friendly name. It should also state the permitted effects, the data that may cross the boundary, and the condition that ends the delegation.

The receiving agent should not infer these facts from the richness of the request. A detailed task can still be unauthorized. Nor should the sending agent treat successful authentication as proof that the receiver is approved for the data involved. Each side owns a different check, and both checks should be visible after the work is done.

Revocation must follow the same object. If a card is withdrawn, a skill is disabled, or an issuer loses trust, the institution needs to know which open tasks were selected under the earlier claim. New discovery should stop new delegation, while already-running work should face an explicit choice: continue under the preserved approval, pause for review, or cancel. Quietly applying today's card to yesterday's handoff rewrites the basis on which the work began.

This makes open discovery more useful, not less. Institutions can benefit from portable capability descriptions while keeping authority local and explicit. New agents can be found without being silently trusted. Known agents can evolve without inheriting indefinite permission. Automated selection can remain fast because the policy boundary is defined before selection begins.

An Agent Card is a valuable introduction. It is not a badge, a contract, or a warrant. The moment a system treats it as all three, interoperability stops being a way to connect software and becomes a way to move authority without admitting that authority moved.

— Dispatches · Summit Cognitive