From d61fee8bfc9fa01f197158e7f8187d11997c6ad3 Mon Sep 17 00:00:00 2001
From: Imran Siddique <45405841+imran-siddique@users.noreply.github.com>
Date: Wed, 14 Oct 2026 22:13:08 -0700
Subject: [PATCH 1/2] docs: present AgenTrust as an independent project

Replace the OPAQUE sponsor block, footers and llms.txt line with the independent project statement, and record OPAQUE Systems as a past sponsor on the community page. Research pages now show AgenTrust as the affiliation, regenerated with tools/build-research.py. The LF announcement credits and partner evidence links are unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Imran Siddique <45405841+imran-siddique@users.noreply.github.com>
---
 community/index.html                          | 26 +++++++++----------
 data/adoption.json                            |  4 +--
 index.html                                    |  8 +++---
 llms.txt                                      |  2 +-
 quickstart/index.html                         |  2 +-
 registry/index.html                           |  2 +-
 research/agent-manifest/index.html            |  2 +-
 research/agent-manifest/v1/index.html         |  2 +-
 research/agent-manifest/v2/index.html         |  2 +-
 research/agentrust-telemetry/index.html       |  2 +-
 research/agentrust-telemetry/v1/index.html    |  2 +-
 research/agentrust-telemetry/v2/index.html    |  2 +-
 research/ca2a/index.html                      |  2 +-
 research/ca2a/v1/index.html                   |  2 +-
 research/ca2a/v2/index.html                   |  2 +-
 research/ca2a/v3/index.html                   |  2 +-
 .../challenge-bound-memory-sweep/index.html   |  2 +-
 .../v1/index.html                             |  2 +-
 research/cmcp/index.html                      |  2 +-
 research/cmcp/v1/index.html                   |  2 +-
 research/cmcp/v2/index.html                   |  2 +-
 research/confidential-handoffs/index.html     |  2 +-
 research/confidential-handoffs/v1/index.html  |  2 +-
 research/confidential-handoffs/v2/index.html  |  2 +-
 research/confidential-handoffs/v3/index.html  |  2 +-
 research/durable-shutdown-blocks/index.html   |  2 +-
 .../durable-shutdown-blocks/v1/index.html     |  2 +-
 research/exact-output-disclosure/index.html   |  2 +-
 .../exact-output-disclosure/v1/index.html     |  2 +-
 .../index.html                                |  2 +-
 .../v1/index.html                             |  2 +-
 research/kill-switch/index.html               |  2 +-
 research/kill-switch/v1/index.html            |  2 +-
 research/kill-switch/v2/index.html            |  2 +-
 .../model-key-broker-provisioning/index.html  |  2 +-
 .../v1/index.html                             |  2 +-
 .../receipt-gated-model-serving/index.html    |  2 +-
 .../receipt-gated-model-serving/v1/index.html |  2 +-
 .../index.html                                |  2 +-
 .../v1/index.html                             |  2 +-
 .../telemetry-evidence-acceptance/index.html  |  2 +-
 .../v1/index.html                             |  2 +-
 .../v2/index.html                             |  2 +-
 .../v3/index.html                             |  2 +-
 research/trace/index.html                     |  2 +-
 research/trace/v1/index.html                  |  2 +-
 research/trace/v2/index.html                  |  2 +-
 research/trace/v3/index.html                  |  2 +-
 research/weight-custody-manifest/index.html   |  2 +-
 .../weight-custody-manifest/v1/index.html     |  2 +-
 .../weight-custody-manifest/v2/index.html     |  2 +-
 search/index.html                             |  2 +-
 tools/build-research.py                       |  2 +-
 verify/index.html                             |  2 +-
 54 files changed, 70 insertions(+), 70 deletions(-)

diff --git a/community/index.html b/community/index.html
index 50f9e4d..4ce279a 100644
--- a/community/index.html
+++ b/community/index.html
@@ -3,8 +3,8 @@
 <head>
   <meta charset="UTF-8">
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
-  <title>Community: Partners, Sponsor and Contributors | AgenTrust</title>
-  <meta name="description" content="Who builds and supports AgenTrust: partners and the sponsor, each linked to public evidence, how the projects are run, and how to take part.">
+  <title>Community: Partners and Contributors | AgenTrust</title>
+  <meta name="description" content="Who builds and supports AgenTrust: partners and contributors, each linked to public evidence, how the projects are run, and how to take part.">
   <link rel="canonical" href="https://agentrust-io.com/community/">
   <meta name="robots" content="index, follow">
 
@@ -17,8 +17,8 @@
   <!-- Open Graph -->
   <meta property="og:type" content="website">
   <meta property="og:site_name" content="AgenTrust">
-  <meta property="og:title" content="Community: Partners, Sponsor and Contributors">
-  <meta property="og:description" content="Who builds and supports AgenTrust: partners and the sponsor, each linked to public evidence, how the projects are run, and how to take part.">
+  <meta property="og:title" content="Community: Partners and Contributors">
+  <meta property="og:description" content="Who builds and supports AgenTrust: partners and contributors, each linked to public evidence, how the projects are run, and how to take part.">
   <meta property="og:url" content="https://agentrust-io.com/community/">
   <meta property="og:locale" content="en_US">
   <meta property="og:image" content="https://agentrust-io.com/og.png">
@@ -28,8 +28,8 @@
 
   <!-- Twitter -->
   <meta name="twitter:card" content="summary_large_image">
-  <meta name="twitter:title" content="Community: Partners, Sponsor and Contributors">
-  <meta name="twitter:description" content="Who builds and supports AgenTrust: partners and the sponsor, each linked to public evidence, how the projects are run, and how to take part.">
+  <meta name="twitter:title" content="Community: Partners and Contributors">
+  <meta name="twitter:description" content="Who builds and supports AgenTrust: partners and contributors, each linked to public evidence, how the projects are run, and how to take part.">
   <meta name="twitter:image" content="https://agentrust-io.com/og.png">
 <script type="application/ld+json">
 {
@@ -39,8 +39,8 @@
       "@type": "AboutPage",
       "@id": "https://agentrust-io.com/community/#page",
       "url": "https://agentrust-io.com/community/",
-      "name": "Community: Partners, Sponsor and Contributors",
-      "description": "Who builds and supports AgenTrust: partners and the sponsor, each linked to public evidence, how the projects are run, and how to take part.",
+      "name": "Community: Partners and Contributors",
+      "description": "Who builds and supports AgenTrust: partners and contributors, each linked to public evidence, how the projects are run, and how to take part.",
       "isPartOf": {
         "@id": "https://agentrust-io.com/#website"
       },
@@ -61,7 +61,7 @@
         {
           "@type": "ListItem",
           "position": 2,
-          "name": "Community: Partners, Sponsor and Contributors",
+          "name": "Community: Partners and Contributors",
           "item": "https://agentrust-io.com/community/"
         }
       ]
