02 · Agent: what is this agent, and what is it allowed to do?

Check the agent you approved against what deployed¶

An AI agent is software that uses an AI model to take actions on its own. Agent Manifest is a signed record of how one agent was set up: its instructions (the prompt), its rules (the policy), its tools, its model and six other parts. Anyone checking the agent later can confirm who signed the record and compare each part with what is actually running. New to these terms? See the terms, in plain English.

Create and check your first manifest What this proves, and what it does not

The agent attestation gap¶

Knowing who is calling does not tell you what they are running. A logged-in agent can still be running a changed prompt, different rules or a new tool. A manifest lists a fingerprint (a hash) of each approved part, so a checker can compare them one by one.

A software signature proves who made those statements. Proving the agent runs on particular hardware takes more: a valid signed report from the processor (called attestation), measurements you have approved, and a link between that report and this manifest.

How it works¶

Someone approves the agent's parts and signs a record of them. Later, a checker brings the signer's public key, its own view of what is running and, if wanted, a hardware report, and gets a result for each part. Scroll the diagram sideways on small screens.

flowchart TB
    config[Approved deployment artifacts] -->|hash and identify| issuer[Manifest issuer]
    issuer -->|sign| record[Signed manifest]
    record --> verifier[Verifier]
    keys[Trusted issuer keys] --> verifier
    actual[Independent runtime inputs] --> verifier
    evidence[Optional appraised hardware evidence] --> verifier
    verifier --> result[Result and per-field checks]

The checker needs its own trusted inputs; it cannot take the agent's word for what is running. A signed manifest describes the agent at one moment and does not keep watching it, and a hardware report does not rule out every later change. What the agent does while it runs is recorded separately in TRACE.

The 10 attested artifacts¶

A manifest can describe up to ten parts of an agent. Which ones must be present, and how strictly each is checked, depends on the level (profile) you choose. A part appearing in this table does not mean it was measured or checked in your deployment.

Hardware providers¶

A provider is the code that collects a signed report from one kind of chip. Supported providers are TPM, AMD SEV-SNP, Intel TDX and OPAQUE. They differ in how the report is collected and checked, and in how well the agent's memory is shielded from the rest of the machine. Use the hardware guide and limitations to choose; the provider name alone does not tell you how far to trust a machine.

Conformance levels¶

Conformance levels are tiers of strictness. Start with software signing. Higher levels add requirements for hardware reports, human approvals, public logs or stronger cryptography. Check the specification before claiming a level; a good signature is only one part of passing.

Frequently asked questions¶

What is an Agent Manifest?¶

A signed record of the parts an agent was approved to run with. It is useful when you confirm who signed it, compare it with what is really running, and check whatever extra evidence your own rules require.

How is an Agent Manifest different from a signed JWT?¶

A JWT (JSON Web Token) is a common format for wrapping signed statements. Agent Manifest defines which parts of an agent to record and how to check each one. The wrapper format alone proves nothing about what is running.

Why not specify it as a JWT or JOSE profile?¶

Because of what similar standards chose; JWT could do the job. The IETF already picked the JWT/CWT route for attestation tokens: EAT (RFC 9711) even supports nested tokens and detached claim sets. That is the right shape for "who is calling, right now," and an EAT is a valid input to a manifest's attestation block.

Every multi-artifact provenance standard with a transparency log went the other way. SCITT (RFC 9943), the closest analog to Agent Manifest, mandates COSE_Sign1 signed statements. DSSE, the envelope behind in-toto and SLSA, rejected a JWS profile in writing, citing implementation hazards and canonicalization as attack surface. C2PA uses COSE_Sign1 inside a JUMBF container.

An Agent Manifest is that second kind of object: ten artifacts, several independent signers, hardware-report binding, a 90-day life, and a log receipt attached after signing. So the layering is EAT and JWT for the attestation-token input, and a signed document for the manifest. The two compose. See ADR-0011 for the full argument. The envelope moves to COSE_Sign1 in spec v0.2 to align with SCITT; v0.1 manifests keep verifying unchanged.

Does Agent Manifest require special hardware?¶

No. The first example uses only software signing. Proving where an agent runs takes extra hardware evidence and extra checks.

Is Agent Manifest free and open source?¶

Yes. The source and license are available on GitHub.

Next steps¶

• Getting started: sign a record, compare it, and catch changes.
• Tutorials: connecting it to your systems and running it day to day.
• Specification: the formal rules an implementation follows.
• Architecture decisions: design rationale.

Status: SDK 0.15.0 · Apache-2.0 · proposed to CoSAI WS4 (RFC #149) · Sponsored by OPAQUE, which funds the engineering, infrastructure and confidential-computing work behind these projects.