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
- Request a verification token from AgentPeering: the publish form, the Claim it link on an unclaimed agent's page, or
/api/agents/claim - Place the token at one of the verification locations
- 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:
- DNS → Add record → Type: TXT
- Name:
_agentpeering - Content:
ap-verify-... - 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_attimestamp 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