Agent Registries Tell You What Exists, Not Whether You Can Still Trust It

Picture an agent in a routine run that looks up a tool by name, calls it, gets a sensible answer and carries on. The run succeeds, and that is the unsettling part, because nobody on the team ever reviewed that capability. Registries and discovery services are supposed to bring moments like this under control, and within a single week several products and specifications arrived that all claim to be that control layer.

None of them is wrong, but together they address only half of what a team needs to know before an agent uses a new capability. This article breaks the problem into four distinct questions, shows which ones current registries answer, and gives you a concrete check, plus a short action list, for the half they leave open.

What arrived in the registry layer

The details below reflect announcements at the time of writing; check current documentation before relying on specific features or version numbers.

AWS Agent Registry

Agent Registry on AWS is now generally available. Think of it as a private catalog, with governance built in, that can hold agents, MCP servers, A2A agent cards, skills and arbitrary custom resources. The design keeps two planes apart on purpose. Curators work in a governance plane where entries are approved or turned down; consumers query a discovery plane that only ever exposes approved entries. Each record moves through five states (draft, pending, approved, rejected, deprecated). EventBridge events drive transitions between them, and CloudTrail keeps the audit log.

With general availability came infrastructure-as-code support (CloudFormation, CDK and Terraform), sharing across accounts via RAM, and automatic detection, across a whole organisation, of agents that are already running on AgentCore. That detection feature is easy to overlook, and it exists because untracked "shadow" agents have already become a genuine inventory headache. Named adopters include Southwest, PepsiCo, Syngenta, Amdocs and Sony, which suggests buyers have moved beyond debating pilots. AWS describes the design in detail on its machine learning blog.

Agentic Resource Discovery (ARD)

Alongside it, a specification backed by several vendors tackles the same gap. Agentic Resource Discovery was written by contributors from Google, Microsoft and Hugging Face and released under Apache 2.0, with NVIDIA, Salesforce and Databricks also contributing. The New Stack's coverage frames it as DNS for agents. Its surface is intentionally small. Messages are JSON-LD over REST. Exactly one endpoint is mandatory, POST /search, and it is queried with a description of the task instead of a resource name. Browse endpoints are optional. Federation lets a company keep its own catalog private while passing queries on to outside registries it has chosen to trust. At the time of writing the spec sits at version 0.91, its governance model is still open, and the W3C has been mentioned as one possible home.

Continuous vetting as a product

The third launch was a startup, AIR, which came out of stealth having raised $50 million over two seed rounds (Sequoia led the first, Greenoaks the second). Its business is inspecting the plug-ins, skills and MCP servers that agents load. One statistic from them is worth keeping in mind: roughly 27% of the publicly sourced skills and add-ons they currently assess get filtered out.

When three launches target one layer within days of each other, it usually means the industry has reached consensus about where the missing piece sits.

Why discovery is not MCP's job

MCP never claimed to solve discovery. It defines the mechanics of invoking a tool after the agent has already settled on which one to use. A2A does the equivalent for conversations between agents that already know about each other. In both cases, locating and selecting the capability is assumed to have happened earlier. If you want a refresher on that division, see how the Model Context Protocol lets agents discover and call tools.

What changed is volume. Wiring MCP servers by hand is manageable with a dozen tools. With over a thousand, owned by different internal teams, SaaS providers and cloud platforms, an agent restricted to a hardcoded list in its config is barely an agent; it is closer to a fixed script that happens to call a model. Discovery lets the set of capabilities change at runtime. The same property means nobody has audited that set, and few teams have priced in that trade-off.

A second pressure comes from how agents are being extended. Researchers who read the source of eleven production coding harnesses, about four million lines covering tools such as OpenHands, Gemini CLI, Codex CLI and Claude Code (arXiv 2609.00006), found that skills in the SKILL.md style have overtaken MCP there: nine of the eleven harnesses support skills, eight support MCP. So the extension mechanism spreading fastest is a Markdown file full of instructions an agent will execute. Such files come with no signing mechanism and hardly any versioning, so a registry entry pointing to one tells you little about what it will do tomorrow.

