Building AI agents right now is a lot like adopting a very fast, very confident puppy that also happens to have your API keys. It wanders. It chews on things it shouldn't. And the second you look away, it's leaked embarrassing data all over the floor.
So most of us spend our days wrestling agents into submission: chasing what drifts, mopping up what leaks, hoping the next one behaves. Here's a more fun way to live: build your agents with rules up front that you actually know will be enforced. And you can prove they were.
In some settings, that's a quirk you can mop up. In the enterprise, and anywhere regulated or sovereign, it's a breach. And the risk is mutating: the next leak may not be a careless agent at all, but a rogue one under a borrowed identity, indistinguishable from legitimate traffic. The risk is also increasing as new models grow increasingly capable of infiltration.
This leaves the builder with questions no current tooling can answer: Is this agent governed as it was built? Would I detect drift, or an identity operating in its place? Can I prove either to a party with no reason to trust me?
agentrust-io is the open trust layer built to answer them: replacing "we have guardrails that will probably catch issues and observability that will probably flag it after the fact" with evidence the builder can verify directly, and any auditor, customer, or regulator can independently confirm, without trusting the operator.
This is not another agent framework. agentrust-io doesn't replace the tools or standards teams already build with: it binds them into verifiable evidence. It comprises standards the ecosystem is already adopting: MCP and A2A for the agent and tool-call surface, AGT (Agent Governance Toolkit) for runtime policy, SPIFFE for workload identity, SLSA and AIBOM/SBOM for supply-chain and model provenance, Cedar for policy, and RATS/EAT for hardware attestation, aligned to NIST SP 800-207 and addresses all OWASP Agentic AI Top 10.
The specifications, SDKs, and conformance tests are free and open. Begin in software; advance to hardware-backed and post-quantum assurance as requirements demand.
The 2-minute version: technical one-pager.
OPAQUE is funding three to five fellows to work on these projects for six months, part-time at 20 hours per week, paid. The work is here in the open repos; OPAQUE is the employer and funder, and the fellowship exists to put more hands on the open specifications rather than on a product.
For security engineers, distributed systems researchers, AI governance and compliance professionals, and Ph.D. students. Fellows contribute code and specifications and complete a public technical artifact such as a paper or a conference talk. Mentored by Imran Siddique, Chief Platform Officer at OPAQUE and creator of AGT.
Selection is on a technical proposal, so start from the work rather than the pitch: open issues labelled
fellowshipacross trace-spec, cmcp, cA2A, and agent-manifest are real, currently-open items. Cohort starts September 2026.
| Project | Description | License | Status |
|---|---|---|---|
| agent-manifest | Agent Manifest SDK: cryptographically bind all 10 artifacts defining an agent at deployment. Python. | Apache 2.0 | Public, v0.7.0 |
| cmcp | cMCP: Confidential MCP Runtime. Hardware-attested policy enforcement for MCP tool calls inside a TEE. | MIT | Public, v0.3.0 |
| ca2a | cA2A: Confidential Agent-to-Agent. Attested, attenuated delegation profile on top of A2A, with a sealed peer channel and offline-verifiable provenance. | MIT | Public, alpha (v0.1.0a1) |
| trace-spec | TRACE: Trust Runtime Attestation and Compliance Evidence. Open attestation standard: an EAT (RFC 9711) profile carried in a JWT or CWT/COSE envelope, plus the agentrust-trace reference SDK. |
Dual: CC BY 4.0 (spec text), Apache 2.0 (code) | Public, spec v0.2, SDK v0.5.1 |
| trace-tests | TRACE conformance test suite for certification. | Apache 2.0 | Public, v0.4.0 |
| examples | End-to-end integration examples: financial services, healthcare, multi-tenant SaaS, industrial embodied AI, and agent-to-agent delegation. | MIT | Public |
| integrations | Ecosystem adapters: third-party governance runtimes to TRACE claims, plus coding-agent plugins. | Apache 2.0 | Public |
| demos | Runnable demos and the web console used for walkthroughs. | MIT | Public |
| awesome-ai-governance | Community-curated list of tools, frameworks, standards, and resources for governing autonomous AI agents. | CC0 1.0 | Public, launched CC Summit Jun 23 |
| trace-registry | Merkle registry of TRACE claim anchors, with a normative anchor and inclusion-proof format. | CC BY 4.0 | Private. Publishing the anchor format is tracked in trace-spec#111 |
These projects are developed in the open. We intend to propose them to recognized open standards bodies; we're inviting the ecosystem to shape them:
- TRACE: we intend to submit it as an open standard. The standards home is under evaluation (the Agentic AI Foundation under the Linux Foundation, or CoSAI under OASIS Open); we're inviting founding co-editors now.
- Agent Manifest: we intend to submit it through CoSAI under OASIS Open, building on CoSAI Workstream 4.
- AGT (Agent Governance Toolkit): the runtime governance engine this stack builds on, created by Imran Siddique (Chief Platform Officer, OPAQUE) while at Microsoft and released under the MIT license: microsoft/agent-governance-toolkit.
agentrust-io is built as an open coalition, not a single-vendor stack; we're inviting the ecosystem to shape it before v1.0.
Founding partners & co-editors. Take a named seat on the specifications, contribute a hardware-root or platform annex, and help set conformance and governance. The charter is built for co-ownership.
- Confirmed founding partner: Technology Innovation Institute (TII).
- Invited: Anthropic, OpenAI, Google, Microsoft, NVIDIA, Intel, AMD, Block, and ServiceNow; and the standards homes we're proposing into (AAIF / Linux Foundation, CoSAI / OASIS Open). Co-editor slots are open.
Fellows. OPAQUE funds three to five paid, part-time fellowships on these projects, applications 1 to 29 August 2026. See the callout at the top of this page.
Contributors & implementers. You don't need a seat to build with us:
- If you build an agent framework or governance tooling (LangChain, CrewAI, LlamaIndex, Haystack, PydanticAI, Dify, Cisco AI Defense, or anything else in the ecosystem), bring an adapter.
- Bring your platform's attestation root (TEE, GPU, TPM, or managed runtime) as a provider.
- Pilot cMCP at your MCP tool-call boundary; run the conformance suite and tell us where it bends.
Sovereign & regulated deployments. The stack is built so agents can run on regulated, proprietary, and sovereign data: hardware-rooted, post-quantum-ready, verifiable without trusting any single operator or jurisdiction. If you're advancing sovereign AI governance, we want you at the table.
To get involved, open a GitHub Discussion or contact the maintainers.
agentrust-io is our proposed reference architecture for zero-trust agentic AI. The Anthropic Zero-Trust for AI Agents eBook (May 2026) adapts NIST SP 800-207 to agentic systems. We map our stack to six verification areas drawn from it — agent identity and authentication, supply chain security, MCP and tool security, policy enforcement and governance, multi-agent coordination, and detection and response — and name the gaps honestly.
The eBook's core point on identity: agent identity must be cryptographically rooted, because a label is trivial to forge — perimeter authentication alone cannot secure an autonomous agent. The sharper framing, and the gap this org was built to close: a signed JWT proves who called an API, not what agent made the call, which system prompt was active, which model version ran, or under which policy it was operating.
The PDF frames agent identity as an authentication problem. The sharper framing: it is an attestation gap. Authentication proves who called. Attestation proves what ran and under what configuration.
Agent Manifest binds ten artifacts into a single cryptographically signed, hardware-attestable document:
| # | Artifact | Attack if unattested |
|---|---|---|
| 1 | System prompt | Prompt injection redefines agent goals |
| 2 | Policy bundle | Policy swap grants unapproved permissions |
| 3 | Tool manifest | Schema extension silently expands capabilities |
| 4 | Model identity | Unapproved version may lack safety alignment |
| 5 | RAG corpus | Corpus poisoning changes outputs silently |
| 6 | Memory baseline | Memory drift corrupts long-running agents |
| 7 | Decision trace | No accountability for high-stakes decisions |
| 8 | A2A delegation chain | Orchestrator spoofing, scope laundering |
| 9 | Supply chain provenance | Compromised dependency runs as approved binary |
| 10 | HITL approvals | EU AI Act Art. 14 violation |
The signing key is hardware-sealed in a TEE. Hardware provider auto-selects: Azure CVM -> SEV-SNP -> TDX -> TPM -> software. OPAQUEProvider is explicit opt-in via OPAQUE_ATTESTATION_URL and is never auto-detected. GPUCCProvider (NVIDIA H100/H200/Blackwell, CC mode) is not shipped; it is blocked on H100 quota rather than on design.
Azure is checked before the bare-metal SNP probe and is its own provider for a reason worth stating plainly: Azure runs SEV-SNP behind a Hyper-V paravisor, so the report is read through the vTPM and the root of trust is a vTPM AK chained to the SNP report, not a guest-controlled REPORT_DATA. A consumer keying on the platform value can tell the two apart. Azure TDX cannot be attested offline at all: the guest receives a vTPM-MAC'd TDREPORT rather than a signed DCAP quote, so rooting it needs a networked service (Azure MAA). Offline TDX works on non-paravisor guests such as GCP C3.
What is verified against real silicon, as opposed to parsed: SEV-SNP report signatures verify to the AMD root (VCEK then ASK then ARK), hardware-validated on GCP N2D and live Azure SEV-SNP. Intel TDX verifies a full DCAP v4 quote to the pinned Intel SGX Root CA, offline and hardware-validated on GCP C3. TPM 2.0 quotes verify an AK chain to a pinned root, validated against a real Azure vTPM quote. Nothing in that list is a format check standing in for a signature check.
A verifier holding the manifest and attestation report can prove, without trusting the operator, that a specific agent ran specific code under specific policy. Agent identity and user identity are cryptographically separate credentials: SPIFFE SVIDs for workload identity, Ed25519 (or post-quantum ML-DSA-65 at Level 3) for the manifest signature.
Four conformance levels address the full deployment range:
| Level | Name | Requirements | Use case |
|---|---|---|---|
| 0 | Software-only | All artifact bindings, Ed25519, transparency log | Development, staging |
| 1 | TEE-attested | + TEE attestation, audit_key_sealed: true |
Enterprise production, EU AI Act Art. 15 |
| 2 | Full stack | + All 10 artifacts, HITL approvals, Phase 2 cMCP, 180-day log retention | Regulated industries, DORA Art. 9 |
| 3 | Post-quantum | + ML-DSA-65 (NIST FIPS 204), ML-KEM-768, SHAKE-256 | Sovereign, classified, long-horizon financial |
Agent Manifest artifact #9 binds container digest, SLSA provenance level, and SBOMs into the signed manifest. A supply chain attack that swaps the container invalidates the TEE measurement, which invalidates the manifest signature. Hardware attestation makes this structurally detectable, not just policy-prohibited.
TRACE includes build_provenance as a first-class field (SLSA Provenance v1.0). The model is identified by model.weights_digest, and an AIBOM is referenced by digest through model.aibom_uri (SPDX 3.0 AI Profile / CycloneDX 1.7 ML-BOM) rather than embedded. Both are inside the signed payload, so the model component inventory cannot be swapped after signing.
Every agentrust-io repository carries OpenSSF Scorecard badges, CodeQL SAST, Dependabot, pip-audit on every PR, and bandit security linting. The tooling in this org practices what it recommends.
The Anthropic eBook cites specific MCP attacks: the Invariant Labs GitHub compromise via MCP integration, the Zenity AgentFlayer 0-click attack, the Postmark MCP npm backdoor. These are not hypothetical threats.
cMCP (Confidential MCP Runtime) is a direct response. Every MCP tool call is intercepted, evaluated against a Cedar policy bundle, and enforced by a policy engine running inside a TEE. The policy bundle hash is measured into the hardware attestation report before any code runs.
| Threat | Software governance | cMCP |
|---|---|---|
| Admin replaces Cedar policy on disk | Undetected: hash chain runs in compromised OS | Policy hash measured by hardware before code runs |
| Supply chain CVE flips allow/deny signal | Undetected: evaluator in attacker's address space | Evaluator in isolated enclave memory |
| Admin regenerates audit log post-breach | Undetected: any party with signing key can reconstruct | Signing key hardware-sealed, new valid signatures structurally impossible |
Every cMCP tool call produces a GatewayClaim (a TRACE Profile) containing the runtime platform measurement, policy bundle hash, and hardware-sealed confirmation key. Tool call authorization is independently auditable and tamper-evident.
The eBook calls for policy at four layers (model, agent, tool, request) with fleet management, centralized policy management, audit logging, and compliance monitoring.
cMCP handles tool-level and request-level policy with Cedar inside a TEE. Cedar is designed for per-request evaluation; this is not a batch audit but runtime enforcement on every call.
TRACE defines the governance record format: what a compliance artifact should contain, how it is cryptographically bound, and how it anchors in a transparency log. TRACE composes existing standards rather than replacing them:
TRACE v0.2 is current, and moving to it is not optional if you pinned the v0.1 profile URI. The EAT profile is now tag:agentrust-io.com,2026:trace-v0.2. The v0.1 identifier named a domain this project never controlled, which RFC 4151 does not permit for a tag URI, so it was invalid rather than merely renamed. Verifiers cut over rather than accepting both, because a verifier honouring the old identifier would keep certifying records minted under a name we do not own. Records already issued under v0.1 stay verifiable against the v0.1 spec and the agentrust-trace 0.4.x and agentrust-trace-tests 0.3.x releases, which remain published. v0.2 also makes transparency optional below Level 2, since an unanchored Level 0 or Level 1 record has no receipt to name.
| Primitive | Role in TRACE |
|---|---|
| RATS / EAT (RFC 9711) | Wire envelope and claim model |
| SLSA Provenance v1.0 | Build-time provenance |
| SPIFFE SVID | Workload identity |
| SCITT | Append-only transparency anchoring |
| EAR (draft-ietf-rats-ar4si) | Verifier appraisal output |
| MCP / A2A | Agent tool-call transcript surface |
| AIBOM (SPDX 3.0 AI Profile / CycloneDX 1.7 ML-BOM) | Model component inventory, referenced by digest from model.aibom_uri |
TRACE Registry is an append-only Merkle registry of TRACE claim anchors, built on RFC 6962 (Certificate Transparency) trees so a third party can verify inclusion without trusting the registry operator. Git's immutable commit history is the tamper-evident proof.
The repository is currently private, and that is a gap rather than a design choice. Independent verification needs the anchor and inclusion-proof format, which is specified normatively but not yet published. Publishing it is tracked in trace-spec#111. Until then, treat independent anchor verification as documented-but-not-yet-exercisable by outside parties.
AGT (Agent Governance Toolkit) (microsoft/agent-governance-toolkit, created by Imran Siddique (Chief Platform Officer, OPAQUE) while at Microsoft and released under the MIT license — 5,100+ stars, 10/10 OWASP Agentic Top 10) provides the runtime governance layer: trust score decay (a score at deployment is meaningless six months later), scope-chain delegation (monotonic narrowing: agent-to-agent delegation with verifiable credentials), and a fleet daemon for multi-agent orchestration.
The prize is obvious: connect agents directly to your most sensitive data and systems: the regulated records, the proprietary models, the production controls, because that is where the value of AI actually lives. It is also exactly what you cannot risk today.
If you have built and run agents, you already know two things to be true: they drift, and they leak. Anyone who says otherwise hasn't shipped one. Take the best case: a good agent leaks only 1% of the time and watch what a fleet does to it. The odds that at least one of n agents leaks is one minus the odds they all stay clean: 1 - (1 - 0.01)^n:
| Agents | Chance at least one leaks |
|---|---|
| 1 | 1% |
| 100 | 63% |
| 1,000 | 99.99% - effectively certain |
Multi-agent architecture compounds it: an orchestrator delegates to sub-agents, scope widens down the chain, and no one can prove which agent did what.
This is the layer the Anthropic Zero-Trust for AI Agents framework calls for: authentication of agent-to-agent communication, RBAC for agent hierarchies, consensus for high-stakes decisions; and where the stack enforces it:
- Agent Manifest artifact #8 (A2A delegation) binds the full agent-to-agent trust chain into the signed manifest. A delegated scope can never exceed the orchestrator's own attested permissions; orchestrator spoofing and scope laundering are structurally prevented. AGT supplies the mechanism: scope-chain delegation (monotonic narrowing) with verifiable credentials.
- cA2A (Confidential A2A) is the profile that carries this at the agent-to-agent boundary: each hop presents a signed delegation credential whose scope is a provable subset of its parent, verified offline. Peer attestation and sealing to a peer's measurement are no longer roadmap: the handshake has run off a live SEV-SNP quote returning
assurance="hardware", with the payload sealed to a channel key a hardware-verified measurement vouches for, followed by a cross-operator run from an Azure SEV-SNP peer to a GCP Intel TDX peer. Two limits remain and cA2A's own docs state them: that appraisal was one-directional (the caller appraised the callee, not the reverse, so mutual simultaneous attestation is outstanding), and the reference server and client still default to software mode, so the hardware path is a validated capability rather than the default configuration. - TRACE records each agent's actions as a hashed, counted
tool_transcript, so the full interaction graph of a multi-agent run can be reconstructed and proven after the fact.
The goal is that every agent carries attested proof of what it is and emits verifiable evidence of what it did, so a multi-agent run can be reconstructed by someone who trusts none of its operators.
Current coverage: TRACE provides the immutable audit chain from which anomalies could be detected. AGT's GovernanceEventSink SPI is a pluggable event sink, so anomaly detection can be wired in without vendor coupling. Trust score decay in AGT is a passive form of behavioral posture management.
Gaps: There is no dedicated behavioral anomaly detection or agent quarantine tooling in the current repos. Automated response (quarantine procedures, rollback) is on the AGT roadmap but not shipped. The eBook's recommendation for sleeper agent detection through behavioral analysis has no direct counterpart here yet. TRACE provides the audit foundation; detection is not included.
| Standard | Agent Manifest | TRACE | cMCP | AGT |
|---|---|---|---|---|
| NIST SP 800-207 (Zero Trust) | Identity, policy layers | Governance records | Tool-level ZT enforcement | Fleet policy, observability |
| OWASP Agentic AI Top 10 (2026) | Addresses all 10 ASI categories with deterministic, attestable controls | Evidence chain | MCP call enforcement | Runtime governance |
| NIST AI RMF 1.0 | GOVERN, MAP, MEASURE, MANAGE | MEASURE, MANAGE | GOVERN (tool policy) | Full RMF lifecycle |
| EU AI Act Art. 13-15 | Transparency (Art. 13), HITL (Art. 14), supports Art. 15 (cybersecurity) at Level 1 | Compliance evidence | Enforcement evidence | Governance lifecycle |
| DORA Art. 9 | Attestation + 180-day log retention (Level 2) | Immutable audit chain | Per-call audit records | Risk management |
| MITRE ATL | Supply chain, model identity, prompt constraints | Verifiable evidence | Policy enforcement | Detection foundation |
| SLSA | Level 2 build provenance | build_provenance field |
SLSA-aware claims | Supply chain |
| CoSAI WS1 | Secure-by-Design Principles, MCP Security Taxonomy | MCP enforcement | WS4 governance |
- Questions and discussion: GitHub Discussions
- Security issues: see SECURITY.md
- Contributing: see CONTRIBUTING.md