From bd8fedad3c2740c6be994b69a92b7c94ec60b677 Mon Sep 17 00:00:00 2001 From: Imran Siddique <45405841+imran-siddique@users.noreply.github.com> Date: Wed, 7 Oct 2026 13:40:38 -0700 Subject: [PATCH 1/3] docs(home): rewrite the homepage in plain language Add a plain-English terms section, relabel the verifier steps in ordinary words, explain each chain step in one line, and refresh stale versions (WCM SDK 0.30.0, Agent Manifest 0.15.0, cmcp-runtime 0.7.0, ca2a-runtime 0.4.0, agentrust-trace 0.11.0) and the OpenSSF badge count. Co-Authored-By: Claude Opus 5.5 --- index.html | 111 +++++++++++++++++++++++++++++++---------------------- 1 file changed, 65 insertions(+), 46 deletions(-) diff --git a/index.html b/index.html index c3cccb0..8dd38d3 100644 --- a/index.html +++ b/index.html @@ -179,26 +179,26 @@

Open specifications for verifiable AI

Prove what your AI ran, and what it did.

-

Open specifications and verifiers that bind model weights, agent identity and every tool call to hardware attestation. Anyone can check the evidence offline, without asking us.

+

When an AI system acts, most of what you can see afterwards is its own logs, and the system can edit those. AgenTrust is a set of free, open specifications and tools that produce a signed receipt instead: which model ran, which agent acted, and each step it took. On supported hardware the processor itself vouches for where the work ran. Anyone can check a receipt on their own computer, without asking us.

- Verify a real Intel TDX quote → - What this proves, and what it does not + Check a real hardware receipt → + The terms, in plain English
-
+
/verify › keybind_quote.binoffline · in this browser
    -
  1. quoteIntel TDX v4, GCP C3, captured 2026-09-14
    2. -
  2. step 1attestation key signature over header and TD reportnot run
    3. -
  3. step 2QE report binds the attestation keynot run
    4. -
  4. step 3QE report signed by the platform PCK certificatenot run
    5. -
  5. step 4PCK chain ends at the pinned Intel SGX Root CAnot run
    6. -
  6. REPORTDATAcommits to the key that signed a published TRACE recordnot run
    7. -
  7. verdictgenuine Intel TDX silicon signed this quotenot run
    8. +
  8. reportSigned report from an Intel TDX processor on Google Cloud, captured 2026-09-14
    9. +
  9. step 1The processor's attestation key signed the reportnot run
    10. +
  10. step 2Intel's quoting enclave vouches for that keynot run
    11. +
  11. step 3That vouching is signed by the chip's own Intel certificate (PCK)not run
    12. +
  12. step 4The certificate chain ends at Intel's root certificatenot run
    13. +
  13. linkThe report names the key that signed a published TRACE receiptnot run
    14. +
  14. verdictA genuine Intel processor produced this reportnot run
-

NoteGenuine Intel TDX silicon signed this quote, and its REPORTDATA commits to the key that signed the TRACE record published beside it. It does not show that the software inside the trust domain was the image anyone intended.

+

NoteThis box checks a real processor report while you watch. A genuine Intel TDX processor signed it, and the report names the key that signed the TRACE receipt published beside it. It does not show which software was running inside.

Runs in your browser. Nothing is sent back to us.

@@ -218,11 +218,11 @@

Agents can edit the record of what they did.

The tooling around agents is the attack surface.

-

In June 2026 a remote UI package for a popular coding-agent CLI, at about 29,000 weekly npm downloads, shipped code that exfiltrated users' non-expiring OAuth refresh tokens.

+

In June 2026 an add-on for a popular coding agent, downloaded about 29,000 times a week, shipped code that quietly copied users' long-lived login tokens to an attacker.

-

Weights are leaving the building.

-

Sovereign and on-premises deployment puts a model builder's weights on hardware somebody else owns. Weight-security research recommends confidential computing for the highest protection levels, and current silicon still falls to an operator with physical access.

+

Models are leaving the building.

+

A model's weights are the trained file that is the model. Running a model in a customer's or a government's own data centre puts that file on hardware somebody else owns. Weight-security research recommends confidential computing for the highest protection levels, and today's chips can still be broken by someone with physical access to the machine.

Read the weight-security research ↗
@@ -240,29 +240,48 @@

Four questions, each with evidence a stranger can chec
01 · WEIGHTS Is this the model that was released, and who may release its key? -

Weight Custody Manifest

- Spec pre-1.0, SDK 0.28.1, 91 portable conformance vectors +

Weight Custody Manifest: a signed record of exactly which model file this is, and the rules for who may release the key that decrypts it.

+ Spec pre-1.0, SDK 0.30.0, 91 portable conformance vectors
02 · AGENT What is this agent, and what is it allowed to do? -

Agent Manifest