Four questions a registry should answer

Whenever an agent is about to use a capability that was not available to it recently, four separate answers are needed. They sound similar but they are different problems, and separating them shows what a given product actually does compared with what it is being bought for.

Existence: is there something that does this?

Is there any capability that handles this task, and where is it hosted? This is the job ARD's POST /search targets, and the AWS discovery plane does it well. The problem is genuine, and for practical purposes it is now close to solved.

Fitness: which candidate is right for this task?

A search returns several candidates, so which one should the agent use? The ARD authors themselves say the DNS comparison breaks down here: a query yields candidates rather than one authoritative address, and each service applies its own trust and ranking rules. Leaving that open is reasonable for a young specification. It is not reasonable for your deployment, because ranking is precisely where an attacker would most like to insert themselves, much like search-engine poisoning or typosquatting in package registries.

Standing: is it approved right now?

This is where AWS is strongest: lifecycle states plus events give a well-modelled answer, more mature than anything else in these systems. The weakness is that an approval ages. Suppose an entry was picked up by auto-detection, approved in March and then ignored. Come September, discovery still hands it out as confidently as something a curator checked this morning.

Provenance: who wrote it and what has changed?

Who authored this capability, what has changed since anyone last looked, and what does it load at runtime? Nothing in the current wave of launches answers this, and it is the whole premise behind AIR's funding. Their position, which holds up, is that vetting has to be continuous rather than a one-time gate. A skill that passed review a month ago can turn malicious after a dependency update or a hijacked maintainer account, while its catalog entry stays exactly the same. Academic work points the same way. Recent research on the foundations of skill-based agents (arXiv 2608.29596) models a lifecycle of nine stages and places public registries, marketplaces and adversaries at the centre of the architecture instead of treating them as operational afterthoughts.

Search problems versus supply-chain problems

The first two questions are about search. The last two are about the supply chain, and the industry has been through this before with browser extensions, container base images and npm packages. In each case, catalogs existed long before anyone could vouch for what was in them, and the security incidents clustered in that interval.

The last-verified test

This check is deliberately small, because the answer matters more than the framework. Take your current list of agent capabilities, a proper registry or just a spreadsheet, and choose any single entry. Then look for two timestamps:

• When was it approved?
• When did anything, a person or an automated job, last compare it with its source?

When those timestamps match, you are holding a catalog rather than a control plane. The first records a past decision; the second reflects present reality. Count the days between the two dates: that is how long a capability someone approved and then forgot has been free to change without anyone noticing. Given that around a quarter of publicly available skills already fail basic vetting, that number is a fair measure of your real exposure.

Many teams have no second timestamp to show. That absence is the real result: the problem is not a bad value but a missing field.

What to do this quarter

The practical plan has three parts, in order of effort.

1. Adopt a registry. Inventory is a genuine problem, and an untracked agent is more dangerous than an untracked SaaS subscription since it acts on its own. Teams already building on Bedrock should look hard at the AWS option; those who need federation and vendor neutrality may prefer ARD.
2. Add the field the registry lacks. Give every entry a last-verified timestamp that an automated job updates, not a human. Decide in advance what staleness triggers: expiry, quarantine or an alert. Any one of those is better than today's typical behaviour, where a stale entry simply stays live indefinitely.
3. Assign ownership of fitness. When discovery hands back three options and the agent simply uses the top one, the registry's default ordering has quietly become your selection policy. Nobody chose it, and it is the least expensive thing here to change, for example with an allowlist of trusted publishers or an explicit scoring rule.

A useful companion to this plan is a runtime control layer that decides what a discovered capability may actually do; permissions, approval gates and risk tiers for agents covers that side.

Key takeaways

• Registries and discovery specs now answer "what exists" and "is it approved" reasonably well.
• "Which candidate is right" and "who vouches for it today" remain open, and they are supply-chain questions, not search questions.
• Approval is a state that decays; without a last-verified date, a catalog cannot tell current trust from historical trust.
• The cheapest wins are an automated verification timestamp with a staleness policy and an explicit ranking rule for discovered candidates.