Agentic Resource Discovery: Why Self-Published Catalogs Are Not Enough

In June 2026 an open Agentic Resource Discovery specification was announced, and it is a genuinely useful piece of infrastructure. The problem it solves is real: as agents proliferate across frameworks and providers, there has been no common way for one agent to find out which capabilities another organization offers, or to confirm that what it found is authentic. ARD gives that a standard answer. An organization publishes a catalog on its own domain - a file, ai-catalog.json, describing the agents, tools, and resources it exposes. Registries index those catalogs so agents elsewhere can discover them, cryptographic verification confirms the publisher's identity, and the discovering agent connects using the resource's native protocol. It builds on a foundational AI Catalog data model from a Linux Foundation working group and launched with industry partners, and at least one cloud agent platform pairs the spec with a hosted Agent Registry that adds governance through namespaced identifiers, egress policies, and resource verification tied to agent identity.

All of that is good, and none of it is what a security team means when it asks whether it has discovered the agents in its environment. ARD is publisher-side and opt-in. It standardizes what an organization chooses to advertise to the outside world. The question a security team has to answer is the inverse, and it is not outward-facing at all: what is actually installed and running on our employees' machines, whether or not anyone chose to declare it. Those are two different kinds of discovery, and conflating them is how a real capability gets mistaken for a control it was never designed to be. This post keeps them apart.

What Agentic Resource Discovery actually standardizes

It is worth stating plainly what ARD does well, because the argument here is not that it falls short - it is that it answers a different question. ARD solves inter-organization interoperability and trust. Before it, an agent that wanted to use a capability published by another company had no standard way to find it, and no standard way to be sure the endpoint it found was really operated by whoever it claimed. The catalog-plus-registry-plus-verification pattern fixes exactly that: discovery of what exists out there, and confirmation that it is authentic. For anyone weighing the emerging discovery landscape, that outward-facing layer is one input among several, a point developed in an enterprise buyer's guide to AI discovery. The mechanism is deliberately declarative: publishing a catalog is a choice, and its contents reflect what an organization wants other agents to see and use.

Two kinds of discovery: declared and observed

The cleanest way to see the boundary is to put the two discovery models side by side. One is discovery by declaration: an organization writes down what it offers and publishes it, and everyone downstream reads that declaration. The other is discovery by observation: a sensor looks directly at what is present on a system and reports what it finds, regardless of whether anyone declared it. ARD is the first kind. Fleet security depends on the second.

Read down the table and the division of labor is obvious. Declaration is the right tool for a problem where the publisher is cooperative and the goal is interoperability - you want the catalog to be an accurate advertisement, and the publisher wants that too. Observation is the right tool when the goal is posture and the interesting cases are precisely the ones nobody thought to declare. Neither substitutes for the other, and a mature program runs both.

The things that will never appear in a catalog

Every meaningful gap in fleet visibility lives on the observation side of that line. Consider what a security team actually loses sleep over. The MCP server a developer added to a local project last week to reach an internal database. The skill someone side-loaded from a gist because it saved them an afternoon. The CLI coding agent that nobody registered, running with the developer's own credentials and cloud sessions. The connector quietly wired to a production system by an engineer solving a real problem. None of these will ever appear in an ai-catalog.json, because the people who installed them were not publishing a catalog - they were getting work done. What that unmanaged layer looks like in practice is the subject of what we found scanning real AI configurations.

This is also why an inventory built from declarations alone is structurally incomplete for MCP in particular. A catalog can list the MCP servers an organization offers to others; it says nothing about the MCP servers running inside the organization, on developer laptops, pointed at internal systems. Building that inside-facing view is a different discipline, closer to how to build an MCP server registry than to reading a public catalog, and it depends on understanding what an MCP server can actually do once it is connected. The advertised catalog and the installed reality are not the same set, and only one of them is a security surface.

Verification proves the publisher, not the posture

ARD's cryptographic verification is a real strength, and it is worth being precise about its scope too. It confirms that a catalog was published by whoever it claims - that the identity behind an advertised capability is authentic. That is verification of an outward-facing identity: this organization really does operate this resource. The identity question inside a fleet is a different one. It is about the non-human identities that agents and their tools carry - the tokens an MCP server holds, the machine identity a CLI agent runs under - and about the trust boundaries between agents that hand work to one another. Those are the substance of non-human identity governance, AI identity security, and agent-to-agent trust boundaries. A verified catalog entry tells you an external capability is genuine; it does not tell you which identities are active on your own endpoints, or what they can reach.

Complementary, not competing

The right posture toward ARD is to adopt it for what it is and not to expect it to do what it cannot. Declared discovery and observed discovery are complementary. ARD standardizes the outward-facing catalog and the trust layer between organizations, which the whole ecosystem benefits from. Observed discovery provides the inward-facing inventory of what is actually present on your fleet, which is the input every governance and audit decision depends on. The same split runs through the broader trend line - capability standardizing and spreading outward while internal posture lags behind - which is the theme of the agentic AI trends of 2026 and the visibility gap behind each. An organization that treats a public catalog as its asset inventory has confused the advertisement for the warehouse.

A catalog tells you what an organization advertises. It cannot tell you what is installed on the machine in front of you.

How Anomity provides the observed side of discovery

Anomity is built for the inward-facing half of this picture. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint across Windows, macOS, and Linux and discovers eight AI artifact types directly from the system - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - whether or not any of them was ever declared anywhere. That is discovery by observation, and it is the exact complement to a published catalog: it sees the local MCP server, the side-loaded skill, and the unregistered CLI agent that ARD is not designed to surface. How that discovery works is walked through in inside Anomity discovery, and turning it into a maintained, queryable record is the methodology in how to build an AI agent inventory.

From that observed inventory the platform does the two things a catalog cannot. It gives you a live fleet inventory collected as metadata only, with secrets redacted on the endpoint before anything leaves it. And where an agent exposes a hook, such as a Claude Code PreToolUse hook, it returns an allow, deny, or log decision before the tool call runs - enforcement, not a request - with every change landing in a queryable 90-day audit trail routed to your SIEM, Slack, email, or Jira. It is SOC 2 Type II and complements your network, EDR, DLP, and GRC controls rather than replacing them. See how it works, where it sits next to your existing stack, and the documentation. Adopt ARD for interoperability and trust between organizations; use observed discovery for posture inside your own. If you want the agentic surface on your fleet inventoried and governed rather than assumed from a catalog, request early access.