Glossary · Verification

Declared, verified and authorized: three claims that never blend

Updated 2026-09-23

Most confusion about agent trust comes from blending these. A mark that means signed gets read as checked, and something checked gets read as permitted. AgenID keeps them apart structurally, by object, rather than with a field someone could flip.

The rule is short: declared does not imply verified, and verified does not imply authorized.

Definition

Declared, verified and authorized are AgenID's three claim states: what an operator says about its agent, what an authority has checked against evidence, and what the agent may do. None is ever inferred from another.

Also known as: claim states

How it works in AgenID

Role is enforced: an operator key cannot produce VERIFIED and an authority key cannot produce DECLARED, even when the signature math validates.

DECLARED is produced only by an operator, through the agent manifest and its ManifestProof.
VERIFIED is produced only by an authority, through a verification assertion whose digest matches the current manifest.
AUTHORIZED has no signed object in v1.1.1; the permissions and authorizations manifest keys are reserved.

What exists today

The reference registry records DECLARED statements at L1_REGISTERED. VERIFIED needs an assertion signed by a root authority key, which has not been created yet, so nothing is VERIFIED today. A v1.2 authorization layer, with signed grants and revocations, is a draft in development and is not available.

Operators can record evidence of domain control at /verify/domain today. That is useful context for a relying party, but it is evidence, not an assertion, and it does not change the claim state.

Why it matters

Which agent is acting is not the same question as what it is allowed to do. A business deciding whether an agent may book, pay or sign needs its own permission policy, and the agent delegation scenario shows where that decision sits. AgenID supplies the identity input, honestly labelled, so nobody mistakes a signature for a permission. A permission decision can use identity as an input; it should never be read off identity alone.

Frequently asked questions

Is a registered agent verified?

No. Registration records a self-declaration at L1. Nobody has checked it.

Can a verified agent act for me?

Verification would say a specific claim was checked. Whether the agent may act is your decision, and v1.1.1 has no object that expresses it.

Why not one trust score?

A single score hides what was checked. Three states tell a relying party exactly what it is relying on. Check any agent's state at /verify.

What agenid.com issues today

The reference deployment at agenid.com issues DECLARED and L1_REGISTERED only. L2_DOMAIN_VERIFIED and higher require a VerificationAssertion signed by a root authority key, and that key has not been created yet. L5 is reserved by the specification and is not issuable at all.

Identity is not permission

Which agent is acting and who declared it is one question. What that agent is allowed to do is another, and it stays with the party on the other side and with the operator. Protocol v1.1.1 defines no signed authorization object.

Sources

AgenID protocol specification (public repository)

how-it-works

Agent-to-agent delegation

Give your agent an identity

Register an agent in the browser — the signing key is generated on your device and never sent to AgenID — or resolve an existing AgenID and re-check its signature yourself.