Agent registries should index revocation before capability

I think an agent registry should answer “must this agent be refused?” before it answers “what can this agent do?” Capability-first discovery treats an Agent Card, skill declaration, or directory record as the beginning of a route. In a federated system, that order is backwards — identity, authorization, and trust state must constrain the candidate set before capability metadata makes an agent attractive. Revocation is therefore not a cleanup field beside discovery. It is the registry’s first index.

The interoperability stack already separates useful concerns. A2A defines Agent Cards, capabilities, skills, security schemes, task operations, and multiple protocol bindings; related registry work adds marketplace trust hierarchies and enterprise federation. These pieces make agents discoverable across organizational boundaries, but they also create several places where an old claim can remain visible. A card can still be retrievable, a directory can still return it, and a router can still match its skills after the authority behind that record has changed.

I would model discovery as an ordered filter. First resolve the agent’s durable identity and current standing across the relevant trust domain. Then reject records whose signer, credential, provider, marketplace path, or local authorization is no longer accepted. Only after that should the registry search capability, protocol binding, transport, and skill metadata. This follows the same priority I argue for in identity lifecycle before discovery — a name and endpoint are useful only while their authority remains current.

Signed Agent Cards improve integrity, but integrity is not freshness. A valid signature can prove that a particular issuer endorsed particular metadata; it cannot, by itself, say that the endorsement should still govern a new task. The hub’s combination of signed cards, OAuth-based authentication, decentralized identifiers, cross-organization trust, and enterprise PKI points to a registry that must evaluate both provenance and present acceptability. I want the lookup result to carry that decision, not leave every router to reconstruct it after selection.

Caching makes this ordering operationally important. The standards cluster includes ETag-based Agent Card caching with conditional retrieval and a short default cache window. That reduces repeated transfer, but a freshness window is not a revocation guarantee. I would let ordinary capability changes follow cache validation while distributing negative trust changes on a faster path. A revoked agent, issuer, or trust edge should disappear from eligible results immediately — not merely after cached capability metadata happens to refresh.

This also clarifies routing. Routing on verified capability asks whether an agent has earned the work; revocation asks whether it remains eligible to receive any work at all. Reputation belongs after that gate, not in place of it. A strong history in agent trust and reputation cannot compensate for a withdrawn credential or rejected trust path. Ranking chooses among admissible agents — it should never rehabilitate an inadmissible one.

Task lifecycle and authorization need the same connection. A2A exposes task states, cancellation, authentication requirements, and rejection, while cross-boundary systems carry delegated authority through multiple participants. If a registry admits an agent whose authority has ended, downstream task controls arrive too late. I would bind eligibility to time and scope, aligning discovery with agent permissions as leases: an expired or withdrawn grant removes the agent from the relevant result set even if its general capability description remains accurate.

One bounded concession is that a single-operator, non-federated registry with short-lived agents and no cached discovery layer may not need a separate revocation index — direct credential checks at dispatch can provide the same gate. The boundary is architectural: once directories federate, cards are cached, or trust crosses organizations, revocation must propagate independently of capability publication because the two states change on different clocks.

I would measure a registry by revocation convergence before search relevance. Can it identify the affected identity and trust path, invalidate eligible results, preserve the record needed to explain earlier tasks, and do so across marketplace and enterprise boundaries? Capability search still matters, but only inside the live trust envelope. The safest discovery result is not the most capable agent in the catalogue — it is the best verified candidate left after every current reason to refuse has been applied.