Google ARD introduces domain-hosted catalogs, registries, and trust metadata so agents can discover approved tools across organizations safely.
What ARD Adds to Agent Discovery
Google ARD (Agent Resource Discovery) defines how organizations publish machine-readable catalogs of tools and services that agents are allowed to use. Instead of hard-coding endpoints or scraping informal docs, an agent resolves a domain-hosted catalog, reads registry entries, and evaluates trust metadata before it calls anything. The goal is safer cross-organization discovery: the same discovery path works whether a tool lives in your own stack or in a partner’s, as long as both sides publish under the same conventions.
At a practical level, ARD separates three concerns that often get mixed together. The catalog answers “what exists here.” The registry answers “how do I address and invoke it.” Trust metadata answers “should I trust this entry for this purpose.” Keeping those layers distinct makes it easier to update approvals without rewriting agent code, and easier to audit why an agent chose one tool over another.
Domain-Hosted Catalogs and Registries
Hosting the catalog on a controlled domain is the control point. Operators publish approved tools under infrastructure they already own—DNS, TLS, and access policies—so discovery inherits the same security perimeter as other public metadata. Agents fetch catalogs from well-known locations on that domain, parse structured entries (identifiers, endpoints, capability descriptions, and optional constraints), then use the registry view to resolve a concrete invocation path.
Design the catalog so entries are stable and incremental. Prefer opaque, durable IDs over names that change with rebrands. Version capability descriptions carefully so agents can pin to a known interface. Document required auth schemes, scopes, and rate or tenancy limits in the registry fields agents will actually read—not only in human README pages. When a tool is deprecated, leave a clear tombstone entry rather than a silent 404; discovery failures should be explicit so agents can fail closed or fall back deliberately.
Trust Metadata That Agents Can Enforce
Trust metadata turns “we listed this tool” into “we endorse this tool under these conditions.” Typical signals include publisher identity, attestation of integrity or provenance, policy tags (for example, allowed data classes or environments), and revocation or expiry hints. Agents should treat missing or unverifiable metadata as a hard stop for production paths, not as soft advice.
- Validate publisher identity and signatures before accepting any endpoint from a foreign domain.
- Match policy tags against the agent’s current task and data sensitivity, not just capability names.
- Cache catalog results with short TTLs and re-check revocation when long-running jobs resume.
- Log the catalog URL, entry ID, and trust decision so security review can reconstruct the chain.
Across organizations, mutual discovery only works if both sides agree on how trust is expressed and verified. Publish the minimum fields partners need to automate checks; keep optional marketing copy out of the machine-readable path so parsers stay simple and security review stays focused.
Putting ARD Into Day-to-Day Agent Design
Wire discovery into a single gate in your agent runtime: resolve catalog → filter by capability and policy → verify trust → invoke. Do not let free-form tool URLs bypass that gate in production. For multi-tenant systems, scope which catalogs each tenant may load, and refuse cross-tenant registry entries unless an explicit federation rule allows them. For local development, use a private catalog that mirrors production shape so agents learn the same discovery flow without pointing at live partner endpoints.
When something breaks, debug at the ARD layer first: Is the catalog reachable and authenticated? Did an entry change identity or endpoint? Did trust metadata expire or fail verification? Most “agent can’t find the tool” incidents are catalog freshness, policy mismatch, or trust checks—not model reasoning. Treat ARD as infrastructure you operate and monitor, and discovery stays a controlled path for approved tools instead of an open invitation to the open web.