@@ -159,8 +159,8 @@ <h2 class="section-title">Relationships the public record supports</h2>
   <div class="adoption-grid">
     <article class="adoption-card">
       <div class="adopter-mark opaque-mark"><img src="/assets/opaque-logo.svg" alt="OPAQUE Systems" loading="lazy"></div>
-      <div class="adopter-stage">Sponsor</div>
-      <p>OPAQUE funds the engineering, infrastructure and confidential-computing work behind AgenTrust, and contributes to the projects.</p>
+      <div class="adopter-stage">Past sponsor</div>
+      <p>OPAQUE Systems sponsored early development until October 2026.</p>
       <a class="evidence-link" href="https://github.com/agentrust-io">Review the public project record ↗</a>
     </article>
     <article class="adoption-card">
@@ -228,8 +228,8 @@ <h2 class="section-title">Relationships the public record supports</h2>
   <aside class="adoption-contact" aria-labelledby="adoption-contact-title">
     <div>
       <div class="partner-kicker">Join the ecosystem</div>
-      <h3 id="adoption-contact-title">Building with, sponsoring, or supporting AgenTrust?</h3>
-      <p>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.</p>
+      <h3 id="adoption-contact-title">Building with or supporting AgenTrust?</h3>
+      <p>Tell us what you are building, connecting or contributing, or how you would like to partner. AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary. We describe every relationship exactly and link it to public evidence where there is some.</p>
     </div>
     <a class="btn btn-primary" href="https://github.com/orgs/agentrust-io/discussions">Start a discussion →</a>
   </aside>
diff --git a/data/adoption.json b/data/adoption.json
index 4ddf107..0c4708b 100644
--- a/data/adoption.json
+++ b/data/adoption.json
@@ -15,8 +15,8 @@
       "name": "OPAQUE Systems",
       "logo": "/assets/opaque-logo.svg",
       "markClass": "opaque-mark",
-      "label": "Sponsor",
-      "description": "OPAQUE funds the engineering, infrastructure and confidential-computing work behind AgenTrust, and contributes to the projects.",
+      "label": "Past sponsor",
+      "description": "OPAQUE Systems sponsored early development until October 2026.",
       "evidenceUrl": "https://github.com/agentrust-io",
       "evidenceLabel": "Review the public project record"
     },
diff --git a/index.html b/index.html
index ba496b8..0c457d4 100644
--- a/index.html
+++ b/index.html
@@ -379,10 +379,10 @@ <h2 class="section-title">Anyone can read it, run it and check it.</h2>
   </article>
   <div class="partner-grid">
     <article class="adoption-card">
-      <div class="adopter-mark opaque-mark"><img src="/assets/opaque-logo.svg" alt="OPAQUE" loading="lazy"></div>
-      <div class="adopter-stage">Sponsor</div>
-      <p><strong>Sponsored by OPAQUE</strong>, which funds the engineering, infrastructure and confidential-computing work behind these projects. Organisations that want to support open, verifiable AI infrastructure are welcome to join as sponsors.</p>
-      <a class="evidence-link" href="/community/#adoption-contact-title">Talk to us about sponsoring →</a>
+      <div class="adopter-stage">Independent project</div>
+      <p><strong>AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary.</strong></p>
+      <p>OPAQUE Systems sponsored early development until October 2026.</p>
+      <a class="evidence-link" href="/community/#community">How the projects are run →</a>
     </article>
     <article class="adoption-card">
       <div class="qa">
diff --git a/llms.txt b/llms.txt
index c973d49..eff4c3a 100644
--- a/llms.txt
+++ b/llms.txt
@@ -40,7 +40,7 @@ AgenTrust lives at https://agentrust-io.com, with its source code in the GitHub
 
 ## Community and stewardship
 
