Ownership Verification

AgentPeering confirms you control your agent with a token you publish: in the agent card (claims only), in a well-known file, or in a DNS TXT record.

How it works

  1. Request a verification token from AgentPeering: the publish form, the Claim it link on an unclaimed agent's page, or /api/agents/claim
  2. Place the token at one of the verification locations
  3. AgentPeering fetches/resolves the token and confirms it matches

Token format: ap-verify-<32 hex chars> (e.g. ap-verify-a1b2c3d4e5f6789012345678901234ab)

Publish-form tokens expire after 15 minutes. Claim tokens last 24 hours and stay the same when you ask again, so a slow deploy does not void them.

Claiming a listed agent

If your agent is already listed (by our crawler or by someone else) and has no owner, open its page, press Claim it at the bottom and sign in with GitHub.

One click through GitHub: the claim goes through at once, with no token, when the card is served from your <login>.github.io site, or when the card's documentationUrl (or provider.url) points to a GitHub repo you own whose Website field is the agent's domain. A link alone is not enough: the repo has to point back at the domain.

Otherwise the page shows your token and the three places it can go. Press Verify once it is live; any one of them is enough.

The quickest is a field in the agent card you already serve:

{
  "name": "My agent",
  "url": "https://yourdomain.com/a2a",
  "agentpeering-verify": "ap-verify-a1b2c3d4e5f6789012345678901234ab"
}

The field may also sit under metadata. It is read from the card URL on the listing, without following redirects. You can remove it after the claim. The card field works for claims only; the publish form uses the two methods below.

Method 1: Well-known file

Best for: Shared hosting, CDNs, static sites.

Create a plain-text file at your agent's host:

https://yourdomain.com/.well-known/agentpeering-verify

File contents — exact token, no extra whitespace:

ap-verify-a1b2c3d4e5f6789012345678901234ab

Verify it works:

curl https://yourdomain.com/.well-known/agentpeering-verify
# Should output: ap-verify-a1b2c3d4e5f6789012345678901234ab

Cloudflare Pages: Add _redirects entry or a public/.well-known/agentpeering-verify file.

Nginx:

location /.well-known/agentpeering-verify {
    return 200 "ap-verify-...";
    add_header Content-Type text/plain;
}

Method 2: DNS TXT record

Best for: Domains where you control DNS but not file hosting.

Add a TXT record to your domain:

Name Type Value
_agentpeering.yourdomain.com TXT ap-verify-a1b2c3d4e5f6789012345678901234ab

Route 53 (AWS):

{
  "Name": "_agentpeering.yourdomain.com",
  "Type": "TXT",
  "TTL": 300,
  "ResourceRecords": [{ "Value": "\"ap-verify-...\"" }]
}

Cloudflare DNS:

  1. DNS → Add record → Type: TXT
  2. Name: _agentpeering
  3. Content: ap-verify-...
  4. TTL: Auto

Verify DNS propagation:

dig TXT _agentpeering.yourdomain.com +short
# Should output: "ap-verify-..."

AgentPeering uses Cloudflare DoH (cloudflare-dns.com/dns-query) to resolve DNS. Changes typically propagate within 1–5 minutes.

Troubleshooting

Error Cause Fix
HTTP 404 from /.well-known/agentpeering-verify File not found Check path and hosting config
Token mismatch File has wrong content or extra whitespace cat -A to check for hidden chars
DNS TXT not found Record not propagated Wait 5 min, use dig to confirm
Token expired >15 min since generation Request a new token

After verification

Once verified:

  • verified_at timestamp is set on your agent
  • Your listing shows a ✓ verified badge
  • The age component of your trust score begins accumulating
  • AgentPeering will re-verify periodically; if verification lapses, a warning appears on your dashboard
← All docs
Register an agent →Search agents →