- SDK 0.12.0, proposed to CoSAI WS4 (RFC #149) +

Agent Manifest: a signed ID card for an agent, listing what it is and what it may touch.

+ SDK 0.15.0, proposed to CoSAI WS4 (RFC #149)
03 · ACTIONS - Was each tool call and each delegation checked inside attested hardware? -

cMCP and cA2A

- cmcp-runtime 0.5.0; cA2A 0.2.0 developer preview + Was each action the agent took, and each job it handed to another agent, checked against the rules? +

cMCP checks every tool an agent uses, such as sending an email or querying a database. cA2A does the same when one agent hands work to another.

+ cmcp-runtime 0.7.0; ca2a-runtime 0.4.0 developer preview
04 · EVIDENCE - Can a third party verify all of it offline, years later? -

TRACE, TRACE Registry, conformance suite

- TRACE spec v0.2, a Series of LF Projects with an AAIF Sandbox proposal open, agentrust-trace 0.10.0, signed registry checkpoints with an external witness receipt + Can someone else check all of it, offline, years later? +

TRACE is the receipt format. The TRACE Registry is a public log of receipts with signed checkpoints, and the conformance suite tests that a tool reads them correctly.

+ TRACE spec v0.2, a Series of LF Projects with an AAIF Sandbox proposal open, agentrust-trace 0.11.0, signed registry checkpoints with an external witness receipt
-

Each step links to its project site. No step requires the others; use the ones your trust boundary needs.

+

Each step links to its own project site. No step needs the others, so start with the one that answers your question.

+ + +
+ + +
+
+
In plain English
+

The words on this site, in one line each.

+
+
+
AI agent
An AI system that takes actions on its own, such as reading files or sending messages, instead of only answering questions.
+
Tool call
One action an agent takes through another piece of software. MCP (Model Context Protocol) is a common way agents connect to those tools.
+
Delegation
One agent handing part of a job to another agent. A2A (Agent2Agent) is a common protocol for it.
+
Confidential computing
Chips that keep a program's memory encrypted while it runs, so even the server's owner cannot read it. Intel TDX, AMD SEV-SNP and NVIDIA H100 are three kinds. The protected area is called a trusted execution environment (TEE).
+
Attestation
A report signed by the chip itself about what it is and what is loaded on it. The signature traces back to the chip maker, not the cloud provider.
+
Signed receipt
A record with a digital signature attached. If anyone changes a single character, the signature check fails. TRACE is the receipt format used here.
+
Verify offline
Check a receipt on your own computer, with no call to us or to any service that could change the answer.
+
@@ -271,26 +290,26 @@

Four questions, each with evidence a stranger can chec
Where it runs
-

Validated on real silicon, verified to the vendor's root.

+

Tested on real confidential-computing chips, checked back to the chip maker.

AMD SEV-SNP

-

Azure confidential VM. Report signatures verify to the AMD root.

+

On a Microsoft Azure confidential virtual machine. The processor's reports check out against AMD's root certificate.

agent-manifest #227, merged 2026-07-21 ↗

NVIDIA H100 confidential computing

-

Through the Weight Custody Manifest path.

+

The GPU that runs the model. The Weight Custody Manifest checks its signed reports, cross-checked against NVIDIA's own verifier.

weight-custody-manifest #54, merged 2026-07-28 ↗
-

We verify signature chains. We do not appraise whether a platform's TCB is current.

+

We check that each signature traces back to the chip maker. We do not judge whether a chip's firmware has its latest security updates.

@@ -302,12 +321,12 @@

NVIDIA H100 confidential computing

What this proves, and what it does not.

@@ -317,22 +336,22 @@

What this proves, and what it does not.

Who it is for
-

Start where your trust boundary is.

+

Start with the part you are responsible for.

Model builders

-

Deploying weights into customer or sovereign infrastructure.

+

Who run their model on a customer's or a government's own hardware and need to stay in control of it.

Start with the Weight Custody Manifest →

Teams running agents in production

-

Who need identity, tool-call policy and delegation they can show to someone else.

+

Who need to show someone else what each agent is, what it was allowed to do, and what it did.

Start with Agent Manifest and cMCP →
@@ -347,7 +366,7 @@

Security, audit and risk teams

Anyone can read it, run it and check it.

-

TRACE is its own Series of LF Projects, announced by the Linux Foundation on 25 August 2026 and developed with AMD, Intel, Microsoft, OPAQUE and TII. It has also been proposed to the Agentic AI Foundation at the Sandbox stage (aaif/project-proposals #42, opened 14 September 2026).

+

TRACE, the receipt format, is hosted at the Linux Foundation as its own project (a Series of LF Projects), announced on 25 August 2026 and developed with AMD, Intel, Microsoft, OPAQUE and TII. It has also been proposed to the Agentic AI Foundation as an early-stage Sandbox project (aaif/project-proposals #42, opened 14 September 2026).

The Linux Foundation AMD @@ -368,8 +387,8 @@

Anyone can read it, run it and check it.

Every project is open source. Licences vary by project and are listed on each site.
-
8 of 9 repositories hold an OpenSSF Best Practices passing badge.
-
Software policy enforcement builds on the Microsoft Agent Governance Toolkit.
+
10 project repositories hold an OpenSSF Best Practices passing badge, an independent checklist for how open source projects are run.
+
The software rule-checking builds on the Microsoft Agent Governance Toolkit.
@@ -383,7 +402,7 @@

Anyone can read it, run it and check it.

Build with it

- Get started, software mode + Get started (no special hardware needed) Demos Research papers Telemetry From 2f4885cf3dcf57626f9bb4424ad82125fb1940e2 Mon Sep 17 00:00:00 2001 From: Imran Siddique <45405841+imran-siddique@users.noreply.github.com> Date: Wed, 7 Oct 2026 13:50:13 -0700 Subject: [PATCH 2/3] docs(site): plain-language pass on every hub page Every page now opens with what it is and who it is for, explains terms at first use, and keeps engineer-level detail in collapsible 'Technical detail' sections. Research papers gain a plain summary above the unchanged published abstract; the 30 controls gain a plain sentence above their cited requirement text. Frozen research versions, normative extension text, commands and outputs are unchanged. Facts refreshed: registry 3 entries and 2 checkpoints at trace-registry ba566ed, trace-verify 0.4.3, telemetry contract 0.1.0-alpha.6, ca2a-runtime 0.4.0. CSS v23 adds details.tech-detail. Co-Authored-By: Claude Opus 5.5 --- 404.html | 14 +- community/index.html | 68 ++++----- data/adoption.json | 20 +-- data/agentic-controls.json | 30 ++++ data/research.json | 16 ++ demos/index.html | 46 +++--- design-system.css | 5 + extensions/ca2a/v0.1/index.html | 14 +- go/agent-anomaly-detection/index.html | 10 +- go/agent-circuit-breaker/index.html | 10 +- go/agent-identity-credential/index.html | 10 +- go/agent-key-binding/index.html | 10 +- go/agent-purpose-declaration/index.html | 10 +- go/agent-rate-limiting/index.html | 10 +- go/agent-session-revocation/index.html | 10 +- go/agent-state-rollback/index.html | 10 +- go/agent-termination/index.html | 10 +- go/attested-a2a-channel/index.html | 10 +- go/behavioural-baseline/index.html | 10 +- go/blast-radius-containment/index.html | 10 +- go/capability-attenuation/index.html | 10 +- go/capability-manifest/index.html | 10 +- go/context-provenance/index.html | 10 +- go/continuous-usage-control/index.html | 10 +- go/evidence-transparency-anchoring/index.html | 10 +- go/graceful-degradation/index.html | 10 +- go/index.html | 143 +++++++++++------- go/input-schema-validation/index.html | 10 +- go/model-weight-custody/index.html | 10 +- go/output-encoding/index.html | 10 +- go/output-personal-data/index.html | 10 +- go/policy-verdict-rationale/index.html | 10 +- go/prompt-injection-prevention/index.html | 10 +- go/resource-allowlist/index.html | 10 +- go/runtime-attestation-evidence/index.html | 10 +- go/structured-action-logging/index.html | 10 +- go/tool-authorization/index.html | 10 +- go/transaction-limits/index.html | 10 +- go/verifiable-evidence-record/index.html | 10 +- index.html | 4 +- llms.txt | 6 +- marketplace/catalog/index.html | 2 +- marketplace/index.html | 20 +-- quickstart/index.html | 32 ++-- registry/index.html | 94 +++++++----- research/agent-manifest/index.html | 5 +- research/agent-manifest/v1/index.html | 4 +- research/agent-manifest/v2/index.html | 4 +- research/agentrust-telemetry/index.html | 5 +- research/agentrust-telemetry/v1/index.html | 4 +- research/agentrust-telemetry/v2/index.html | 4 +- research/ca2a/index.html | 5 +- research/ca2a/v1/index.html | 4 +- research/ca2a/v2/index.html | 4 +- research/ca2a/v3/index.html | 4 +- .../challenge-bound-memory-sweep/index.html | 5 +- .../v1/index.html | 4 +- research/cmcp/index.html | 5 +- research/cmcp/v1/index.html | 4 +- research/cmcp/v2/index.html | 4 +- research/confidential-handoffs/index.html | 5 +- research/confidential-handoffs/v1/index.html | 4 +- research/confidential-handoffs/v2/index.html | 4 +- research/confidential-handoffs/v3/index.html | 4 +- research/durable-shutdown-blocks/index.html | 5 +- .../durable-shutdown-blocks/v1/index.html | 4 +- research/exact-output-disclosure/index.html | 5 +- .../exact-output-disclosure/v1/index.html | 4 +- .../index.html | 5 +- .../v1/index.html | 4 +- research/index.html | 18 +-- research/kill-switch/index.html | 5 +- research/kill-switch/v1/index.html | 4 +- .../model-key-broker-provisioning/index.html | 5 +- .../v1/index.html | 4 +- .../receipt-gated-model-serving/index.html | 5 +- .../receipt-gated-model-serving/v1/index.html | 4 +- .../index.html | 5 +- .../v1/index.html | 4 +- research/research.css | 3 + .../telemetry-evidence-acceptance/index.html | 5 +- .../v1/index.html | 4 +- .../v2/index.html | 4 +- .../v3/index.html | 4 +- research/trace/index.html | 5 +- research/trace/v1/index.html | 4 +- research/trace/v2/index.html | 4 +- research/trace/v3/index.html | 4 +- research/weight-custody-manifest/index.html | 5 +- .../weight-custody-manifest/v1/index.html | 4 +- .../weight-custody-manifest/v2/index.html | 4 +- search/index.html | 12 +- telemetry/index.html | 86 ++++++----- tools/build-controls.py | 55 ++++--- tools/build-research.py | 14 +- tools/site_header.py | 2 +- verify/index.html | 60 +++++--- wcm/index.html | 2 +- 98 files changed, 726 insertions(+), 532 deletions(-) diff --git a/404.html b/404.html index 56ae970..6d8d327 100644 --- a/404.html +++ b/404.html @@ -3,7 +3,7 @@ Page not found | AgenTrust - + @@ -40,16 +40,16 @@

404 · Page not found

Find your next step.

-

This address may have moved, or the link may be incomplete. Older links pointed at homepage sections that are now one four-step chain.

+

There is no page at this address. It may have moved, or the link may be cut short. Some older links pointed at homepage sections that have since been merged into one four-step overview. Try one of these instead:

- + diff --git a/community/index.html b/community/index.html index f14a518..50f9e4d 100644 --- a/community/index.html +++ b/community/index.html @@ -4,7 +4,7 @@ Community: Partners, Sponsor and Contributors | AgenTrust - + @@ -18,7 +18,7 @@ - + @@ -29,7 +29,7 @@ - + - + @@ -124,23 +124,23 @@

Community

The people and organisations behind AgenTrust

-

Partner and sponsor relationships linked to public evidence, how the projects are governed, and how to contribute.

+

AgenTrust is a set of free, open specifications and tools for checking what an AI system ran and what it did (the terms, in plain English). This page lists who builds and supports it, how decisions are made, and how you can take part. Every relationship named here links to something public you can check.

Follow AgenTrust on LinkedIn for project updates and community highlights. To suggest work for a feature, use the Message button on the LinkedIn page and send a link with a few lines about what you would like us to cover.

-
From open technology to durable infrastructure
-

An ecosystem built around adoption

+
Three ways to take part
+

Use it, improve it, keep it going

-

Use it

Start with runnable demos, reference implementations, schemas, and conformance tests. Move from evaluation to a production pilot without waiting for a proprietary platform.

-

Improve it

Bring implementation feedback, integrations, threat models, deployment evidence, and research. Public repositories and issue trackers make the contribution path visible.

-

Sustain it

Grow maintainers, review contributions, document adoption patterns, and share stewardship across organizations so critical governance infrastructure outlives any one team.

+

Use it

Start with demos you can run, working example code, data formats and tests. You can go from trying it out to a real pilot without buying anything or waiting for a closed product.

+

Improve it

Tell us what broke, build connections to other tools, point out security weaknesses, share results from real deployments, or publish research. All the code and issue lists are public, so you can see where help is needed.

+

Keep it going

Help review changes, become a maintainer, write up how you use it, and share the upkeep across organisations, so the work does not depend on any one team.

-
Adoption pathway: explore a ten-minute demo → test against the open suites → pilot one trust boundary → contribute results and integrations → help govern and maintain the shared infrastructure.
- +
A typical path: try a ten-minute demo → run the open tests → pilot it on one part of your system → share your results and integrations → help run and maintain the projects.
+
@@ -150,11 +150,11 @@

An ecosystem built around adoption

Verified ecosystem evidence

Relationships the public record supports

-

Every organization named here has a traceable relationship through a public announcement, open-source repository, or explicit AgenTrust partner statement. The label on each card states that relationship precisely; sponsorship, partnership, contribution, and adoption are distinct relationships, and none implies blanket endorsement of the full stack.

+

Every organisation named here is backed by something public: an announcement, an open-source repository, or a partner statement. The label on each card says exactly what the relationship is. Sponsoring, partnering, contributing and adopting are different things, and none of them means an organisation endorses everything AgenTrust does.

The Linux Foundation
-
Neutral host

TRACE Specification is an LF Project

TRACE is hosted at the Linux Foundation as its own series. Its specification, IP, trademark, and conformance mark sit with the series under the Community Specification License and LF Projects policies, so no single vendor decides what conformance means. It has also been proposed to the Agentic AI Foundation at the Sandbox stage.

Read the project governance ↗
+
Neutral host

TRACE Specification is an LF Project

TRACE, the receipt format, is hosted at the Linux Foundation as its own project (a Series of LF Projects). The specification, its intellectual property, its trademark and its conformance mark belong to that project under the Community Specification License and LF Projects policies, so no single company decides what passing the tests means. It has also been proposed to the Agentic AI Foundation as an early-stage Sandbox project.

Read the project governance ↗
@@ -166,25 +166,25 @@

Relationships the public record supports

Microsoft
Open-source project home
-

Microsoft hosts the Agent Governance Toolkit, the open runtime-governance foundation that the AgenTrust trust chain builds on.

+

Microsoft hosts the Agent Governance Toolkit, open-source software that checks what AI agents do against rules while they run. AgenTrust builds on it.

View the repository ↗
Technology Innovation Institute
Confirmed founding partner
-

TII is the confirmed AgenTrust founding partner anchoring the work in sovereign-AI deployment requirements.

+

TII is the confirmed AgenTrust founding partner. It keeps the work grounded in what a country needs when it runs AI on infrastructure it controls.

Read the OPAQUE announcement ↗
AMD
Founding member and hardware partner
-

AMD is a founding partner of AgenTrust. AMD and OPAQUE published a joint implementation blueprint for hardware-backed Confidential AI, and the implementation verifies SEV-SNP report signatures to the AMD root.

+

AMD is a founding partner of AgenTrust. AMD and OPAQUE published a joint implementation blueprint for hardware-backed Confidential AI, and the AgenTrust code checks signed reports from AMD SEV-SNP processors back to AMD's root certificate.

Read the joint white paper ↗
Intel
Founding member and hardware partner
-

Intel is a founding partner of AgenTrust. The implementation verifies Intel TDX DCAP v4 quotes to the pinned Intel SGX Root CA, hardware-validated on GCP C3.

+

Intel is a founding partner of AgenTrust. The AgenTrust code checks signed reports from Intel TDX processors (DCAP v4 quotes) back to Intel's root certificate, tested on real Google Cloud C3 machines.

Review the public implementation record ↗
@@ -196,24 +196,24 @@

Relationships the public record supports

CSA Agentic Trust Framework
Public framework collaboration
-

ATF's author publicly supports positioning AGT as a reference implementation and invited implementation input into the conformance specification.

+

The author of the CSA Agentic Trust Framework (ATF) publicly supports the Agent Governance Toolkit (AGT) as a reference implementation, a working example of the framework, and invited implementers to help shape its conformance specification.

Read the public collaboration thread ↗
PRONATIVE AI
Ecosystem Training & Adoption Partner
-

PRONATIVE AI works with AgenTrust to bring verifiable agent governance into enterprise engineering education and adoption. The partnership includes joint educational programming and the planned integration of cMCP, cA2A, and TRACE into PRONATIVE AI's AI-Native Engineering Foundry curriculum. PRONATIVE AI is also adopting the Microsoft Agent Governance Toolkit within its delivery environment and will publish implementation guidance as that work becomes publicly available.

+

PRONATIVE AI works with AgenTrust to teach enterprise engineering teams how to run AI agents whose actions can be checked. The partnership includes joint training sessions and the planned addition of cMCP, cA2A and TRACE to PRONATIVE AI's AI-Native Engineering Foundry curriculum. PRONATIVE AI is also adopting the Microsoft Agent Governance Toolkit in its own delivery work and will publish implementation guidance once that work is public.

View the featured session ↗
XRSI: Human Intelligence In The Loop
-
Ecosystem partner

Governance and Ecosystem Sustainability Partner

XRSI brings governance, community-building, and long-term ecosystem sustainability expertise to the AgenTrust adoption programme.

+
Ecosystem partner

Governance and Ecosystem Sustainability Partner

XRSI brings experience in governance, community building and keeping open projects going over the long term to the AgenTrust adoption programme.

Action State Group
-
Technical collaborator

Trust Registry and Verifiable Record Collaboration

Action State Group is collaborating with AgenTrust on an open contribution path for the TRACE Trust Registry, connecting TRACE runtime evidence with neutral, independently verifiable record and witness infrastructure.

Visit Action State Group ↗
+
Technical collaborator

Trust Registry and Verifiable Record Collaboration

Action State Group is working with AgenTrust on an open way to contribute to the TRACE Trust Registry, connecting TRACE receipts to neutral record-keeping and witness services that anyone can check independently.

Visit Action State Group ↗
Odystra AI
@@ -221,7 +221,7 @@

Relationships the public record supports

o1Labs
-
Startup supporter

o1Labs

o1Labs develops applications and infrastructure powered by zero-knowledge cryptography.

Visit o1Labs ↗
+
Startup supporter

o1Labs

o1Labs develops applications and infrastructure built on zero-knowledge cryptography, which proves a statement is true without revealing the data behind it.

Visit o1Labs ↗
@@ -229,7 +229,7 @@

Relationships the public record supports

Join the ecosystem

Building with, sponsoring, or supporting AgenTrust?

-

Share your implementation, integration, contribution, sponsorship, or partnership context. Every relationship is described precisely and linked to public evidence where available.

+

Tell us what you are building, connecting or contributing, or how you would like to sponsor or partner. OPAQUE sponsors AgenTrust today, and further sponsors are welcome. We describe every relationship exactly and link it to public evidence where there is some.

Start a discussion → @@ -242,16 +242,16 @@

Building with, sponsoring, or supporting AgenTru
Community governance

Open work, visible decisions, more maintainers

-

AgenTrust develops in public through open repositories, reviewable proposals, implementation evidence, and conformance testing. The goal is not simply to publish specifications: it is to create a contributor community capable of operating, improving, and stewarding the technology.

+

All AgenTrust work happens in public: the code, the proposals for changes, the evidence from real deployments and the test results. Publishing specifications is only half the job. The other half is building a group of contributors who can run, improve and look after the technology themselves.

-
Technical stewardship

Imran Siddique

AgenTrust
Architecture, implementation, conformance, and maintainer development.

-
Governance & sustainability

XRSI

Named organizational partner for community governance, ecosystem adoption, and long-term sustainability. Individual committee appointments will be published only after confirmation.

-
Committee formation

Community seats

Adopter, maintainer, research, and public-interest representation will be added as the steering model is formalized.

+
Technical lead

Imran Siddique

AgenTrust
Overall design, code, the conformance tests, and growing new maintainers.

+
Governance & sustainability

XRSI

The named partner organisation for how the community is run, how others adopt the work, and keeping it going long term. Individual committee members will be named only once confirmed.

+
Committee formation

Community seats

Seats for adopters, maintainers, researchers and the public interest will be added as the steering committee takes shape.

@@ -268,7 +268,7 @@

NSF PESOSE Track 1 submission (in review)

Compliance adoption roadmap

From runtime evidence to compliance playbooks

-

We are turning AgenTrust implementation patterns into practical, public playbooks. Each playbook will map governance controls and TRACE evidence to an authoritative framework without claiming certification or legal compliance.

+

We are writing public, practical guides (playbooks) for the rules and standards organisations already answer to. Each one will show which AgenTrust checks and which TRACE receipts help with which requirement. A playbook is a guide: using it does not certify you or make you legally compliant. None of these is published yet.

Management systemISO/IEC 42001Planned playbook TransparencyEU AI Act · Article 50Planned playbook @@ -285,12 +285,12 @@

From runtime evidence to compliance playbooks

New field guide · Published September 2026

Architecting at Scale

-

AgenTrust founder Imran Siddique has turned the lessons behind production cloud and AI systems into a practical book. It connects the architecture of distributed systems with the harder problem now in front of us: building AI-native systems that remain observable, governable, and correct when they meet production.

+

AgenTrust founder Imran Siddique has written a practical book from the lessons of running large cloud and AI systems. It covers how to design systems that run across many machines, and how to build AI systems that you can still watch, control and trust to be correct once real users depend on them.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/agentrust-telemetry/index.html b/research/agentrust-telemetry/index.html index 3dec984..904e235 100644 --- a/research/agentrust-telemetry/index.html +++ b/research/agentrust-telemetry/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

From Agent Observability to Governance Evidence: A Privacy-Constrained Telem

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewedPatent Pending
+

In plain English

Monitoring tools for AI agents record what happened, but they drop data and can capture sensitive content, so they make poor audit evidence. This report proposes a shared format for six kinds of governance events, such as policy decisions and human approvals, that keeps prompts, outputs and secrets out and keeps everyday monitoring separate from audit evidence. The tested release passed its tests, but whether the evidence is complete is something the producer states rather than something the system measures, and a defect found later let an edited snapshot be signed.

Abstract

Agent observability conventions describe model, tool, and agent operations, but governance facts are commonly fragmented across policy engines, approval stores, cost modules, and audit systems. Copying those facts into ordinary traces creates two hazards: sensitive payload capture and the false inference that sampled operational telemetry is complete audit evidence. This technical report describes AgenTrust Telemetry, a backend-neutral contract for six governance event families: policy decisions, approval lifecycles, usage, classified data flows, action execution, and evidence lifecycle. The contract correlates with W3C Trace Context and OpenTelemetry without installing a provider, exporter, or competing tracing model. A metadata-only profile rejects prompts, outputs, source code, tool arguments and results, credentials, and authorization tokens by key. Durable run and action identifiers survive process and asynchronous handoffs; propagated metadata remains untrusted and does not confer identity or authority. An optional accumulator accepts events before lossy export and can be finalized into a separately verifiable TRACE record. Its completeness status is a producer assertion that the accumulator records but does not measure. The evaluated release, 0.1.0-alpha.2, ships Python and TypeScript reference SDKs over shared schemas and a portable conformance set of six valid and seven invalid fixtures. At that commit 111 Python unit tests pass and all 13 fixtures produce their expected verdicts, on September 3, 2026 and again when rerun for this edition. A defect found after the evaluation let an edited evidence snapshot be signed; it is reported beside the results it qualifies. The contribution is not another agent tracing convention; it is a narrow semantic boundary between operational observation and governance evidence whose completeness must be stated rather than inferred.

What this report contributes

A backend-neutral contract for six governance event families that keeps lossy operational telemetry separate from evidence whose completeness is stated.

@@ -91,5 +92,5 @@

From Agent Observability to Governance Evidence: A Privacy-Constrained Telem

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/agentrust-telemetry/v1/index.html b/research/agentrust-telemetry/v1/index.html index d7720ad..6a1d340 100644 --- a/research/agentrust-telemetry/v1/index.html +++ b/research/agentrust-telemetry/v1/index.html @@ -24,7 +24,7 @@ - + @@ -91,5 +91,5 @@

From Agent Observability to Governance Evidence: A Privacy-Constrained Telem

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/agentrust-telemetry/v2/index.html b/research/agentrust-telemetry/v2/index.html index dd68e92..80777eb 100644 --- a/research/agentrust-telemetry/v2/index.html +++ b/research/agentrust-telemetry/v2/index.html @@ -24,7 +24,7 @@ - + @@ -91,5 +91,5 @@

From Agent Observability to Governance Evidence: A Privacy-Constrained Telem

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/ca2a/index.html b/research/ca2a/index.html index ecb9c59..ea9fd0d 100644 --- a/research/ca2a/index.html +++ b/research/ca2a/index.html @@ -26,7 +26,7 @@ - + @@ -69,6 +69,7 @@

cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A

Rishabh Poddar, Aaron Fulkerson, Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewedPatent Pending
+

In plain English

When one AI agent hands a task to another, the standard A2A protocol does not limit the authority passed along, check what software the other agent runs, or leave a record of who asked whom. cA2A adds those protections on top of A2A: permissions that can only shrink at each handoff, a check of the other agent's hardware evidence before sending, an encrypted task and a signed record of each step. Software tests confirm these behaviors, but trust between hardware run by two independent organizations has not yet been shown.

Abstract

The Agent2Agent (A2A) protocol moves tasks between agents, and its Signed Agent Card lets a client check that a domain owner issued a card. The card does not bound the authority a delegating agent passes on, establish what code a peer runs, keep a task payload from the peer's host, or leave an offline record of who delegated what to whom. This technical report describes cA2A (Confidential A2A), a trust profile layered on A2A rather than a new transport. It composes four mechanisms: signed delegation credentials whose scope can only narrow at each hop, appraisal of a peer's attestation evidence before a task is sent, a payload sealed to the channel key that evidence vouches for, and a signed per-hop provenance record linked to its parent. Attenuated delegation and provenance binding are covered by prior capability-token work and IETF drafts; the contribution here is their composition on A2A with an open implementation. We state six properties and report software experiments rerun against ca2a 0.3.1: attenuation checks over 5,400 generated chains, rejection of in-chain replay and cross-chain splicing, intersection of delegated scope with local policy, sealed-payload behavior at the cryptographic layer, structural checks on linked provenance records, and a cross-operator attestation protocol exercised with synthetic evidence. Chain verification cost about 0.22 ms per hop in this environment. These results do not show that a peer's key is confined to attested code or that attestation works across independent operators. Recorded hardware runs cover one-directional appraisal of an Intel TDX peer by an AMD SEV-SNP peer in another cloud and a same-operator mutual SEV-SNP diagnostic; mutual attestation between independent operators has not been demonstrated.

What this report contributes

A trust profile on A2A composing narrowing delegation credentials, peer attestation appraisal, sealed payloads and linked per-hop provenance records.

@@ -94,5 +95,5 @@

cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/ca2a/v1/index.html b/research/ca2a/v1/index.html index 95f7b27..cdf588b 100644 --- a/research/ca2a/v1/index.html +++ b/research/ca2a/v1/index.html @@ -26,7 +26,7 @@ - + @@ -94,5 +94,5 @@

cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/ca2a/v2/index.html b/research/ca2a/v2/index.html index 5dd80c0..52174b6 100644 --- a/research/ca2a/v2/index.html +++ b/research/ca2a/v2/index.html @@ -26,7 +26,7 @@ - + @@ -94,5 +94,5 @@

cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/ca2a/v3/index.html b/research/ca2a/v3/index.html index 04f6e4e..b32a589 100644 --- a/research/ca2a/v3/index.html +++ b/research/ca2a/v3/index.html @@ -26,7 +26,7 @@ - + @@ -94,5 +94,5 @@

cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/challenge-bound-memory-sweep/index.html b/research/challenge-bound-memory-sweep/index.html index 67a8158..8a069e9 100644 --- a/research/challenge-bound-memory-sweep/index.html +++ b/research/challenge-bound-memory-sweep/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

A Challenge-Bound Memory-Consistency Predicate for Model-Key Release

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

Before a model's decryption key is released, the key service checks what software is running but not how its memory behaves. This report adds an extra check: the machine writes and reads back a pattern over a stated memory range, based on a fresh challenge, signs the result, and gets the key only if that result is fresh, clean and signed by the expected key. It passed its software tests, but it covers only the stated range at that moment and does not stop an attacker with physical access to the machine.

Abstract

A key broker that gates model-key release on attestation checks code identity. It does not see how a designated memory region behaves while the release request is in flight. We describe a supplementary predicate implemented in Weight Custody Manifest. A runtime derives page-specific values and two traversal orders from a secret and the broker's challenge, writes every logical page, reads every page back, and signs a transcript of declared geometry, page counts, a readback commitment and a mismatch flag. The broker accepts the transcript only if it carries the current challenge, reports no mismatch and verifies under a pinned key, in addition to its existing release policy. At a pinned revision, 35 local tests across the memory sweep and broker modules passed on September 4, September 27 and October 1, 2026. A controlled aliased adapter yields an authentic negative transcript, which shows why signature verification and release approval have to be separate checks. We also analyze a retained 256 MiB protected-guest receipt without treating it as a fresh end-to-end key-release experiment. The predicate gives a bounded observation over a declared logical range. It does not prove full model-memory coverage, defeat a physical-owner attack or establish that memory stays unchanged after the check.

What this report contributes

A supplementary key-release predicate: a challenge-bound, signed write/read sweep of a declared memory range, accepted only when fresh, mismatch-free and signed by a pinned key.

@@ -90,5 +91,5 @@

A Challenge-Bound Memory-Consistency Predicate for Model-Key Release

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/challenge-bound-memory-sweep/v1/index.html b/research/challenge-bound-memory-sweep/v1/index.html index 084346c..debb109 100644 --- a/research/challenge-bound-memory-sweep/v1/index.html +++ b/research/challenge-bound-memory-sweep/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

A Challenge-Bound Memory-Consistency Predicate for Model-Key Release

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/cmcp/index.html b/research/cmcp/index.html index 096dfc8..d2ae3c0 100644 --- a/research/cmcp/index.html +++ b/research/cmcp/index.html @@ -26,7 +26,7 @@ - + @@ -69,6 +69,7 @@

cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls

Rishabh Poddar, Aaron Fulkerson, Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewedPatent Pending
+

In plain English

AI agents act through tools, and MCP (the Model Context Protocol) is a common way they call them. cMCP puts a checkpoint in front of those tool calls: it checks each call against a written policy before it runs and keeps a signed record of the decision. The report tests this in software with made-up healthcare traces; it did not test real confidential hardware or show that every call was captured.

Abstract

cMCP (Confidential MCP) proposes a gateway for policy evaluation at the Model Context Protocol tool-call boundary. The gateway evaluates Cedar policies before dispatch and emits signed records binding policy measurements, session identifiers, and tool-call evidence. Its design combines policy hashing, monotonic session sensitivity, tool-catalog pinning, and audit-chain checks. This technical report preserves software-only experiments for those mechanisms, including synthetic healthcare call traces and simulated attestation paths. The measurements illustrate behavior under the stated inputs and assumptions; they do not validate a hardware TEE, establish complete information-flow tracking, or show that every tool invocation was captured. Hardware provenance requires independent attestation appraisal and signing-key binding. Replay and omission detection additionally depend on freshness checks and an expected session or log boundary. The report distinguishes these deployment requirements from the software behavior measured here.

What this report contributes

A gateway design combining policy evaluation, session sensitivity, tool-catalog pinning, and signed tool-call records.

@@ -93,5 +94,5 @@

cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/cmcp/v1/index.html b/research/cmcp/v1/index.html index 33d68a8..914f2e7 100644 --- a/research/cmcp/v1/index.html +++ b/research/cmcp/v1/index.html @@ -26,7 +26,7 @@ - + @@ -93,5 +93,5 @@

cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/cmcp/v2/index.html b/research/cmcp/v2/index.html index 26c1653..a97d006 100644 --- a/research/cmcp/v2/index.html +++ b/research/cmcp/v2/index.html @@ -26,7 +26,7 @@ - + @@ -93,5 +93,5 @@

cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/confidential-handoffs/index.html b/research/confidential-handoffs/index.html index 36b1b8d..105a72a 100644 --- a/research/confidential-handoffs/index.html +++ b/research/confidential-handoffs/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Confidentiality Across Agent Handoffs: Conditions for preserving an inferenc

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewedPatent Pending
+

In plain English

Keeping data private inside one protected AI system is not enough if an agent then passes it to a tool or to another agent. This paper sets out the conditions each handoff must meet for the data to stay private, and says the sender must hold the data back when a recipient cannot meet them. Its software experiments show leaks earlier in a workflow even when the final answer arrives correctly, and it states that today's AgenTrust components do not yet deliver the full guarantee.

Abstract

This paper states conditions under which tool calls and agent handoffs preserve an authorized plaintext-holder boundary. This requires a protected channel bound to an appraised workload, restricted authority, enforceable downstream information-flow rules, and control over every other plaintext sink. A signature on an execution record or a valid hardware quote alone cannot establish these conditions. If a recipient cannot satisfy them, the sender must withhold the data or obtain authorization for a precisely described disclosure. This paper develops a conditional composition argument, a proposed handoff contract, and component experiments that expose failures of appraisal, supervision, and outcome inference. A composed software harness joins provisioning, diagnostic model computation, a confined agent, a mediated tool, delegated peer authentication, and exact-output disclosure. Its paired mutations expose earlier leaks despite successful final delivery; a rerun on September 27, 2026 reproduced all 36 recorded observations. All results are software results with synthetic attestation and a single operator. AgenTrust supplies relevant identity, key-release, gateway, delegation, and evidence primitives, but its present components do not demonstrate the complete property. The distinction matters most at remote tools, CPU-GPU transfers, operator-controlled key brokers, runtime changes, and audit systems.

What this report contributes

A conditional composition argument and proposed handoff contract for when tool calls and delegations preserve an authorized plaintext-holder boundary.

@@ -92,5 +93,5 @@

Confidentiality Across Agent Handoffs: Conditions for preserving an inferenc

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/confidential-handoffs/v1/index.html b/research/confidential-handoffs/v1/index.html index afc2868..8ca2f4b 100644 --- a/research/confidential-handoffs/v1/index.html +++ b/research/confidential-handoffs/v1/index.html @@ -24,7 +24,7 @@ - + @@ -92,5 +92,5 @@

Confidentiality Across Agent Handoffs: Conditions for preserving an inferenc

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/confidential-handoffs/v2/index.html b/research/confidential-handoffs/v2/index.html index 0e9a612..68e103e 100644 --- a/research/confidential-handoffs/v2/index.html +++ b/research/confidential-handoffs/v2/index.html @@ -24,7 +24,7 @@ - + @@ -92,5 +92,5 @@

Confidentiality Across Agent Handoffs: Conditions for preserving an inferenc

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/confidential-handoffs/v3/index.html b/research/confidential-handoffs/v3/index.html index ad7ca37..8ca5851 100644 --- a/research/confidential-handoffs/v3/index.html +++ b/research/confidential-handoffs/v3/index.html @@ -24,7 +24,7 @@ - + @@ -92,5 +92,5 @@

Confidentiality Across Agent Handoffs: Conditions for preserving an inferenc

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/durable-shutdown-blocks/index.html b/research/durable-shutdown-blocks/index.html index e8c6d3c..52f20e3 100644 --- a/research/durable-shutdown-blocks/index.html +++ b/research/durable-shutdown-blocks/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

When an Agent Kill Switch Trips: Durable blocks, linked refusals and work al

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

When an operator presses an AI agent's kill switch, what is actually stopped, and does it stay stopped after a restart? Testing the cMCP tool gateway, the report finds that new tool calls are refused with signed refusals anyone can check, and that the block survives restarts. It also finds that work already under way can still finish, in one case about 1.2 seconds after the kill switch had returned.

Abstract

An operator presses the kill switch on an agent. What is actually true a second later, a day later, and after someone restarts the gateway? We study this at one place where the answer can be tested: the cMCP tool gateway, which stores an identity block durably, closes the governed session with a signed claim, and signs every later refusal so that it names that claim by digest. Recovery takes an explicit operator action with a separate credential. On the pinned source, 86 selected tests pass, and removing the durable block lookup or the refusal signature check makes 17 and 2 of them fail. A block written once is seen by 20 of 20 reopened store connections. With four slow tool calls in flight, an operator trip admits nothing new in three different timing cases: calls sent 54 to 71 ms after the trip starts, and after it returns, are refused with a receipt that verifies. The same experiment measures what a trip does to work already admitted. Cooperative calls finish or are cancelled at the drain deadline, but a call running in a worker thread completes its effect about 1.2 s after the trip has returned, while its caller receives HTTP 500. A prototype challenge-response check, written for this study, lets a verifier ask whether the block is in force now, which an archived refusal cannot answer. All results were rerun on October 1, 2026 from a fresh environment and match the earlier records, and the same harness passes on current cMCP main.

What this report contributes

A tested account of what a tool-gateway kill switch establishes: a durable block, signed refusals that name the closing claim, explicit recovery, and the fate of work already admitted.

@@ -90,5 +91,5 @@

When an Agent Kill Switch Trips: Durable blocks, linked refusals and work al

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/durable-shutdown-blocks/v1/index.html b/research/durable-shutdown-blocks/v1/index.html index d15551f..13f2fc3 100644 --- a/research/durable-shutdown-blocks/v1/index.html +++ b/research/durable-shutdown-blocks/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

When an Agent Kill Switch Trips: Durable blocks, linked refusals and work al

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/exact-output-disclosure/index.html b/research/exact-output-disclosure/index.html index d6780e7..b8b3312 100644 --- a/research/exact-output-disclosure/index.html +++ b/research/exact-output-disclosure/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes,

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

An answer an AI agent writes from confidential data still carries that data's restrictions. This report describes a release step in which the data's owner approves the exact answer for a named recipient and purpose, and the system delivers it at most once, reporting the outcome as unknown instead of resending when delivery is uncertain. Concurrency and crash tests in cMCP never produced a second delivery, though they ran on one machine and the approval ledger must itself be protected from being rolled back.

Abstract

An answer an agent writes from a confidential record keeps the record's restrictions, even when it reads like a harmless summary. This report describes a release path for that case. An owner signs the exact output bytes together with the recipient, purpose, source scope, inherited labels, policy version and a validity interval. A gate checks the signer's authority for that scope, verifies the signature, and commits a request identifier to a persistent ledger before it calls the one registered delivery adapter. If the acknowledgment is lost, the attempt stays consumed and the outcome is reported as unknown. Nothing is sent twice. We evaluate the implementation in cMCP, which ships in cmcp-runtime 0.6.0 and later. All 46 existing tests pass, and removing either of two controls makes specific tests fail. In 20 rounds of 16 concurrent attempts, every round delivered once. In 10 rounds of 8 competing sender processes, every round produced exactly one recorded receipt. Process kills on both sides of the ledger commit, lock timeouts, a corrupted ledger and a dropped acknowledgment never produced a second receipt; with replay consumption removed, all 9 of those cases fail. Every number was reproduced on October 1, 2026 at the evaluated revision and at current main.

What this report contributes

A release gate that ties owner-signed exact output bytes to a scoped, persistent, single-attempt decision and reports an uncertain delivery as unknown instead of repeating it.

@@ -90,5 +91,5 @@

Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes,

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/exact-output-disclosure/v1/index.html b/research/exact-output-disclosure/v1/index.html index f556a81..9a8b6fe 100644 --- a/research/exact-output-disclosure/v1/index.html +++ b/research/exact-output-disclosure/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes,

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/handoff-response-authentication/index.html b/research/handoff-response-authentication/index.html index 9bb6b6b..fa11717 100644 --- a/research/handoff-response-authentication/index.html +++ b/research/handoff-response-authentication/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Authenticating the Answer in an Agent Handoff: Single-use, request-bound res

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

When one agent sends a task to another, checking the other agent beforehand does not prove who wrote the answer that comes back, because a relay in between could swap or replay it. This report tests a cA2A mode that lets the caller accept exactly one genuine answer to its exact request, and report the outcome as unknown instead of retrying when something fails. Tests show it blocks swapped, replayed and doubled answers, but the check works only for the live caller and does not prove authorship to anyone else later.

Abstract

One agent appraises a peer, delegates a task to it, and gets an HTTP response back. Appraising the peer before sending says nothing about who wrote that response. A relay can swap the body, replay an answer from another call, or turn an error into a success. We study the strict response-authentication mode of the cA2A runtime, which binds the appraised peer key, the complete request and a fresh request occurrence into a key that can verify exactly one response, once. It authenticates success and denial bodies, binds the status the caller will act on, and reports an unknown outcome whenever verification or transport fails, instead of guessing. On the pinned source, 57 selected tests pass, including loopback HTTP exchanges, and removing the MAC comparison or the single-use consumption makes 4 and 3 of them fail. In 20 rounds of 16 concurrent verifications, exactly one response is accepted per round. With separate caller, relay and peer processes and the connection cut before dispatch, after execution, mid-body, or with the caller killed, the client submits once, reports unknown, and a restarted caller cannot accept the captured response. A control client that resends once on a transport error makes the peer execute one business operation twice. The authentication is for the live caller: the caller can compute the same MAC, so a stored response is not proof of peer authorship to a third party. All results were rerun on October 1, 2026 from a fresh environment and match the earlier records, and the same harness passes on current cA2A main.

What this report contributes

A strict response-authentication mode that binds the appraised peer key, the complete request and a fresh occurrence into a single-use key, and reports unknown outcomes instead of guessing.

@@ -90,5 +91,5 @@

Authenticating the Answer in an Agent Handoff: Single-use, request-bound res

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/handoff-response-authentication/v1/index.html b/research/handoff-response-authentication/v1/index.html index 83834ff..408d397 100644 --- a/research/handoff-response-authentication/v1/index.html +++ b/research/handoff-response-authentication/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

Authenticating the Answer in an Agent Handoff: Single-use, request-bound res

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/index.html b/research/index.html index 9f499e0..2d43588 100644 --- a/research/index.html +++ b/research/index.html @@ -2,25 +2,25 @@ Research: AI Agent Identity, Enforcement and Evidence | AgenTrust - + - + - + - + - + @@ -57,9 +57,9 @@ -

AgenTrust Research

Identity, enforcement,
and evidence for AI agents.

Technical reports with open source, recorded experiments, and explicit limits. Read the work, inspect the evidence, and cite a specific version.

-
Research collection16 reports / Not peer reviewed
-

Read the evidence with the claim

These reports preserve historical designs and software evaluations. A signature, an attestation result, and an execution-completeness claim establish different properties. Each paper page identifies the evidence evaluated and the limits that remain.

For implementation, follow the current project specifications linked from each report. Paper text is available under CC BY 4.0; code retains its project license.

+

AgenTrust Research

Identity, enforcement,
and evidence for AI agents.

Reports on how to check what an AI agent is, what it is allowed to do, and what it actually did. Each comes with a PDF, its source code and recorded test results, and says plainly what it does not prove. Read the work, check the evidence yourself, and cite a specific version.

+
Research collection16 reports / Not peer reviewed

Runtime evidence

TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)

When an AI agent runs, the people who rely on it often want proof of what it ran: which model, which policy, which tools it called. TRACE proposes one portable, signed record of those facts that anyone can check against their own rules. The report measures how quickly such records are signed and checked and how large they are, and states plainly that a signature alone does not prove the record came from trusted hardware or that its claims are true.

Rishabh Poddar, Aaron Fulkerson, Imran Siddique

Version 3 / October 1, 2026 / Technical report

Read the report

Tool-call enforcement

cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls

AI agents act through tools, and MCP (the Model Context Protocol) is a common way they call them. cMCP puts a checkpoint in front of those tool calls: it checks each call against a written policy before it runs and keeps a signed record of the decision. The report tests this in software with made-up healthcare traces; it did not test real confidential hardware or show that every call was captured.

Rishabh Poddar, Aaron Fulkerson, Imran Siddique

Version 2 / October 1, 2026 / Technical report

Read the report

Agent identity

Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents

An AI agent is defined by many parts: its instructions, model, policy, tools, memory and the people who approved it. Agent Manifest proposes a signed list of those parts, so that a later change to any of them can be spotted by someone holding the parts and the right keys. The report measures signing speed and tampering tests, notes that the tested version accepted forged human approvals (later versions check them), and states that a signed list alone does not prove the agent actually ran with those parts.

Imran Siddique

Version 2 / October 1, 2026 / Technical report

Read the report

Model weight custody

Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights

When a company runs its private AI model on computers someone else controls, it needs a way to keep control of the model. WCM is an open protocol that releases the model's key only to approved, checked software, requires that permission to be renewed, and records evidence of deletion and of any models derived from it. The tested code passed all 91 shared conformance tests; the report also describes two flaws in that version (fixed later) and a missing hardware setting on the tested cloud machine without which the strongest protection does not hold.

Imran Siddique

Version 2 / October 1, 2026 / Technical report

Read the report

Delegation evidence

cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A

When one AI agent hands a task to another, the standard A2A protocol does not limit the authority passed along, check what software the other agent runs, or leave a record of who asked whom. cA2A adds those protections on top of A2A: permissions that can only shrink at each handoff, a check of the other agent's hardware evidence before sending, an encrypted task and a signed record of each step. Software tests confirm these behaviors, but trust between hardware run by two independent organizations has not yet been shown.

Rishabh Poddar, Aaron Fulkerson, Imran Siddique

Version 3 / October 1, 2026 / Technical report

Read the report

Governance telemetry

From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract

Monitoring tools for AI agents record what happened, but they drop data and can capture sensitive content, so they make poor audit evidence. This report proposes a shared format for six kinds of governance events, such as policy decisions and human approvals, that keeps prompts, outputs and secrets out and keeps everyday monitoring separate from audit evidence. The tested release passed its tests, but whether the evidence is complete is something the producer states rather than something the system measures, and a defect found later let an edited snapshot be signed.

Imran Siddique

Version 2 / October 1, 2026 / Technical report

Read the report

Confidential handoffs

Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation

Keeping data private inside one protected AI system is not enough if an agent then passes it to a tool or to another agent. This paper sets out the conditions each handoff must meet for the data to stay private, and says the sender must hold the data back when a recipient cannot meet them. Its software experiments show leaks earlier in a workflow even when the final answer arrives correctly, and it states that today's AgenTrust components do not yet deliver the full guarantee.

Imran Siddique

Version 3 / October 1, 2026 / Technical report

Read the report

Governance telemetry

Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry

Monitoring systems can lose events, so their records cannot prove that every governance event was kept. This report proposes recording each event as evidence at the source first, before it is sent to any monitoring system, so a failed export never means lost evidence. Tests confirm that separation and also show its limits: nothing guarantees an event is stored exactly once, and an empty record can still be declared complete.

Imran Siddique

Version 3 / October 1, 2026 / Technical report

Read the report

Model weight custody

A Challenge-Bound Memory-Consistency Predicate for Model-Key Release

Before a model's decryption key is released, the key service checks what software is running but not how its memory behaves. This report adds an extra check: the machine writes and reads back a pattern over a stated memory range, based on a fresh challenge, signs the result, and gets the key only if that result is fresh, clean and signed by the expected key. It passed its software tests, but it covers only the stated range at that moment and does not stop an attacker with physical access to the machine.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report

Human oversight

Requirement-Preserving Human Approvals for Signed Agent Manifests

A person often approves an AI agent after its signed description, its manifest, has already been issued. This report shows how to sign the rule that a human must approve so nobody can weaken it, while still letting each approver add their own signed approval later. Tests confirm the design and found a gap in the tested version that a later change closed, and the report lists the further checks on identity and action a system still needs before acting on an approval.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report

Disclosure control

Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery

An answer an AI agent writes from confidential data still carries that data's restrictions. This report describes a release step in which the data's owner approves the exact answer for a named recipient and purpose, and the system delivers it at most once, reporting the outcome as unknown instead of resending when delivery is uncertain. Concurrency and crash tests in cMCP never produced a second delivery, though they ran on one machine and the approval ledger must itself be protected from being rolled back.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report

Model weight custody

Owner-Approved Provisioning of a Model-Key Broker: Binding the broker's configuration, receiving key and policy epoch before the model key leaves the owner

A model owner can require checks before a key service releases the model's key, but that does not help if the operator can quietly change the key service itself. This report has the owner check the key service first, confirming its software, its settings and a fresh receiving key, before handing over the model key. Software tests show that changed or outdated setups are refused, but no real hardware or model key was used, and the owner's own records must be protected against rollback.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report

Tool-call enforcement

When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway

When an operator presses an AI agent's kill switch, what is actually stopped, and does it stay stopped after a restart? Testing the cMCP tool gateway, the report finds that new tool calls are refused with signed refusals anyone can check, and that the block survives restarts. It also finds that work already under way can still finish, in one case about 1.2 seconds after the kill switch had returned.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report

Delegation evidence

Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know

When one agent sends a task to another, checking the other agent beforehand does not prove who wrote the answer that comes back, because a relay in between could swap or replay it. This report tests a cA2A mode that lets the caller accept exactly one genuine answer to its exact request, and report the outcome as unknown instead of retrying when something fails. Tests show it blocks swapped, replayed and doubled answers, but the check works only for the live caller and does not prove authorship to anyone else later.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report

Model serving

Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt

A confidential AI model host has to start before it can prove it is trustworthy, so the question is when users should be allowed to reach it. This report sends traffic to the host only after a signed admission receipt for that exact session has been checked, removes the route when the session ends, and keeps a durable record so a revoked session can never be reopened. Software tests confirm the design without a real cluster or confidential GPU, and show that the record itself must be protected against being rolled back.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report

Tool-call enforcement

What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an agent tool gateway

Pressing a kill switch, getting a signed refusal and seeing nothing further happen are three different things. Testing the cMCP gateway, the report finds that it refuses new work and stays blocked after a restart, but also that a call already admitted can finish and a tool reached directly, around the gateway, can still act. It proposes a way to evaluate shutdown that checks each of these separately, including a fresh check of whether the block holds now.

Imran Siddique

Version 1 / October 1, 2026 / Technical report

Read the report
+

Read the evidence with the claim

Each report records a design and its tests as they stood on a given date. A digital signature, a hardware check (attestation) and a claim that every action was recorded each prove different things. Each paper page says which evidence was examined and what is still unproven.

To build on this work, follow the current project specifications linked from each report. Paper text is available under CC BY 4.0; code keeps its project license.

- + diff --git a/research/kill-switch/index.html b/research/kill-switch/index.html index d0efc6a..a4a5ab9 100644 --- a/research/kill-switch/index.html +++ b/research/kill-switch/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an age

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewedPatent Pending
+

In plain English

Pressing a kill switch, getting a signed refusal and seeing nothing further happen are three different things. Testing the cMCP gateway, the report finds that it refuses new work and stays blocked after a restart, but also that a call already admitted can finish and a tool reached directly, around the gateway, can still act. It proposes a way to evaluate shutdown that checks each of these separately, including a fresh check of whether the block holds now.

Abstract

A shutdown command, a signed refusal and the absence of subsequent effects are different observations. We examine those distinctions using the merged cMCP gateway kill switch and its accompanying policy-key and delegation revocation mechanisms. A reproducible evaluator drives gateway startup, signed agent identity, Cedar evaluation, loopback HTTP tool calls, durable blocks, process restart, recovery and offline receipt verification. The reference run satisfies 27 named assertions. Two targeted implementation weakenings are detected at their intended assertions. Separately, 81 existing cMCP component tests and 38 cA2A revocation tests pass on pinned source revisions. The observed system refuses new tool work through the stopped gateway and retains its block after restart. An admitted call can nevertheless finish during shutdown, a direct tool path can produce an effect while the gateway is stopped, and a historical refusal still verifies after recovery. These counterexamples establish the limits of treating a signed receipt as evidence of continuing or universal shutdown. We propose an evaluator protocol that separates admission, effects, persistence, recovery and freshness, with an explicit role for independent observation. The exercise uses software keys, one operator and no model or confidential hardware.

What this report contributes

An evaluator protocol that separates admission, drain, persistence, recovery and evidence at a tool gateway, with counterexamples to reading a signed refusal as proof of continuing shutdown.

@@ -90,5 +91,5 @@

What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an age

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/kill-switch/v1/index.html b/research/kill-switch/v1/index.html index 4e3a91a..af6ac6d 100644 --- a/research/kill-switch/v1/index.html +++ b/research/kill-switch/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an age

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/model-key-broker-provisioning/index.html b/research/model-key-broker-provisioning/index.html index 220d8d3..df3faee 100644 --- a/research/model-key-broker-provisioning/index.html +++ b/research/model-key-broker-provisioning/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Owner-Approved Provisioning of a Model-Key Broker: Binding the broker's

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

A model owner can require checks before a key service releases the model's key, but that does not help if the operator can quietly change the key service itself. This report has the owner check the key service first, confirming its software, its settings and a fresh receiving key, before handing over the model key. Software tests show that changed or outdated setups are refused, but no real hardware or model key was used, and the owner's own records must be protected against rollback.

Abstract

A model owner can require workload attestation before a key broker releases a decryption key, and still lose control if the deployment operator can change the broker itself: its trust roots, its list of accepted model manifests, or the owner key it trusts. This report describes provisioning in the other direction. The owner treats the broker as a recipient. Before sending the model key, the owner appraises a signed attestation report that commits to the broker's launch measurement, a digest of the configuration the broker actually constructed, a fresh receiving key, the model identity and the policy epoch. A separate deployment approval pins the build artifacts and launch parameters. The receiver installs one owner-authenticated envelope, serves workloads, and refuses every path after retirement. We evaluate the implementation in the Weight Custody Manifest library, released in weight-custody-manifest 0.28.4 and later. All 84 existing tests pass, and removing the configuration or measurement check makes 5 and 3 specific tests fail. A retired receiver in its own process refused all four API paths, and an old envelope would not install in a replacement. Across separate owner processes sharing one epoch store, a stale live owner, a restarted stale owner and a same-epoch substitution were all refused, and a killed policy admission left the floor unchanged. Every number was reproduced on October 1, 2026 at the evaluated revision and at current main.

What this report contributes

An owner-side provisioning protocol that appraises the broker as a recipient, binding its configuration, fresh receiving key, model identity and policy epoch before the model key leaves.

@@ -90,5 +91,5 @@

Owner-Approved Provisioning of a Model-Key Broker: Binding the broker's

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/model-key-broker-provisioning/v1/index.html b/research/model-key-broker-provisioning/v1/index.html index 41609e4..0c22354 100644 --- a/research/model-key-broker-provisioning/v1/index.html +++ b/research/model-key-broker-provisioning/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

Owner-Approved Provisioning of a Model-Key Broker: Binding the broker's

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/receipt-gated-model-serving/index.html b/research/receipt-gated-model-serving/index.html index fad72d0..65ec0d9 100644 --- a/research/receipt-gated-model-serving/index.html +++ b/research/receipt-gated-model-serving/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Receipt-Gated Model Serving: Routing to a confidential model host only after

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

A confidential AI model host has to start before it can prove it is trustworthy, so the question is when users should be allowed to reach it. This report sends traffic to the host only after a signed admission receipt for that exact session has been checked, removes the route when the session ends, and keeps a durable record so a revoked session can never be reopened. Software tests confirm the design without a real cluster or confidential GPU, and show that the record itself must be protected against being rolled back.

Abstract

A confidential model host has to exist before it can attest, so the Pod comes first. The open question is when clients may reach it. This report describes a mechanism that answers it with evidence. A planner produces a bootstrap Pod that holds only encrypted model material, and produces the Kubernetes Service that routes to it only after it has verified a signed admission receipt for that exact hosting session: pinned signer key, first position in the receipt chain, and equality with six application bindings (tenant, model, encrypted artifact, workload, policy, transport). A signed, terminal lifecycle receipt for the same session removes the route. Because the planner keeps no state, a controller carries a durable, monotonic per-session ledger, so a session that has been revoked can never be routed again from its old admission. We evaluated the planner in an internal repository at two commits, and a reference implementation published with this report. The planner passed its 6 selected tests, rejected six correctly signed receipts that each carried one wrong binding, and, as expected for a stateless component, still accepted an old admission after revocation. The controller, run against a fake Kubernetes API in which every action is a fresh process, kept every revoked session unroutable across all 12 cases of its test matrix. Removing the ledger check, or keeping the ledger in memory, failed 7 of 12 cases. Restoring an old copy of the ledger reopened a revoked session, so the ledger itself needs rollback protection. The evidence is software only; no cluster, confidential GPU or model inference was used.

What this report contributes

A routing gate for confidential model hosts: the Kubernetes Service exists only from a verified first admission receipt for one session, and a durable per-session ledger keeps revoked sessions unroutable.

@@ -90,5 +91,5 @@

Receipt-Gated Model Serving: Routing to a confidential model host only after

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the AgenTrust public issue tracker and identify the report version and section.

- + diff --git a/research/receipt-gated-model-serving/v1/index.html b/research/receipt-gated-model-serving/v1/index.html index f9171d8..04a5a9d 100644 --- a/research/receipt-gated-model-serving/v1/index.html +++ b/research/receipt-gated-model-serving/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

Receipt-Gated Model Serving: Routing to a confidential model host only after

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the AgenTrust public issue tracker and identify the report version and section.

- + diff --git a/research/requirement-preserving-human-approval/index.html b/research/requirement-preserving-human-approval/index.html index d413db3..82fb0f0 100644 --- a/research/requirement-preserving-human-approval/index.html +++ b/research/requirement-preserving-human-approval/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Requirement-Preserving Human Approvals for Signed Agent Manifests

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

A person often approves an AI agent after its signed description, its manifest, has already been issued. This report shows how to sign the rule that a human must approve so nobody can weaken it, while still letting each approver add their own signed approval later. Tests confirm the design and found a gap in the tested version that a later change closed, and the report lists the further checks on identity and action a system still needs before acting on an approval.

Abstract

Human approval often arrives after an agent manifest has been issued. If the issuer signs the approval collection as immutable content, nobody can attach an approval later without a new signature. If the issuer leaves the whole oversight record unsigned, anyone can weaken the requirement. We analyze a two-domain construction: the issuer signs the oversight requirement while normalizing only its approvals array to empty, and each human separately signs an approval bound to a manifest and scope. A verifier reconstructs the issuer pre-image and evaluates human evidence on its own terms. Agent Manifest uses this pre-image for version 0.1 manifests; its version 0.2 COSE envelope reaches the same split by carrying approvals in the unprotected header. At a pinned Agent Manifest revision, 74 signing and delegation/HITL tests passed on September 4, September 27 and October 1, 2026. Separate probes confirm requirement binding and appendability. At the pinned revision they also show that the human signature did not cover the outer authenticator-method label. A later upstream change binds that label, and the same probe fails against two later revisions, including the October 1 main branch. The result is a precise signing boundary and a list of the identity, action and authenticator evidence a runtime still needs before it acts on an approval.

What this report contributes

A two-domain signing boundary: the issuer signs the oversight requirement with approvals normalized to empty, and each human signs an approval bound to a manifest and scope.

@@ -90,5 +91,5 @@

Requirement-Preserving Human Approvals for Signed Agent Manifests

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/requirement-preserving-human-approval/v1/index.html b/research/requirement-preserving-human-approval/v1/index.html index 055a82e..e86a346 100644 --- a/research/requirement-preserving-human-approval/v1/index.html +++ b/research/requirement-preserving-human-approval/v1/index.html @@ -24,7 +24,7 @@ - + @@ -90,5 +90,5 @@

Requirement-Preserving Human Approvals for Signed Agent Manifests

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/research.css b/research/research.css index abb3c47..90371b8 100644 --- a/research/research.css +++ b/research/research.css @@ -21,6 +21,9 @@ .paper-affiliation { font-size: 14px; color: var(--at-muted); margin: 0 0 18px; } .paper-status { display: flex; flex-wrap: wrap; gap: 10px 24px; color: var(--at-muted); font: 12px/1.6 var(--at-mono); } .paper-abstract { margin-top: 30px; max-width: 850px; } +.paper-plain { margin-top: 30px; max-width: 850px; } +.paper-plain h2 { font: 400 26px/1.3 var(--at-serif); margin: 0 0 16px; } +.paper-plain p { font-size: 17px; line-height: 1.8; } .paper-abstract h2, .research-section h2 { font: 400 26px/1.3 var(--at-serif); margin: 0 0 16px; } .paper-abstract p, .research-section p, .research-section li { font-size: 16px; line-height: 1.8; } .paper-actions { display: flex; flex-wrap: wrap; align-items: center; gap: 14px 24px; margin: 28px 0 40px; font-size: 14px; } diff --git a/research/telemetry-evidence-acceptance/index.html b/research/telemetry-evidence-acceptance/index.html index ae31081..969ec1c 100644 --- a/research/telemetry-evidence-acceptance/index.html +++ b/research/telemetry-evidence-acceptance/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Acceptance Before Export: A Bounded Evidence Contract for Governance Telemet

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewedPatent Pending
+

In plain English

Monitoring systems can lose events, so their records cannot prove that every governance event was kept. This report proposes recording each event as evidence at the source first, before it is sent to any monitoring system, so a failed export never means lost evidence. Tests confirm that separation and also show its limits: nothing guarantees an event is stored exactly once, and an empty record can still be declared complete.

Abstract

An operational telemetry backend can lose events through sampling, retention and exporter failures. Its observations therefore cannot, by themselves, establish complete governance evidence. We describe a source-side acceptance boundary in AgenTrust Telemetry: validate a metadata-constrained event, check context correlation, accept an isolated representation into a run-scoped cryptographic prefix, and only then attempt operational projections. In a durable configuration, an external callback must acknowledge persistence before the local prefix advances. Export failures remain distinct from evidence failures. We formalize the conditional ordering property and test its limits, including acknowledgment loss and an empty accumulator declared complete. At a pinned source revision, 111 Python tests and 13 portable conformance fixtures produced expected results on September 4 and again on September 27, 2026. Four additional probes demonstrate both the useful separation and the absence of automatic completeness or distributed exactly-once persistence. The contribution is a precise contract for acceptance before export, with explicit trust and recovery obligations, rather than a claim that a hash chain proves every event occurred.

What this report contributes

A source-side contract that accepts each governance event into a run-scoped cryptographic prefix before operational export, keeping export failures separate from evidence failures.

@@ -92,5 +93,5 @@

Acceptance Before Export: A Bounded Evidence Contract for Governance Telemet

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/telemetry-evidence-acceptance/v1/index.html b/research/telemetry-evidence-acceptance/v1/index.html index a9b8611..51e3978 100644 --- a/research/telemetry-evidence-acceptance/v1/index.html +++ b/research/telemetry-evidence-acceptance/v1/index.html @@ -24,7 +24,7 @@ - + @@ -92,5 +92,5 @@

Acceptance Before Export: A Bounded Evidence Contract for Governance Telemet

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/telemetry-evidence-acceptance/v2/index.html b/research/telemetry-evidence-acceptance/v2/index.html index 20ae0f9..edfa455 100644 --- a/research/telemetry-evidence-acceptance/v2/index.html +++ b/research/telemetry-evidence-acceptance/v2/index.html @@ -24,7 +24,7 @@ - + @@ -92,5 +92,5 @@

Acceptance Before Export: A Bounded Evidence Contract for Governance Telemet

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/telemetry-evidence-acceptance/v3/index.html b/research/telemetry-evidence-acceptance/v3/index.html index c7dc397..a2037a7 100644 --- a/research/telemetry-evidence-acceptance/v3/index.html +++ b/research/telemetry-evidence-acceptance/v3/index.html @@ -24,7 +24,7 @@ - + @@ -92,5 +92,5 @@

Acceptance Before Export: A Bounded Evidence Contract for Governance Telemet

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/trace/index.html b/research/trace/index.html index 08e4726..4f59170 100644 --- a/research/trace/index.html +++ b/research/trace/index.html @@ -26,7 +26,7 @@ - + @@ -69,6 +69,7 @@

TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attes

Rishabh Poddar, Aaron Fulkerson, Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewed
+

In plain English

When an AI agent runs, the people who rely on it often want proof of what it ran: which model, which policy, which tools it called. TRACE proposes one portable, signed record of those facts that anyone can check against their own rules. The report measures how quickly such records are signed and checked and how large they are, and states plainly that a signature alone does not prove the record came from trusted hardware or that its claims are true.

Abstract

TRACE (Trust, Runtime Attestation, and Compliance Evidence) proposes a portable record for claims about AI agent runtimes: workload identity, model, policy, data class, tool transcript, build provenance, and appraisal. It composes RATS/EAT, signatures, and transparency evidence into a format that a relying party can evaluate against its own trust policy. A valid signature establishes integrity and possession of the signing key; hardware origin additionally requires verified attestation and a binding from that evidence to the key. This technical report describes the original design and preserves the recorded software evaluation of agentrust-trace (trace-spec revision 523f8cc, whose signing code is release 0.3.0) and trace-tests 0.2.0. The evaluation measures canonicalization, Ed25519 signing and verification, record size, and fixture outcomes. It does not measure silicon certificate-chain appraisal or establish that the recorded runtime claims are true. The current normative specification and its implementation limits are maintained separately.

What this report contributes

A portable format for runtime claims, with recorded measurements of signing, verification, record size, and conformance fixtures.

@@ -94,5 +95,5 @@

TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attes

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/trace/v1/index.html b/research/trace/v1/index.html index 426a96a..86b4305 100644 --- a/research/trace/v1/index.html +++ b/research/trace/v1/index.html @@ -26,7 +26,7 @@ - + @@ -94,5 +94,5 @@

TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attes

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/trace/v2/index.html b/research/trace/v2/index.html index 61a2e21..ccc19a7 100644 --- a/research/trace/v2/index.html +++ b/research/trace/v2/index.html @@ -26,7 +26,7 @@ - + @@ -94,5 +94,5 @@

TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attes

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/trace/v3/index.html b/research/trace/v3/index.html index 80d6d03..3c43d24 100644 --- a/research/trace/v3/index.html +++ b/research/trace/v3/index.html @@ -26,7 +26,7 @@ - + @@ -94,5 +94,5 @@

TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attes

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/weight-custody-manifest/index.html b/research/weight-custody-manifest/index.html index 0f9cc77..e37178b 100644 --- a/research/weight-custody-manifest/index.html +++ b/research/weight-custody-manifest/index.html @@ -24,7 +24,7 @@ - + @@ -67,6 +67,7 @@

Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary

Imran Siddique

OPAQUE Systems

October 1, 2026Not peer reviewedPatent Pending
+

In plain English

When a company runs its private AI model on computers someone else controls, it needs a way to keep control of the model. WCM is an open protocol that releases the model's key only to approved, checked software, requires that permission to be renewed, and records evidence of deletion and of any models derived from it. The tested code passed all 91 shared conformance tests; the report also describes two flaws in that version (fixed later) and a missing hardware setting on the tested cloud machine without which the strongest protection does not hold.

Abstract

Deploying proprietary model weights into infrastructure controlled by a customer reverses the usual confidential-computing trust problem: the model builder, rather than the infrastructure owner, supplies the secret. Existing confidential-computing stacks can attest workloads and release secrets, while model-signing systems authenticate model artifacts. Neither capability alone specifies continuing custody of a particular weight artifact after release. This technical report describes the Weight Custody Manifest (WCM), a vendor-neutral protocol and conformance model that binds an exact weight digest, an approved workload measurement, attestation policy, a fresh transport key, renewable authorization, terminal refusal and wipe evidence, and derivative lineage. WCM distinguishes cryptographic custody against software adversaries from accountability-grade controls when the infrastructure operator physically owns the machine. The evaluated Python reference implementation, version 0.28.0, supplies 91 portable conformance vectors across four levels. Its test suite produced 618 passing tests and three skips on September 3, 2026, and the same counts when rerun at the same commit for this edition. Later findings bound those results. The evaluated key broker compared the approved workload measurement with an unsigned evidence field rather than the signed report, and did not require GPU confidential-compute mode before release; both are fixed in later releases. The SEV-SNP platform used for the hardware run does not enable the ciphertext hiding that the cryptographic-custody claim against a hypervisor-privileged operator requires. The contribution is a portable artifact-to-runtime custody contract with explicit lifecycle evidence, derivative accountability, and conformance, not a new attestation primitive or a certification of any deployment.

What this report contributes

A portable custody contract binding exact weights, measured workload, fresh channel-bound release, renewable authority, terminal evidence and derivative lineage.

@@ -91,5 +92,5 @@

Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/weight-custody-manifest/v1/index.html b/research/weight-custody-manifest/v1/index.html index fc8c025..18b0454 100644 --- a/research/weight-custody-manifest/v1/index.html +++ b/research/weight-custody-manifest/v1/index.html @@ -24,7 +24,7 @@ - + @@ -91,5 +91,5 @@

Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/research/weight-custody-manifest/v2/index.html b/research/weight-custody-manifest/v2/index.html index c416220..218584f 100644 --- a/research/weight-custody-manifest/v2/index.html +++ b/research/weight-custody-manifest/v2/index.html @@ -24,7 +24,7 @@ - + @@ -91,5 +91,5 @@

Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary

File checksums. Published version files are retained; substantive revisions receive a new version.

Questions and corrections

Open an issue in the project repository and identify the report version and section.

- + diff --git a/search/index.html b/search/index.html index d1141fd..9abb229 100644 --- a/search/index.html +++ b/search/index.html @@ -4,7 +4,7 @@ Search | AgenTrust - + @@ -12,7 +12,7 @@ - + @@ -23,7 +23,7 @@ - + @@ -32,7 +32,7 @@ - + @@ -76,7 +76,7 @@
Every AgenTrust site

Search

-

Matches the documentation of WCM, Agent Manifest, cMCP, cA2A, TRACE, the conformance suite and the governance list, plus the pages of this site. Each site's own search index is fetched when this page opens, so results match what is deployed.

+

Type a few words to search every AgenTrust site at once: the documentation for WCM, Agent Manifest, cMCP, cA2A, TRACE, the conformance suite and the governance list, plus the pages of this site. When this page opens it downloads each site's current search index, so results always match what is published. A result must contain every word you type.

- + diff --git a/telemetry/index.html b/telemetry/index.html index d64b205..b977a9e 100644 --- a/telemetry/index.html +++ b/telemetry/index.html @@ -4,7 +4,7 @@ Telemetry and Evidence Events for Agent Runtimes | AgenTrust - + @@ -12,7 +12,7 @@ - + @@ -23,7 +23,7 @@ - + @@ -67,7 +67,7 @@ ] } - + @@ -109,12 +109,12 @@
Between actions and evidence · Observe · Correlate

Portable telemetry and evidence
for AI-agent runtimes

-

Normalize the governance facts around an agent run: policy decisions, approvals, actions, classified data flow, usage, cost, and evidence, without replacing your OpenTelemetry stack, policy engine, framework, or UI.

+

AgenTrust Telemetry is an open record format, with code libraries for Python and TypeScript, for the oversight side of an AI agent run: which rule allowed or blocked an action, who approved it, what the agent did, where data went, and what it cost. Today those facts sit in separate logs and dashboards. This puts them in one consistent shape, alongside the monitoring tools you already run, without recording prompts or outputs by default.

Emit your first local event Explore the six event families
-
Alpha contract 0.1.0-alpha.4 · Python and TypeScript · MIT licensed
+
Alpha contract 0.1.0-alpha.6 · Python and TypeScript · MIT licensed