AI Agent Identity Graph: Connect Names, Services and Proof

Your agent has a directory listing, a manifest and an API. All three use the same name. How does someone establish that they belong together?

An AI agent identity graph maps the relationships between an agent, its operator, public records and service interfaces, along with the evidence supporting those relationships. It lets a caller follow a claim from one place to the source that can confirm it.

The useful part is the connection. A manifest might list an endpoint. A provider might confirm that the endpoint belongs to a particular account. A signed statement might connect that account to the named agent. Those are different claims, and they deserve different checks.

Give every connection a meaning

Think of the agent name, operator, manifest and endpoint as nodes in the graph. The connections between them describe relationships: “operated by,” “publishes,” “provides this service,” or “issued this credential.”

A plain list of URLs loses those distinctions. It can tell you where to go without explaining why that destination belongs to the agent.

This is a way to organize an inspection, not a new universal schema. Each protocol and provider defines its own records and verification rules. You also don't need a graph database to begin; a small relationship inventory can expose the gaps.

For a field-by-field walkthrough of a single record, use How to Read an Agent Identity Record. The graph connects those records across systems.

Keep the records in the systems that define them

Headless Domains documents hosted manifests and Markdown records, with TXT pointers that lead to them. Use the locations returned by the service or published in its records. Don't assume that every headless name serves a website at https://name.agent, or invent a well-known path for a file. The manifest documentation describes the platform's publishing format.

An A2A Agent Card has its own contract. The current A2A specification describes discovery through /.well-known/agent-card.json, catalogs or direct configuration. A card declares interfaces and interaction requirements. A Headless Domains manifest can point toward an A2A service without becoming an A2A Agent Card itself.

Instructions and documentation belong in the map too. The llms.txt proposal helps agents find website information. The Agent Skills specification defines a skill package around a SKILL.md file. Headless Domains also publishes a lowercase /skill.md web guide. Follow the published URL; a readable web guide isn't automatically an installed skill package.

For the fuller format comparison, see AgentCard vs agent.json vs SKILL.md. Here, the question is whether the records describe the same service consistently.

Add the authentication relationship

A caller who finds an API still needs to discover how to authenticate. That connection deserves an explicit place in the graph: the protected resource points to its authentication instructions and, where supported, structured issuer metadata.

The current Headless Domains auth.md guide links its service, API contract, discovery metadata and credential lifecycle. It documents direct API-key provisioning, an authenticated identity endpoint and key revocation.

Its limits matter just as much. Headless Domains says the full signed-assertion and OAuth token-exchange flow is not yet implemented. It also states that advertised supported scopes describe service capabilities, not enforced grants attached to each API key. An identity graph should preserve those distinctions instead of upgrading a published capability into a permission.

Public records can explain how to obtain and manage access. API keys, claim codes and private customer data stay outside the public graph.

Walk one service through the graph

Imagine a supplier's inventory agent called stockcheck.agent. This is a conceptual example, not a claim about a registered name.

A buyer finds the agent in a directory. The listing points to a public record, which identifies the supplier and links to an inventory API. The API documentation names an authentication provider. A paid reporting feature uses a separate payment processor.

Those services don't need identical hostnames. They need explainable relationships.

The buyer can compare the supplier's own published information with the agent record, inspect the declared API, and follow the resource's authentication metadata. If payment goes through another company, the supplier's verified instructions should explain that arrangement. A different payment recipient can be legitimate; a matching display name proves very little.

Now suppose the directory says the agent belongs to one supplier, but the manifest names another. Record the conflict. Don't silently choose whichever page looks newer. Establish which party can substantiate the relationship before relying on it.

The result should be specific: the API relationship is supported, the payment-provider relationship is unresolved, or the operator claim conflicts with another source. “Verified agent” is too broad to describe all of that.

A link is a claim. Record what was actually checked.

Two pages linking to each other can help someone navigate. If both are controlled by the same impostor, they don't independently establish the claimed company affiliation.

Likewise, a signature proves something only after the verifier establishes which key to trust and what the signature covers. A successful request shows that an interface worked under the conditions tested. It doesn't establish every claim about its operator or capabilities.

For each important relationship, keep the source, the evidence examined, the check performed and the time of that check. Leave unsupported claims visibly unresolved. That gives the next reviewer something more useful than a checkmark.

Headless Domains' Action Card v1 schema reflects this separation through fields for claim sources, provider provenance, verification evidence, invocation requirements and lifecycle status. It describes what a provider exposes and what evidence is available.

The public API contract explicitly defines the resolver as read-only identity and action discovery. Resolving an action does not authorize it or make Headless Domains execute it. The receiving provider still has to enforce access.

Connect payment references without publishing the transaction

The public graph can point to payment documentation and the service that handles a purchase. Keep private mandates, customer details and transaction evidence in the systems responsible for them.

Payment verification follows the selected protocol and implementation. A public name isn't a prerequisite for using x402, AP2 or MPP, and putting a payment URL in a manifest doesn't enable checkout. Our payment protocol comparison covers their different jobs.

Start with the connections your agent already uses

Choose one existing agent and map its operator, public record and working service interface. Add authentication, instructions, directory listings or payment references where that service actually uses them. You don't need every file or protocol mentioned in this article.

Then inspect the connections. Does each destination exist? Does it describe the expected service? Who supplied the claim, and what supports it? Fix unexplained relationships before adding more links.

As the service changes, revisit the affected connections. Our canonical identity guide covers continuity through migrations and key changes. The Agent Identity Stack covers the broader management framework.

Headless Domains gives the agent a maintained public name and records that help others follow these relationships. The useful test is whether someone arriving from a listing can establish which service they're looking at and where to go next.

Give your agent the Headless Domains skill file and ask it to explain how to register a name and connect the public records for the service you already operate, before making changes or payments.

Documentation checked September 10, 2026. Platform capabilities and protocol requirements depend on the current implementation and configuration.