-- [Community, partners and sponsor](https://agentrust-io.com/community/#adoption): Published roles and partner relationships, each linked to public evidence. OPAQUE sponsors the work. The NSF submission is in review, not an award.
+- [Community, partners and contributors](https://agentrust-io.com/community/#adoption): Published roles and partner relationships, each linked to public evidence. AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary. The NSF submission is in review, not an award.
 - [Architecting at Scale](https://agentrust-io.com/community/#book): The field guide and its public companion code.
 
 ## More documentation
diff --git a/quickstart/index.html b/quickstart/index.html
index 7302746..967efeb 100644
--- a/quickstart/index.html
+++ b/quickstart/index.html
@@ -183,7 +183,7 @@ <h2>Check real hardware evidence first</h2>
       <a href="/demos/">Demos</a>
       <a href="https://github.com/agentrust-io">GitHub</a>
     </div>
-    <div class="credit"><b>Sponsored by OPAQUE</b>, which funds the engineering, infrastructure and confidential-computing work behind these projects.</div>
+    <div class="credit">AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary.</div>
   </div>
   <div class="foot-legal">© 2026 AgenTrust Contributors · agentrust-io.com</div>
 </div></footer>
diff --git a/registry/index.html b/registry/index.html
index a0b16bf..7e37983 100644
--- a/registry/index.html
+++ b/registry/index.html
@@ -337,7 +337,7 @@ <h2>Three ways in</h2>
       <a href="/demos/">Demos</a>
       <a href="https://github.com/agentrust-io">GitHub</a>
     </div>
-    <div class="credit"><b>Sponsored by OPAQUE</b>, which funds the engineering, infrastructure and confidential-computing work behind these projects.</div>
+    <div class="credit">AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary.</div>
   </div>
   <div class="foot-legal">© 2026 AgenTrust Contributors · agentrust-io.com</div>
 </div></footer>
diff --git a/research/agent-manifest/index.html b/research/agent-manifest/index.html
index 3ee9c85..e162bb8 100644
--- a/research/agent-manifest/index.html
+++ b/research/agent-manifest/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Agent Manifest</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/agent-manifest/v1/index.html b/research/agent-manifest/v1/index.html
index 32d0923..a14d1b4 100644
--- a/research/agent-manifest/v1/index.html
+++ b/research/agent-manifest/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Agent Manifest / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>Agent Manifest proposes a signed record of the artifacts that define an AI agent, including its system prompt, model, policy, tools, retrieval corpus, memory, decision trace, delegation, supply chain, and human approvals. Artifact digests and canonical serialization make changes to the recorded baseline detectable when a verifier has the relevant artifacts and trusted keys. The design composes SPIFFE identities, RFC 8785 canonicalization, Ed25519 signatures, an optional ML-DSA-65 profile, and hardware-attestation bindings. This technical report describes the original model and preserves the recorded Ed25519 software benchmarks, delegation checks, and tamper probes. Signed metadata alone does not prove that the recorded configuration was used during execution. The evaluation does not measure post-quantum performance or establish live hardware provenance; continuous verification of mutable memory and retrieval state is outside its scope. Current SDK behavior and normative requirements are maintained separately.</p></section>
diff --git a/research/agent-manifest/v2/index.html b/research/agent-manifest/v2/index.html
index ef08b4a..d904fe2 100644
--- a/research/agent-manifest/v2/index.html
+++ b/research/agent-manifest/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Agent Manifest / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>Agent Manifest proposes a signed record of the artifacts that define an AI agent, including its system prompt, model, policy, tools, retrieval corpus, memory, decision trace, delegation, supply chain, and human approvals. Artifact digests and canonical serialization make changes to the recorded baseline detectable when a verifier has the relevant artifacts and trusted keys. The design composes SPIFFE identities, RFC 8785 canonicalization, Ed25519 signatures, an optional ML-DSA-65 profile, and hardware-attestation bindings. This technical report describes the original model and preserves the recorded Ed25519 software benchmarks, delegation checks, and tamper probes. Signed metadata alone does not prove that the recorded configuration was used during execution. The evaluation does not measure post-quantum performance or establish live hardware provenance; continuous verification of mutable memory and retrieval state is outside its scope. Current SDK behavior and normative requirements are maintained separately.</p></section>
diff --git a/research/agentrust-telemetry/index.html b/research/agentrust-telemetry/index.html
index 904e235..744866f 100644
--- a/research/agentrust-telemetry/index.html
+++ b/research/agentrust-telemetry/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / AgenTrust Telemetry</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/agentrust-telemetry/v1/index.html b/research/agentrust-telemetry/v1/index.html
index 6a1d340..f8b2baa 100644
--- a/research/agentrust-telemetry/v1/index.html
+++ b/research/agentrust-telemetry/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / AgenTrust Telemetry / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/agentrust-telemetry/v2/index.html b/research/agentrust-telemetry/v2/index.html
index 80777eb..8dbf1ae 100644
--- a/research/agentrust-telemetry/v2/index.html
+++ b/research/agentrust-telemetry/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / AgenTrust Telemetry / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/ca2a/index.html b/research/ca2a/index.html
index ea9fd0d..dc929fc 100644
--- a/research/ca2a/index.html
+++ b/research/ca2a/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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&#x27;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.</p></section>
diff --git a/research/ca2a/v1/index.html b/research/ca2a/v1/index.html
index cdf588b..5cdcb65 100644
--- a/research/ca2a/v1/index.html
+++ b/research/ca2a/v1/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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&#x27;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&#x27;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.</p></section>
diff --git a/research/ca2a/v2/index.html b/research/ca2a/v2/index.html
index 52174b6..6d56f7d 100644
--- a/research/ca2a/v2/index.html
+++ b/research/ca2a/v2/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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&#x27;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&#x27;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.</p></section>
diff --git a/research/ca2a/v3/index.html b/research/ca2a/v3/index.html
index b32a589..43c41c0 100644
--- a/research/ca2a/v3/index.html
+++ b/research/ca2a/v3/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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&#x27;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&#x27;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.</p></section>
diff --git a/research/challenge-bound-memory-sweep/index.html b/research/challenge-bound-memory-sweep/index.html
index 8a069e9..19d0631 100644
--- a/research/challenge-bound-memory-sweep/index.html
+++ b/research/challenge-bound-memory-sweep/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Memory-Consistency Predicate</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>A Challenge-Bound Memory-Consistency Predicate for Model-Key Release</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>Before a model&#x27;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.</p></section>
diff --git a/research/challenge-bound-memory-sweep/v1/index.html b/research/challenge-bound-memory-sweep/v1/index.html
index debb109..d838ed2 100644
--- a/research/challenge-bound-memory-sweep/v1/index.html
+++ b/research/challenge-bound-memory-sweep/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Memory-Consistency Predicate / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>A Challenge-Bound Memory-Consistency Predicate for Model-Key Release</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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.</p></section>
diff --git a/research/cmcp/index.html b/research/cmcp/index.html
index d2ae3c0..7c0f88a 100644
--- a/research/cmcp/index.html
+++ b/research/cmcp/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cMCP</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/cmcp/v1/index.html b/research/cmcp/v1/index.html
index 914f2e7..83f3887 100644
--- a/research/cmcp/v1/index.html
+++ b/research/cmcp/v1/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cMCP / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/cmcp/v2/index.html b/research/cmcp/v2/index.html
index a97d006..91a752f 100644
--- a/research/cmcp/v2/index.html
+++ b/research/cmcp/v2/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cMCP / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/confidential-handoffs/index.html b/research/confidential-handoffs/index.html
index 105a72a..317796e 100644
--- a/research/confidential-handoffs/index.html
+++ b/research/confidential-handoffs/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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&#x27;s AgenTrust components do not yet deliver the full guarantee.</p></section>
diff --git a/research/confidential-handoffs/v1/index.html b/research/confidential-handoffs/v1/index.html
index 8ca2f4b..ec95c12 100644
--- a/research/confidential-handoffs/v1/index.html
+++ b/research/confidential-handoffs/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/confidential-handoffs/v2/index.html b/research/confidential-handoffs/v2/index.html
index 68e103e..3d2eecf 100644
--- a/research/confidential-handoffs/v2/index.html
+++ b/research/confidential-handoffs/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 30, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/confidential-handoffs/v3/index.html b/research/confidential-handoffs/v3/index.html
index 8ca5851..9957b91 100644
--- a/research/confidential-handoffs/v3/index.html
+++ b/research/confidential-handoffs/v3/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/durable-shutdown-blocks/index.html b/research/durable-shutdown-blocks/index.html
index 52f20e3..7d0a172 100644
--- a/research/durable-shutdown-blocks/index.html
+++ b/research/durable-shutdown-blocks/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Kill Switch Trips</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>When an operator presses an AI agent&#x27;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.</p></section>
diff --git a/research/durable-shutdown-blocks/v1/index.html b/research/durable-shutdown-blocks/v1/index.html
index 13f2fc3..99c47b6 100644
--- a/research/durable-shutdown-blocks/v1/index.html
+++ b/research/durable-shutdown-blocks/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Kill Switch Trips / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/exact-output-disclosure/index.html b/research/exact-output-disclosure/index.html
index b8b3312..9dd7652 100644
--- a/research/exact-output-disclosure/index.html
+++ b/research/exact-output-disclosure/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Exact-Output Disclosure</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>An answer an AI agent writes from confidential data still carries that data&#x27;s restrictions. This report describes a release step in which the data&#x27;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.</p></section>
diff --git a/research/exact-output-disclosure/v1/index.html b/research/exact-output-disclosure/v1/index.html
index 9a8b6fe..c0acc64 100644
--- a/research/exact-output-disclosure/v1/index.html
+++ b/research/exact-output-disclosure/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Exact-Output Disclosure / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>An answer an agent writes from a confidential record keeps the record&#x27;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&#x27;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.</p></section>
diff --git a/research/handoff-response-authentication/index.html b/research/handoff-response-authentication/index.html
index fa11717..5f70f62 100644
--- a/research/handoff-response-authentication/index.html
+++ b/research/handoff-response-authentication/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Handoff Response Authentication</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/handoff-response-authentication/v1/index.html b/research/handoff-response-authentication/v1/index.html
index 408d397..350914d 100644
--- a/research/handoff-response-authentication/v1/index.html
+++ b/research/handoff-response-authentication/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Handoff Response Authentication / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/kill-switch/index.html b/research/kill-switch/index.html
index 09f6a8f..bdf28cf 100644
--- a/research/kill-switch/index.html
+++ b/research/kill-switch/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / What a Kill Switch Proves</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an agent tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 11, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/kill-switch/v1/index.html b/research/kill-switch/v1/index.html
index 91dd867..fd96357 100644
--- a/research/kill-switch/v1/index.html
+++ b/research/kill-switch/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / What a Kill Switch Proves / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an agent tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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. An external evaluator repeated the reference run, both weakenings and both component suites on his own workstation and obtained the same outcome for every assertion. 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.</p></section>
diff --git a/research/kill-switch/v2/index.html b/research/kill-switch/v2/index.html
index 237c104..683d720 100644
--- a/research/kill-switch/v2/index.html
+++ b/research/kill-switch/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / What a Kill Switch Proves / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an agent tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 11, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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. An external evaluator repeated the reference run, both weakenings and both component suites on his own workstation and obtained the same outcome for every assertion. 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.</p></section>
diff --git a/research/model-key-broker-provisioning/index.html b/research/model-key-broker-provisioning/index.html
index df3faee..b5eba31 100644
--- a/research/model-key-broker-provisioning/index.html
+++ b/research/model-key-broker-provisioning/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Model-Key Broker Provisioning</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Owner-Approved Provisioning of a Model-Key Broker: Binding the broker&#x27;s configuration, receiving key and policy epoch before the model key leaves the owner</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>A model owner can require checks before a key service releases the model&#x27;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&#x27;s own records must be protected against rollback.</p></section>
diff --git a/research/model-key-broker-provisioning/v1/index.html b/research/model-key-broker-provisioning/v1/index.html
index 0c22354..ef67859 100644
--- a/research/model-key-broker-provisioning/v1/index.html
+++ b/research/model-key-broker-provisioning/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Model-Key Broker Provisioning / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Owner-Approved Provisioning of a Model-Key Broker: Binding the broker&#x27;s configuration, receiving key and policy epoch before the model key leaves the owner</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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.</p></section>
diff --git a/research/receipt-gated-model-serving/index.html b/research/receipt-gated-model-serving/index.html
index 65ec0d9..d969b86 100644
--- a/research/receipt-gated-model-serving/index.html
+++ b/research/receipt-gated-model-serving/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Receipt-Gated Model Serving</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/receipt-gated-model-serving/v1/index.html b/research/receipt-gated-model-serving/v1/index.html
index 04a5a9d..51642dc 100644
--- a/research/receipt-gated-model-serving/v1/index.html
+++ b/research/receipt-gated-model-serving/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Receipt-Gated Model Serving / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/requirement-preserving-human-approval/index.html b/research/requirement-preserving-human-approval/index.html
index 82fb0f0..efbd5fd 100644
--- a/research/requirement-preserving-human-approval/index.html
+++ b/research/requirement-preserving-human-approval/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Human Approvals</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Requirement-Preserving Human Approvals for Signed Agent Manifests</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/requirement-preserving-human-approval/v1/index.html b/research/requirement-preserving-human-approval/v1/index.html
index e86a346..0e86326 100644
--- a/research/requirement-preserving-human-approval/v1/index.html
+++ b/research/requirement-preserving-human-approval/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Human Approvals / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Requirement-Preserving Human Approvals for Signed Agent Manifests</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/index.html b/research/telemetry-evidence-acceptance/index.html
index 969ec1c..1cba3ac 100644
--- a/research/telemetry-evidence-acceptance/index.html
+++ b/research/telemetry-evidence-acceptance/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/v1/index.html b/research/telemetry-evidence-acceptance/v1/index.html
index 51e3978..910e7eb 100644
--- a/research/telemetry-evidence-acceptance/v1/index.html
+++ b/research/telemetry-evidence-acceptance/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/v2/index.html b/research/telemetry-evidence-acceptance/v2/index.html
index edfa455..ddaeb46 100644
--- a/research/telemetry-evidence-acceptance/v2/index.html
+++ b/research/telemetry-evidence-acceptance/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 30, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/v3/index.html b/research/telemetry-evidence-acceptance/v3/index.html
index a2037a7..7e98c71 100644
--- a/research/telemetry-evidence-acceptance/v3/index.html
+++ b/research/telemetry-evidence-acceptance/v3/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/trace/index.html b/research/trace/index.html
index 4f59170..a0eb9f0 100644
--- a/research/trace/index.html
+++ b/research/trace/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/trace/v1/index.html b/research/trace/v1/index.html
index 86b4305..fdef26a 100644
--- a/research/trace/v1/index.html
+++ b/research/trace/v1/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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 0.2.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.</p></section>
diff --git a/research/trace/v2/index.html b/research/trace/v2/index.html
index ccc19a7..a7be596 100644
--- a/research/trace/v2/index.html
+++ b/research/trace/v2/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 28, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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 0.2.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.</p></section>
diff --git a/research/trace/v3/index.html b/research/trace/v3/index.html
index 3c43d24..402a115 100644
--- a/research/trace/v3/index.html
+++ b/research/trace/v3/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/weight-custody-manifest/index.html b/research/weight-custody-manifest/index.html
index e37178b..ef35e19 100644
--- a/research/weight-custody-manifest/index.html
+++ b/research/weight-custody-manifest/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Weight Custody Manifest</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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&#x27;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.</p></section>
diff --git a/research/weight-custody-manifest/v1/index.html b/research/weight-custody-manifest/v1/index.html
index 18b0454..0c88bc7 100644
--- a/research/weight-custody-manifest/v1/index.html
+++ b/research/weight-custody-manifest/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Weight Custody Manifest / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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. Two later findings bound those results: a published advisory showed that the evaluated key broker did not require GPU confidential-compute mode before release, and 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.</p></section>
diff --git a/research/weight-custody-manifest/v2/index.html b/research/weight-custody-manifest/v2/index.html
index 218584f..cd5a9a6 100644
--- a/research/weight-custody-manifest/v2/index.html
+++ b/research/weight-custody-manifest/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Weight Custody Manifest / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/search/index.html b/search/index.html
index 9abb229..0e03c13 100644
--- a/search/index.html
+++ b/search/index.html
@@ -120,7 +120,7 @@ <h1>Search</h1>
       <a href="/demos/">Demos</a>
       <a href="https://github.com/agentrust-io">GitHub</a>
     </div>
-    <div class="credit"><b>Sponsored by OPAQUE</b>, which funds the engineering, infrastructure and confidential-computing work behind these projects.</div>
+    <div class="credit">AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary.</div>
   </div>
   <div class="foot-legal">© 2026 AgenTrust Contributors · agentrust-io.com</div>
 </div></footer>
diff --git a/tools/build-research.py b/tools/build-research.py
index b383098..0f4bfc3 100644
--- a/tools/build-research.py
+++ b/tools/build-research.py
@@ -128,7 +128,7 @@ def paper_page(p, v=None):
     body=f'''<nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / {esc(q['short_title'])}{f' / Version {n}' if v else ''}</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version {n}</p>
 <h1>{esc(q['title'])}</h1>
-<p class="paper-authors">{esc(', '.join(q['authors']))}</p><p class="paper-affiliation">OPAQUE Systems</p>
+<p class="paper-authors">{esc(', '.join(q['authors']))}</p><p class="paper-affiliation">AgenTrust</p>
 <div class="paper-status"><span>{human_date(q['date'])}</span><span>Not peer reviewed</span>{patent}</div>
 </header>
 {plain}<section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>{esc(q['abstract'])}</p></section>
diff --git a/verify/index.html b/verify/index.html
index 7088231..f803630 100644
--- a/verify/index.html
+++ b/verify/index.html
@@ -222,7 +222,7 @@ <h2>A port, held to its original</h2>
       <a href="/quickstart/">Get started</a>
       <a href="https://github.com/agentrust-io">GitHub</a>
     </div>
-    <div class="credit"><b>Sponsored by OPAQUE</b>, which funds the engineering, infrastructure and confidential-computing work behind these projects.</div>
+    <div class="credit">AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary.</div>
   </div>
   <div class="foot-legal">© 2026 AgenTrust Contributors · agentrust-io.com</div>
 </div></footer>

From 542436ab52a5f17a108318b6c32bbdfd80707597 Mon Sep 17 00:00:00 2001
From: Imran Siddique <45405841+imran-siddique@users.noreply.github.com>
Date: Thu, 15 Oct 2026 09:59:10 -0700
Subject: [PATCH 2/2] docs: keep OPAQUE Systems as the affiliation on published
 papers

The research pages mirror archived technical reports whose PDFs and Zenodo records name OPAQUE Systems. Changing the page affiliation made the site disagree with the paper of record. Raised by rajnisht7.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Imran Siddique <45405841+imran-siddique@users.noreply.github.com>
---
 research/agent-manifest/index.html                           | 2 +-
 research/agent-manifest/v1/index.html                        | 2 +-
 research/agent-manifest/v2/index.html                        | 2 +-
 research/agentrust-telemetry/index.html                      | 2 +-
 research/agentrust-telemetry/v1/index.html                   | 2 +-
 research/agentrust-telemetry/v2/index.html                   | 2 +-
 research/ca2a/index.html                                     | 2 +-
 research/ca2a/v1/index.html                                  | 2 +-
 research/ca2a/v2/index.html                                  | 2 +-
 research/ca2a/v3/index.html                                  | 2 +-
 research/challenge-bound-memory-sweep/index.html             | 2 +-
 research/challenge-bound-memory-sweep/v1/index.html          | 2 +-
 research/cmcp/index.html                                     | 2 +-
 research/cmcp/v1/index.html                                  | 2 +-
 research/cmcp/v2/index.html                                  | 2 +-
 research/confidential-handoffs/index.html                    | 2 +-
 research/confidential-handoffs/v1/index.html                 | 2 +-
 research/confidential-handoffs/v2/index.html                 | 2 +-
 research/confidential-handoffs/v3/index.html                 | 2 +-
 research/durable-shutdown-blocks/index.html                  | 2 +-
 research/durable-shutdown-blocks/v1/index.html               | 2 +-
 research/exact-output-disclosure/index.html                  | 2 +-
 research/exact-output-disclosure/v1/index.html               | 2 +-
 research/handoff-response-authentication/index.html          | 2 +-
 research/handoff-response-authentication/v1/index.html       | 2 +-
 research/kill-switch/index.html                              | 2 +-
 research/kill-switch/v1/index.html                           | 2 +-
 research/kill-switch/v2/index.html                           | 2 +-
 research/model-key-broker-provisioning/index.html            | 2 +-
 research/model-key-broker-provisioning/v1/index.html         | 2 +-
 research/receipt-gated-model-serving/index.html              | 2 +-
 research/receipt-gated-model-serving/v1/index.html           | 2 +-
 research/requirement-preserving-human-approval/index.html    | 2 +-
 research/requirement-preserving-human-approval/v1/index.html | 2 +-
 research/telemetry-evidence-acceptance/index.html            | 2 +-
 research/telemetry-evidence-acceptance/v1/index.html         | 2 +-
 research/telemetry-evidence-acceptance/v2/index.html         | 2 +-
 research/telemetry-evidence-acceptance/v3/index.html         | 2 +-
 research/trace/index.html                                    | 2 +-
 research/trace/v1/index.html                                 | 2 +-
 research/trace/v2/index.html                                 | 2 +-
 research/trace/v3/index.html                                 | 2 +-
 research/weight-custody-manifest/index.html                  | 2 +-
 research/weight-custody-manifest/v1/index.html               | 2 +-
 research/weight-custody-manifest/v2/index.html               | 2 +-
 tools/build-research.py                                      | 2 +-
 46 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/research/agent-manifest/index.html b/research/agent-manifest/index.html
index e162bb8..3ee9c85 100644
--- a/research/agent-manifest/index.html
+++ b/research/agent-manifest/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Agent Manifest</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/agent-manifest/v1/index.html b/research/agent-manifest/v1/index.html
index a14d1b4..32d0923 100644
--- a/research/agent-manifest/v1/index.html
+++ b/research/agent-manifest/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Agent Manifest / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>Agent Manifest proposes a signed record of the artifacts that define an AI agent, including its system prompt, model, policy, tools, retrieval corpus, memory, decision trace, delegation, supply chain, and human approvals. Artifact digests and canonical serialization make changes to the recorded baseline detectable when a verifier has the relevant artifacts and trusted keys. The design composes SPIFFE identities, RFC 8785 canonicalization, Ed25519 signatures, an optional ML-DSA-65 profile, and hardware-attestation bindings. This technical report describes the original model and preserves the recorded Ed25519 software benchmarks, delegation checks, and tamper probes. Signed metadata alone does not prove that the recorded configuration was used during execution. The evaluation does not measure post-quantum performance or establish live hardware provenance; continuous verification of mutable memory and retrieval state is outside its scope. Current SDK behavior and normative requirements are maintained separately.</p></section>
diff --git a/research/agent-manifest/v2/index.html b/research/agent-manifest/v2/index.html
index d904fe2..ef08b4a 100644
--- a/research/agent-manifest/v2/index.html
+++ b/research/agent-manifest/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Agent Manifest / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>Agent Manifest proposes a signed record of the artifacts that define an AI agent, including its system prompt, model, policy, tools, retrieval corpus, memory, decision trace, delegation, supply chain, and human approvals. Artifact digests and canonical serialization make changes to the recorded baseline detectable when a verifier has the relevant artifacts and trusted keys. The design composes SPIFFE identities, RFC 8785 canonicalization, Ed25519 signatures, an optional ML-DSA-65 profile, and hardware-attestation bindings. This technical report describes the original model and preserves the recorded Ed25519 software benchmarks, delegation checks, and tamper probes. Signed metadata alone does not prove that the recorded configuration was used during execution. The evaluation does not measure post-quantum performance or establish live hardware provenance; continuous verification of mutable memory and retrieval state is outside its scope. Current SDK behavior and normative requirements are maintained separately.</p></section>
diff --git a/research/agentrust-telemetry/index.html b/research/agentrust-telemetry/index.html
index 744866f..904e235 100644
--- a/research/agentrust-telemetry/index.html
+++ b/research/agentrust-telemetry/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / AgenTrust Telemetry</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/agentrust-telemetry/v1/index.html b/research/agentrust-telemetry/v1/index.html
index f8b2baa..6a1d340 100644
--- a/research/agentrust-telemetry/v1/index.html
+++ b/research/agentrust-telemetry/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / AgenTrust Telemetry / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/agentrust-telemetry/v2/index.html b/research/agentrust-telemetry/v2/index.html
index 8dbf1ae..80777eb 100644
--- a/research/agentrust-telemetry/v2/index.html
+++ b/research/agentrust-telemetry/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / AgenTrust Telemetry / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/ca2a/index.html b/research/ca2a/index.html
index dc929fc..ea9fd0d 100644
--- a/research/ca2a/index.html
+++ b/research/ca2a/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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&#x27;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.</p></section>
diff --git a/research/ca2a/v1/index.html b/research/ca2a/v1/index.html
index 5cdcb65..cdf588b 100644
--- a/research/ca2a/v1/index.html
+++ b/research/ca2a/v1/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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&#x27;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&#x27;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.</p></section>
diff --git a/research/ca2a/v2/index.html b/research/ca2a/v2/index.html
index 6d56f7d..52174b6 100644
--- a/research/ca2a/v2/index.html
+++ b/research/ca2a/v2/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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&#x27;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&#x27;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.</p></section>
diff --git a/research/ca2a/v3/index.html b/research/ca2a/v3/index.html
index 43c41c0..b32a589 100644
--- a/research/ca2a/v3/index.html
+++ b/research/ca2a/v3/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cA2A / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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&#x27;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&#x27;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.</p></section>
diff --git a/research/challenge-bound-memory-sweep/index.html b/research/challenge-bound-memory-sweep/index.html
index 19d0631..8a069e9 100644
--- a/research/challenge-bound-memory-sweep/index.html
+++ b/research/challenge-bound-memory-sweep/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Memory-Consistency Predicate</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>A Challenge-Bound Memory-Consistency Predicate for Model-Key Release</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>Before a model&#x27;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.</p></section>
diff --git a/research/challenge-bound-memory-sweep/v1/index.html b/research/challenge-bound-memory-sweep/v1/index.html
index d838ed2..debb109 100644
--- a/research/challenge-bound-memory-sweep/v1/index.html
+++ b/research/challenge-bound-memory-sweep/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Memory-Consistency Predicate / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>A Challenge-Bound Memory-Consistency Predicate for Model-Key Release</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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.</p></section>
diff --git a/research/cmcp/index.html b/research/cmcp/index.html
index 7c0f88a..d2ae3c0 100644
--- a/research/cmcp/index.html
+++ b/research/cmcp/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cMCP</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/cmcp/v1/index.html b/research/cmcp/v1/index.html
index 83f3887..914f2e7 100644
--- a/research/cmcp/v1/index.html
+++ b/research/cmcp/v1/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cMCP / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/cmcp/v2/index.html b/research/cmcp/v2/index.html
index 91a752f..a97d006 100644
--- a/research/cmcp/v2/index.html
+++ b/research/cmcp/v2/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / cMCP / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/confidential-handoffs/index.html b/research/confidential-handoffs/index.html
index 317796e..105a72a 100644
--- a/research/confidential-handoffs/index.html
+++ b/research/confidential-handoffs/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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&#x27;s AgenTrust components do not yet deliver the full guarantee.</p></section>
diff --git a/research/confidential-handoffs/v1/index.html b/research/confidential-handoffs/v1/index.html
index ec95c12..8ca2f4b 100644
--- a/research/confidential-handoffs/v1/index.html
+++ b/research/confidential-handoffs/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/confidential-handoffs/v2/index.html b/research/confidential-handoffs/v2/index.html
index 3d2eecf..68e103e 100644
--- a/research/confidential-handoffs/v2/index.html
+++ b/research/confidential-handoffs/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 30, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/confidential-handoffs/v3/index.html b/research/confidential-handoffs/v3/index.html
index 9957b91..8ca5851 100644
--- a/research/confidential-handoffs/v3/index.html
+++ b/research/confidential-handoffs/v3/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Confidential Handoffs / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/durable-shutdown-blocks/index.html b/research/durable-shutdown-blocks/index.html
index 7d0a172..52f20e3 100644
--- a/research/durable-shutdown-blocks/index.html
+++ b/research/durable-shutdown-blocks/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Kill Switch Trips</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>When an operator presses an AI agent&#x27;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.</p></section>
diff --git a/research/durable-shutdown-blocks/v1/index.html b/research/durable-shutdown-blocks/v1/index.html
index 99c47b6..13f2fc3 100644
--- a/research/durable-shutdown-blocks/v1/index.html
+++ b/research/durable-shutdown-blocks/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Kill Switch Trips / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/exact-output-disclosure/index.html b/research/exact-output-disclosure/index.html
index 9dd7652..b8b3312 100644
--- a/research/exact-output-disclosure/index.html
+++ b/research/exact-output-disclosure/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Exact-Output Disclosure</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>An answer an AI agent writes from confidential data still carries that data&#x27;s restrictions. This report describes a release step in which the data&#x27;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.</p></section>
diff --git a/research/exact-output-disclosure/v1/index.html b/research/exact-output-disclosure/v1/index.html
index c0acc64..9a8b6fe 100644
--- a/research/exact-output-disclosure/v1/index.html
+++ b/research/exact-output-disclosure/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Exact-Output Disclosure / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>An answer an agent writes from a confidential record keeps the record&#x27;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&#x27;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.</p></section>
diff --git a/research/handoff-response-authentication/index.html b/research/handoff-response-authentication/index.html
index 5f70f62..fa11717 100644
--- a/research/handoff-response-authentication/index.html
+++ b/research/handoff-response-authentication/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Handoff Response Authentication</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/handoff-response-authentication/v1/index.html b/research/handoff-response-authentication/v1/index.html
index 350914d..408d397 100644
--- a/research/handoff-response-authentication/v1/index.html
+++ b/research/handoff-response-authentication/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Handoff Response Authentication / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/kill-switch/index.html b/research/kill-switch/index.html
index bdf28cf..09f6a8f 100644
--- a/research/kill-switch/index.html
+++ b/research/kill-switch/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / What a Kill Switch Proves</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an agent tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 11, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/kill-switch/v1/index.html b/research/kill-switch/v1/index.html
index fd96357..91dd867 100644
--- a/research/kill-switch/v1/index.html
+++ b/research/kill-switch/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / What a Kill Switch Proves / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an agent tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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. An external evaluator repeated the reference run, both weakenings and both component suites on his own workstation and obtained the same outcome for every assertion. 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.</p></section>
diff --git a/research/kill-switch/v2/index.html b/research/kill-switch/v2/index.html
index 683d720..237c104 100644
--- a/research/kill-switch/v2/index.html
+++ b/research/kill-switch/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / What a Kill Switch Proves / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>What Does an AI Kill Switch Prove? Evidence and limits of shutdown at an agent tool gateway</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 11, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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. An external evaluator repeated the reference run, both weakenings and both component suites on his own workstation and obtained the same outcome for every assertion. 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.</p></section>
diff --git a/research/model-key-broker-provisioning/index.html b/research/model-key-broker-provisioning/index.html
index b5eba31..df3faee 100644
--- a/research/model-key-broker-provisioning/index.html
+++ b/research/model-key-broker-provisioning/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Model-Key Broker Provisioning</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Owner-Approved Provisioning of a Model-Key Broker: Binding the broker&#x27;s configuration, receiving key and policy epoch before the model key leaves the owner</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>A model owner can require checks before a key service releases the model&#x27;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&#x27;s own records must be protected against rollback.</p></section>
diff --git a/research/model-key-broker-provisioning/v1/index.html b/research/model-key-broker-provisioning/v1/index.html
index ef67859..0c22354 100644
--- a/research/model-key-broker-provisioning/v1/index.html
+++ b/research/model-key-broker-provisioning/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Model-Key Broker Provisioning / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Owner-Approved Provisioning of a Model-Key Broker: Binding the broker&#x27;s configuration, receiving key and policy epoch before the model key leaves the owner</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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&#x27;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.</p></section>
diff --git a/research/receipt-gated-model-serving/index.html b/research/receipt-gated-model-serving/index.html
index d969b86..65ec0d9 100644
--- a/research/receipt-gated-model-serving/index.html
+++ b/research/receipt-gated-model-serving/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Receipt-Gated Model Serving</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/receipt-gated-model-serving/v1/index.html b/research/receipt-gated-model-serving/v1/index.html
index 51642dc..04a5a9d 100644
--- a/research/receipt-gated-model-serving/v1/index.html
+++ b/research/receipt-gated-model-serving/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Receipt-Gated Model Serving / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/requirement-preserving-human-approval/index.html b/research/requirement-preserving-human-approval/index.html
index efbd5fd..82fb0f0 100644
--- a/research/requirement-preserving-human-approval/index.html
+++ b/research/requirement-preserving-human-approval/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Human Approvals</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Requirement-Preserving Human Approvals for Signed Agent Manifests</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/requirement-preserving-human-approval/v1/index.html b/research/requirement-preserving-human-approval/v1/index.html
index 0e86326..e86a346 100644
--- a/research/requirement-preserving-human-approval/v1/index.html
+++ b/research/requirement-preserving-human-approval/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Human Approvals / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Requirement-Preserving Human Approvals for Signed Agent Manifests</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/index.html b/research/telemetry-evidence-acceptance/index.html
index 1cba3ac..969ec1c 100644
--- a/research/telemetry-evidence-acceptance/index.html
+++ b/research/telemetry-evidence-acceptance/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/v1/index.html b/research/telemetry-evidence-acceptance/v1/index.html
index 910e7eb..51e3978 100644
--- a/research/telemetry-evidence-acceptance/v1/index.html
+++ b/research/telemetry-evidence-acceptance/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/v2/index.html b/research/telemetry-evidence-acceptance/v2/index.html
index ddaeb46..edfa455 100644
--- a/research/telemetry-evidence-acceptance/v2/index.html
+++ b/research/telemetry-evidence-acceptance/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 30, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/telemetry-evidence-acceptance/v3/index.html b/research/telemetry-evidence-acceptance/v3/index.html
index 7e98c71..a2037a7 100644
--- a/research/telemetry-evidence-acceptance/v3/index.html
+++ b/research/telemetry-evidence-acceptance/v3/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Acceptance Before Export / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/trace/index.html b/research/trace/index.html
index a0eb9f0..4f59170 100644
--- a/research/trace/index.html
+++ b/research/trace/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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.</p></section>
diff --git a/research/trace/v1/index.html b/research/trace/v1/index.html
index fdef26a..86b4305 100644
--- a/research/trace/v1/index.html
+++ b/research/trace/v1/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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 0.2.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.</p></section>
diff --git a/research/trace/v2/index.html b/research/trace/v2/index.html
index a7be596..ccc19a7 100644
--- a/research/trace/v2/index.html
+++ b/research/trace/v2/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 28, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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 0.2.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.</p></section>
diff --git a/research/trace/v3/index.html b/research/trace/v3/index.html
index 402a115..3c43d24 100644
--- a/research/trace/v3/index.html
+++ b/research/trace/v3/index.html
@@ -66,7 +66,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / TRACE / Version 3</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 3</p>
 <h1>TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)</h1>
-<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Rishabh Poddar, Aaron Fulkerson, Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/research/weight-custody-manifest/index.html b/research/weight-custody-manifest/index.html
index ef35e19..e37178b 100644
--- a/research/weight-custody-manifest/index.html
+++ b/research/weight-custody-manifest/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Weight Custody Manifest</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-plain" aria-labelledby="plain-english"><h2 id="plain-english">In plain English</h2><p>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&#x27;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.</p></section>
diff --git a/research/weight-custody-manifest/v1/index.html b/research/weight-custody-manifest/v1/index.html
index 0c88bc7..18b0454 100644
--- a/research/weight-custody-manifest/v1/index.html
+++ b/research/weight-custody-manifest/v1/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Weight Custody Manifest / Version 1</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 1</p>
 <h1>Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>September 27, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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. Two later findings bound those results: a published advisory showed that the evaluated key broker did not require GPU confidential-compute mode before release, and 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.</p></section>
diff --git a/research/weight-custody-manifest/v2/index.html b/research/weight-custody-manifest/v2/index.html
index cd5a9a6..218584f 100644
--- a/research/weight-custody-manifest/v2/index.html
+++ b/research/weight-custody-manifest/v2/index.html
@@ -64,7 +64,7 @@
 <main id="main" class="research-main"><nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / Weight Custody Manifest / Version 2</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version 2</p>
 <h1>Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights</h1>
-<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">Imran Siddique</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>October 1, 2026</span><span>Not peer reviewed</span><span>Patent Pending</span></div>
 </header>
 <section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>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.</p></section>
diff --git a/tools/build-research.py b/tools/build-research.py
index 0f4bfc3..b383098 100644
--- a/tools/build-research.py
+++ b/tools/build-research.py
@@ -128,7 +128,7 @@ def paper_page(p, v=None):
     body=f'''<nav class="research-breadcrumb" aria-label="Breadcrumb"><a href="/research/">Research</a> / {esc(q['short_title'])}{f' / Version {n}' if v else ''}</nav>
 <header class="paper-header"><p class="research-eyebrow">Technical report / Version {n}</p>
 <h1>{esc(q['title'])}</h1>
-<p class="paper-authors">{esc(', '.join(q['authors']))}</p><p class="paper-affiliation">AgenTrust</p>
+<p class="paper-authors">{esc(', '.join(q['authors']))}</p><p class="paper-affiliation">OPAQUE Systems</p>
 <div class="paper-status"><span>{human_date(q['date'])}</span><span>Not peer reviewed</span>{patent}</div>
 </header>
 {plain}<section class="paper-abstract" aria-labelledby="abstract"><h2 id="abstract">Abstract</h2><p>{esc(q['abstract'])}</p></section>