Glossary · Identity

The agent manifest: an operator's declaration about its AI agent

Updated 2026-09-23

The manifest is what a relying party reads when it asks who an agent is. It is plain JSON with a strict schema: a version, the agent_id, and four groups of fields.

Everything in it is DECLARED. It is what the operator says about its own agent, bound by signature so it cannot change without detection, but not checked by anyone else.

Definition

An agent manifest is the operator's canonical-JSON self-declaration about an AI agent: its identity, its accountable operator, its purpose and how it discloses itself. In AgenID the manifest is never signed directly; a ManifestProof binds it by SHA-256 digest.

Also known as: manifest

How it works in AgenID

The schema rejects unknown members. The manifest digest is SHA-256 over its RFC 8785 canonical bytes, and the ManifestProof signs that digest. The four groups are fixed:

identity: the agent's name and description.
ownership: operator, operator_domain and contact.
purpose: a summary and its channels (voice, sms, chat, email or api).
disclosure: is_ai, discloses_to_user and human_escalation.

Why it matters

The disclosure attestations describe real behavior that no API can discover, so AgenID requires the operator to set them explicitly; the flow at /issue starts them at false rather than pre-checking them. A defaulted attestation would be a fabricated claim under a real signature. Binding by digest also means any edit, even one flipped boolean, fails verification with manifest_digest_mismatch.

The purpose and channels fields tell a relying party what the agent says it is for, which is useful context when a call or message arrives on an unexpected channel. A scheduling agent that turns up on email is not proof of misuse, but it is a fair question to put to the operator.

What it does not mean

Operator attestations are self-declared and unverifiable by anyone, including AgenID. The keys permissions and authorizations are reserved and rejected in v1.1.1, so a manifest cannot state what the agent is allowed to do. It describes the agent; it grants nothing.

Frequently asked questions

What happens if the manifest changes?

It produces a different digest, so it needs a new ManifestProof. A verification assertion bound to the old digest no longer applies to the new version.

Is the manifest public?

Yes. It appears in the resolution envelope and on the Verification Card, so keep secrets and private data out of it. The onboarding guide covers each field.

Why not sign the manifest directly?

Binding by digest keeps the manifest freely cacheable and lets several signed objects reference one version without re-signing it.

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)

Operator onboarding guide

how-it-works

Dentist appointment

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.