Vendor identity verification
Claim your Trust Profile.
Claiming proves control of a pre-recorded canonical identity. It does not improve benchmark results, evidence grade, trust status or ranking.
Claim protocol v1
| Public GitHub repository | GET /api/claim-challenge?type=MCP_SERVER&id=<id>&method=repository |
|---|---|
| Canonical website | GET /api/claim-challenge?type=MCP_SERVER&id=<id>&method=website |
| Publish proof | Place the exact returned token at the returned proof_url, using /.well-known/agent-trust-lab.txt. |
| Verify | Call /api/claim-verify with the same type, id and method. |
| Result | CLAIM_PROOF_MATCHED proves control for the current challenge window. Evidence remains independently evaluated. |
Evidence is a separate flow
Anyone may submit a public artifact for an existing profile through evidence intake. Acceptance for review does not prove identity and never changes claim status automatically.
Why two proof methods?
Public repositories can prove control without credentials. Private repositories cannot be read through public raw GitHub URLs, so a vendor can instead publish the token under the already-recorded canonical website origin. Callers cannot substitute an arbitrary proof URL.
Safety boundary
- The verifier fetches only the pre-recorded canonical repository or website origin.
- The challenge is method-bound, identity-bound and time-bounded.
- A matched claim verifies identity control only.
- Evidence submission is independent from identity verification.
- Benchmark, production, freshness and autonomy evidence remain independently evaluated.
- Unsupported identities return
MANUAL_REVIEW_REQUIRED; they are never auto-claimed.