Trust Center

AgenID v1.1.1 is the current locked specification, published and MIT-licensed at AgenID-protocol/spec. Two errata are on record — a key-identifier URI fix and a number-domain canonicalization rule (E1), and the namespace unification onto a single agenid.com domain (E2). Any future change to identity, cryptography, serialization, or verification semantics requires a published erratum before any implementation follows it; the spec is the source of truth, not the code.

Manifests and assertions are canonicalized with RFC 8785 JSON Canonicalization Scheme (JCS) before signing — the signing input is the JCS bytes of the signed object minus its signature field, and the $schema field is part of what’s signed.

Signatures are pure Ed25519 (RFC 8032) over those canonical bytes directly — no Ed25519ph, no external pre-hash step. The only SHA-256 in the protocol produces the manifest_digest data value, which the signature binds; SHA-256 is never itself the signed input.

The §8.7 number-domain rule rejects non-finite values and rejects integer-literal canonical tokens with magnitude greater than 2⁵³−1 — documented as a rejection case, never as a silently-accepted edge case.

Every key has its own ULID. A key’s role is exactly operator or authority — an operator key can never produce a valid VerificationAssertion, and an authority key can never produce a valid ManifestProof. That separation is enforced at verification time, not by convention.

Nothing is ever deleted: a key stays resolvable forever, so a signature made years ago can still be checked against the key that made it. The KeyDocument schema defines active, retired and revoked states and the resolver serves whichever is stored — but this deployment has no key-rotation or key-revocation flow yet, so every key published here is active. The same is true one level up: agent status transitions (CHANGED, STALE, SUSPENDED, REVOKED) are defined in the protocol and stored in the registry’s schema, and no write path sets them. There is no revocation flow today, and this page will say so until there is.

Verification is a distinct, signed act — a VerificationAssertion, made by an authority key, bound to one specific manifest digest and evidence type. It is never inferred from an operator’s own declaration.

Two different questions, kept apart deliberately: defined in v1.1.1 is a fact about the specification, and issued by AgenID today is a fact about this deployment. They are not the same answer for any level above L1.

• L1_REGISTERED — schema_validation. Defined in v1.1.1 · Issued by AgenID today.
• L2_DOMAIN_VERIFIED — dns_txt_challenge / http_wellknown_challenge. Defined in v1.1.1 · Not issued by AgenID today. The evidence can be collected now at /verify/domain; what cannot happen yet is signing the assertion.
• L3_ORGANIZATION_VERIFIED — business_registry_match / document_review. Defined in v1.1.1 · Not issued by AgenID today. Deferred behind a written evidence standard as well as the root key.
• L4_DEPLOYMENT_VERIFIED — deployment_conformance via deployment_sample_review. Defined in v1.1.1 · Not issued by AgenID today. The sampling methodology is also still open — see below.
• L5_CONTINUOUSLY_MONITORED — a reserved name only. No continuous-integrity claim exists in v1.1.1. Not defined · Not issued.

The ceiling on this deployment is L1_REGISTERED. Every level above it is a VerificationAssertion signed by the root authority key, and that key has not been generated — see below. An operator can complete every step that exists today and will still hold an L1 identity. Nothing on this site is an offer of L2, L3 or L4.

A VERIFIED claim is scoped to exactly what its evidence type checked. It is never a general safety, behavioral, or legal guarantee — verification is not compliance.

Not yet complete. The production root authority key has not completed its HSM ceremony. The verification mechanism for trust anchors — two-path key discovery, key roles, revocation — is fully specified and testable today (spec §9.5). What has not happened yet is the operational step of generating and ceremonially sealing the actual production root key. This is disclosed here rather than implied to be finished, and this page will be updated the day it is.

The L4 deployment_sample_review methodology and the CI sync step between the spec repository and this site’s mirrored schemas/docs are also open items, tracked internally and not yet resolved.

The protocol specification is public and MIT-licensed: AgenID-protocol/spec. The independent conformance suite is also public and MIT-licensed: AgenID-protocol/conformance — it never imports @agenid/core or calls AgenID’s own registry, and currently passes 34 of 34 checks in CI on every push.

A registered manifest’s declared fields (identity, operator, purpose, disclosure) are public by design — that is what makes independent verification possible. Registration lists an agent nowhere: by default an agent is found only by its identifier. The agent directory lists only agents whose operators opted in by signing a listing consent with the agent’s own operator key, and an operator can withdraw it the same way. A listing is not an endorsement and changes no verification level. There is no search or enumeration of unlisted agents on this deployment. This changed on 2026-09-23 and is disclosed here rather than silently.