Skip to content
Go back

Agentic Resource Discovery Still Needs a Verification Boundary

Updated:
Commentary

Originally published onLinkedIn on 15 Jul 2026.

Junjie Bu and Srinivas Krishnan’s announcement of Agentic Resource Discovery gives its authors explicit credit for addressing a real architectural gap: an agent may know how to call an MCP server, an A2A agent, or an API, yet have no interoperable way to discover that the capability exists. Their specification introduces catalogs published under an organization’s domain and registries that index those catalogs for search.

That separation is useful, but it also marks the boundary that implementers must not blur. Discovery can produce a candidate capability. It cannot, by itself, establish that invoking the capability is appropriate for a particular user, task, or data set.

What the specification gets right

ARD separates two responsibilities that are often hard-coded into one platform:

This makes discovery independent of the execution protocol. An organization can publish MCP servers, agents, APIs, or nested catalogs without requiring one universal runtime. Domain anchoring also gives the client a stronger provenance signal than an unqualified entry copied into a central marketplace.

The resulting architecture resembles the open web more than a plugin directory: publication is distributed, indexing can be federated, and clients are not required to use one global registry.

Discovery is not authorization

The dangerous implementation shortcut would be:

  1. ask a registry for a capability;
  2. accept the highest-ranked match;
  3. load it into the agent’s execution context;
  4. allow the model to invoke it.

Each step introduces a separate claim. A registry result claims relevance. Domain control claims provenance. Cryptographic metadata may establish identity and integrity. None of these claims establishes least privilege, data-handling suitability, or permission for a particular operation.

A production client therefore needs an explicit verification boundary between discovery and execution. At minimum, that boundary should check:

The discovered description should be treated as untrusted input until those checks succeed.

What remains unresolved

ARD is still an evolving specification. A common schema does not yet tell us how different registries will rank results, handle stale catalogs, respond to compromised publishers, or expose conflicts between similarly named capabilities. Domain ownership is a useful root of provenance, but a genuine publisher can still publish an unsafe or unsuitable tool.

Federation also moves part of the quality problem into search. A client may receive different candidates as registries update their indexes or ranking policies. Reproducible agent runs will therefore require more than logging the natural-language query: they should preserve the selected resource identity, catalog version, verification evidence, registry response, and policy decision.

A testing model for discovery systems

ARD clients should be tested as security-sensitive resolvers rather than as ordinary search boxes. Useful adversarial cases include:

The core assertion is not simply that the client finds a tool. It is that no discovered tool crosses into execution without inspectable evidence for identity, compatibility, policy, and authorization.

ARD can become an important discovery layer for multi-agent systems. Its strongest use will come from keeping that layer narrow: find candidates, preserve provenance, and hand them to a separate verification and governance mechanism before anything is allowed to act.


Share this note

Previous Note
Chain-of-Thought Prompting Can Improve Answers; It Is Not Proof
Next Note
Token Usage Is an Input Cost, Not an Engineering Outcome