Introducing Agent Manifest, an open specification for cryptographically binding the complete trust surface of an AI agent into a single hardware-attestable record.
A signed JWT proves who called an API. It proves nothing about the agent that made the call.
Which system prompt defined its behavior. Which model version ran. Which tools were authorized. Whether the policy bundle in memory matches what was reviewed. Whether a human approved the configuration before it shipped. A JWT answers the authentication question. It does not answer the attestation question. And in regulated environments, it is the attestation question that matters.
This is the gap Agent Manifest closes. It launched publicly on June 23 at the Confidential Computing Summit, and the spec, SDK, and conformance suite are available now.
The Problem: Agents Have No Identity Primitive
Every other entity in a modern enterprise system has a verifiable identity. Users carry X.509 certificates and OAuth tokens. Services carry SPIFFE SVIDs. APIs are called with signed JWTs. Containers have image digests. Infrastructure has hardware TPM measurements.
AI agents have none of these.
An agent calling Salesforce, your payment processor, or a healthcare database today presents no unforgeable proof of:
- Which system prompt defined its behavior
- Which model version is running
- Which policy bundle was approved by your security team
- Which tools were authorized and what they can access
- Whether its knowledge base was tampered with
- Whether a human reviewed and approved the configuration
That is not a theoretical problem. Between January and February 2026, researchers filed over 30 CVEs targeting MCP servers, clients, and tooling. Palo Alto Unit 42 found that with five connected MCP servers, a single compromised server hit a 78.3% attack success rate. The attack surface is real and it is growing.
The gap is not authentication. Agents can authenticate with certificates and tokens today. The gap is attestation: the inability to prove, to a third party who does not trust the operator, that the agent running right now is the agent that was approved, with the tools that were authorized, under the policy that was reviewed.
The Ten Unattested Surfaces
Every AI agent has ten surfaces that define its complete trust boundary. None of them have a standard attestation mechanism today.
Agent Manifest binds all ten into one signed, hardware-attestable record. A verifying party who holds the manifest and the accompanying attestation report can prove, without trusting the operator, that a specific agent instance ran specific code under specific policy with specific tools, produced specific decisions, and received specific human oversight.
How It Works
The Manifest Is Not the Artifacts
The manifest stores hashes and identifiers, not content. The system prompt hash is bound; the system prompt itself is not stored in the manifest. This keeps manifests small, portable, and privacy-preserving, while ensuring that any change to any artifact breaks the hash binding and is detectable.
Each artifact binding looks like this:
Every field that could be tampered with is bound. allow_dynamic_registration: false prevents MCP rug-pulls, the class of attack where a tool server signals a notifications/tools/list_changed event mid-session and silently expands the agent’s capabilities. rug_pull_policy: deny-and-hold defines what happens when one is detected anyway.
Attestation Levels
The spec defines three conformance levels:
Level 0: software only. Ed25519-signed manifest, no hardware attestation. Useful for development and low-stakes contexts. Any privileged operator can forge this; its trust model is operator trust.
Level 1: TPM-attested. The manifest hash is sealed into a TPM measurement. A TPM quote references the manifest. This roots the binding in hardware but relies on TPM firmware integrity, which a co-tenant cannot compromise.
Level 2: TEE-attested. The manifest hash is measured into the hardware attestation report before any user code runs (via AMD SEV-SNP, Intel TDX, or equivalent). The signing key never leaves the enclave. All ten artifacts bound. This is the level that produces evidence a regulator, auditor, or enterprise CISO cannot dismiss as operator self-attestation.
The Lifecycle
An Agent Manifest follows five phases:
- Authoring. Developer creates the unsigned draft, binding all artifacts by hash.
- Signing. Security reviewer approves and signs with an Ed25519 or ML-DSA-65 key.
- Attestation. At workload launch, the TEE measures the manifest hash into the hardware report.
- Verification. At every trust boundary (tool call, delegation hop, audit), a relying party verifies.
- Revocation. When any artifact changes, a revocation record is published to the transparency log.
manifest_id is a UUID v7 and is immutable per issuance. Any change to any signed field produces a new manifest with a new UUID. There is no in-place update mechanism. A previous_manifest_id field chains to the prior manifest for audit continuity.
Why “Tamper-Evidence Over Tamper-Resistance”
This is the key design choice worth understanding.
Agent Manifest does not prevent a rogue operator from swapping a system prompt in memory. What it does is make that swap detectable by a third party who holds the manifest and compares it against the hardware attestation report. The measurement happened in silicon, before any user code ran, and the signing key never left the TEE. The operator with root access on the host cannot retroactively produce a matching attestation report for a run that used a different system prompt.
The Anthropic Zero Trust for AI Agents framework phrases it well: does a control make the attack impossible, or just tedious? Software-signed manifests are tedious controls. Hardware-attested manifests are impossible controls.
Standards Alignment
Agent Manifest is designed to compose with, not replace, existing standards:
- SPIFFE/SPIRE: agent_id is a SPIFFE SVID URI, and identity is hardware-rooted in TEE deployments
- SLSA: supply chain provenance is bound in artifacts.supply_chain
- Cedar (AGT): policy bundle binding in artifacts.policy_bundle uses AGT’s Cedar bundle format
- MCP: tool manifest binding in artifacts.tool_manifest uses MCP’s tool descriptor schema, extended with hash bindings
- TRACE: decision trace uses TRACE Trust Records for hardware-signed per-invocation evidence
- EU AI Act Art. 14/15: hitl_record covers human oversight records required for high-risk AI systems
The specification is targeting the Agentic AI Foundation (AAIF) at the Linux Foundation. The v0.1 draft is published at manifest.agentrust-io.com with 197 conformance tests against the formal specification.
The Verification Protocol
The verifier checks the signature, the expires_at timestamp, the manifest_id against the revocation log, and, if a TEE attestation report is provided, the hardware measurements against the manifest hash. No callback to the issuer. No vendor in the trust path beyond the silicon root.
The Problem This Solves for Regulated Deployments
Consider a bank deploying an AI agent that calls a payment authorization API. The bank’s CISO needs to show a regulator:
- The agent that called the API is the agent that was reviewed and approved by the security team
- The policy bundle in force at the time of the call is the policy bundle that was approved
- The model version running is the model version that was safety-evaluated
- No tool capabilities were added between approval and execution
- A human sign-off exists for high-value transactions above a threshold
Without Agent Manifest, every one of these is answered by operator documentation: logs the operator controls, signed by keys the operator holds. With Agent Manifest at Level 2, every one is answered by hardware evidence rooted in silicon the operator does not control.
Get Started
That is the gap this fills.
Documentation: manifest.agentrust-io.com Specification: github.com/agentrust-io/agent-manifest Discord: discord.gg/grgzFEHgkj
The project launched publicly on June 23 at the Confidential Computing Summit. The spec, SDK, and 197-test conformance suite are available now. Open an issue or join the Discord to get involved.
Originally published at https://www.linkedin.com.
Top comments (0)