Reference

Trust in agentic discovery

Serving a manifest proves control of a domain. Every other field in it is an assertion, and knowing which is which is most of the security model.

The only thing a manifest proves

A manifest at /.well-known/ard.json proves exactly one fact: whoever served it controls that domain, or controls something that answers for it. That is a genuine and useful proof. It is also the only one on offer.

Everything else in the document is an assertion. The display name, the description, the tool list, the queries it claims to answer, the publisher it names: a registry reading the file cannot check any of it. This is not a flaw in the specification. It is the same trust model as a web page, and it is worth stating plainly because discovery output tends to be read as though it were vetting.

Publisher authority, and why identifiers are not names

ARD identifiers use a URN form:

urn:air:example.com:mcp:invoicing

The second segment is the publisher. Nothing prevents a manifest from writing somebody else's domain there, which would be an obvious way to borrow a reputation. What makes the field usable is where the claim was found: a publisher segment is credible when the manifest asserting it was served by that publisher's own domain, and is a claim about a third party when it was not.

This is the same reasoning that makes a well-known path meaningful in the first place. The location is the proof; the content is the claim. A registry that indexes an entry naming stripe.com from a manifest served by not-stripe.example has found an assertion about Stripe, not a Stripe resource, and should treat it that way.

What this means if you publish

Serve your manifest from the domain you are naming. If your resources live on api.example.com but your manifest is on example.com, that is normal and fine: the registrable domain is what binds. What is not fine is publishing entries whose publisher segment names a domain you do not control, even with good intentions, because a consumer applying the rule correctly will discount them.

Tool descriptions, and the injection question

An MCP tool description is written by the publisher and read by a model. That is, by construction, a channel from a stranger into an agent's context, and it is the part of the stack most worth being careful about.

It is also worth knowing the base rate rather than assuming it. Across 97,472 tool descriptions from 5,079 servers reachable in a public index, the shape of the problem measures like this:

Two conclusions, and they point in different directions.

There is nothing here to score. A safety grade computed over this distribution would be a number attached to thousands of honest publishers in order to flag a handful, and the first draft of that scan flagged legitimate publishers whose descriptions were in a non-Latin script or who work in security and therefore write about attacks. A count and an excerpt are defensible. A grade is not.

And a rare risk is still a risk. A base rate near zero says nothing about the one description that matters, because an agent acting unsupervised needs to be wrong only once. The mitigation is not a registry badge. It is treating a tool description as untrusted input at the point where it enters a prompt, the same way a form field is treated as untrusted input at the point it enters a query.

What an agent should check before it connects

1. The host is the one the entry named. Follow redirects with the same suspicion you would apply to a link in an email: a discovery result that lands somewhere else is worth stopping for.
2. The publisher matches the domain that served the manifest. If it does not, the entry is a third-party claim and should be weighted as one.
3. The tool list matches the expectation. A manifest that promised one capability and a session that offers twenty, including several that write, is a discrepancy worth surfacing to a human.
4. Descriptions are data. Whatever a description says about how the agent should behave is a string the publisher chose, not an instruction from the operator.

What a registry can honestly tell you

The useful signals are observations, not judgments, and they are things a registry is in a position to know:

• Whether it answered. A count of probes and how many got a response, which is a fact about behaviour over time rather than a promise about the future. Of 8,593 endpoints where a connection was attempted, 2,628 completed a handshake and returned a tool list, 2,094 required credentials, and 1,237 answered 404 at the address their own entry gave.
• Whether the domain was verified. A DNS record proving control is a real credential, and a registry either has it or does not.
• What changed. A tool list that gained a destructive capability last Tuesday is a fact worth knowing, and one nobody can see without watching over time.

None of those is a trust score, and the absence is the point. The honest output of a discovery layer is a set of observations with dates on them, handed to something that can decide.

Questions

curl -X POST https://neuronto.com/submit \
  -H "Content-Type: application/json" \
  -d '{"url": "https://yourdomain.com"}'

Last reviewed 2026-09-05. Checked against ARD v0.91 (Proposal, 2026-08-26).