agentrust-trace 0.1.1__tar.gz → 0.3.0__tar.gz

agentrust_trace-0.3.0/.github/workflows/docs.yml

@@ -0,0 +1,72 @@
+name: Docs
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - "docs/**"
+      - "spec/**"
+      - "mkdocs.yml"
+      - "requirements-docs.txt"
+      - "README.md"
+      - "CHANGELOG.md"
+      - "CONTRIBUTING.md"
+      - "GOVERNANCE.md"
+      - "ROADMAP.md"
+      - "LIMITATIONS.md"
+      - "CNAME"
+  workflow_dispatch:
+
+permissions:
+  contents: write
+
+concurrency:
+  group: docs-deploy
+  cancel-in-progress: false
+
+jobs:
+  deploy:
+    name: Build and deploy docs
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - uses: actions/setup-python@v6
+        with:
+          python-version: "3.11"
+          cache: pip
+
+      - name: Install docs dependencies
+        run: |
+          pip install -r requirements-docs.txt
+          pip install -e ".[dev]"
+
+      - name: Configure git for gh-deploy
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "github-actions[bot]@users.noreply.github.com"
+
+      - name: Assemble docs build directory
+        run: |
+          BUILD=.docs_build
+          mkdir -p $BUILD
+
+          if [ -d docs ]; then cp -r docs $BUILD/docs; fi
+          if [ -d spec ]; then cp -r spec $BUILD/spec; fi
+          if [ -d examples ]; then cp -r examples $BUILD/examples; fi
+
+          for fname in README.md CHANGELOG.md CONTRIBUTING.md GOVERNANCE.md ROADMAP.md LIMITATIONS.md CNAME; do
+            if [ -f "$fname" ]; then cp "$fname" "$BUILD/$fname"; fi
+          done
+
+          echo "Build dir contains $(find $BUILD -type f | wc -l) files"
+
+      - name: Generate build config
+        run: |
+          sed 's|^docs_dir: \.$|docs_dir: .docs_build|' mkdocs.yml > .mkdocs_build.yml
+
+      - name: Build and deploy to GitHub Pages
+        run: mkdocs gh-deploy --force --clean --config-file .mkdocs_build.yml

{agentrust_trace-0.1.1 → agentrust_trace-0.3.0}/ADOPTERS.md

@@ -8,4 +8,4 @@ To add your organization, open a pull request editing this file.
 
 | Organization | Usage |
 |---|---|
-| Opaque Systems | Founding contributor — developed the initial specification, reference implementation, and TRACE registry infrastructure |
+| OPAQUE Systems | Founding contributor — developed the initial specification, reference implementation, and TRACE registry infrastructure |

agentrust_trace-0.3.0/ANTITRUST.md

@@ -0,0 +1,26 @@
+# Antitrust Policy
+
+TRACE is an open specification project hosted under the agentrust-io organization and targeting donation to the Agentic AI Foundation (AAIF) under the Linux Foundation. Participation in this project is subject to antitrust and competition laws.
+
+## Prohibited topics
+
+The following topics must not be discussed in any project forum, issue, PR, mailing list, meeting, or chat channel:
+
+- Prices, pricing strategies, or cost structures of any product or service
+- Market allocation, geographic territories, or customer segmentation
+- Bids, contracts, or terms with any customer or competitor
+- Whether to deal with, or boycott, any company or individual
+- Production volumes, capacity plans, or sales forecasts
+- Any other competitively sensitive business information
+
+## What is appropriate
+
+Project discussions must be limited to technical matters: specification design, cryptographic protocols, SDK implementation, conformance test coverage, and interoperability. Commercial decisions are for each organization to make independently.
+
+## Reporting
+
+If you observe discussion that appears to violate this policy, stop the discussion immediately and report it to the Project Lead via private GitHub message or email. Do not continue the discussion or document it further in project channels.
+
+## Questions
+
+If you are uncertain whether a topic is appropriate for project discussion, consult your organization's legal counsel before participating.

{agentrust_trace-0.1.1 → agentrust_trace-0.3.0}/CHANGELOG.md

@@ -9,6 +9,19 @@ Format: [Semantic Versioning](https://semver.org/). Spec versions follow `MAJOR.
 
 ---
 
+## [0.3.0] — 2026-06-30
+
+### Security
+
+- `verify_record` now requires an explicit trusted key. Self-verification from the embedded `cnf.jwk` is no longer the default; use `allow_embedded_key=True` to opt in.
+- Verification enforces freshness (`iat` / `max_age_seconds`, default 24h) and an optional `expected_nonce`. JWK `kty` / `crv` are validated.
+
+### Breaking
+
+- **BREAKING:** Canonicalization is now RFC 8785 (JCS). Trust records are NOT cross-verifiable with 0.2.0 (the prior `json.dumps` canonicalization was non-conformant).
+
+---
+
 ## [0.1.0] — 2026-06-23
 
 Initial public draft. Announced at Confidential Computing Summit, San Francisco.
@@ -35,7 +48,26 @@ Initial public draft. Announced at Confidential Computing Summit, San Francisco.
 
 ### Open questions
 
-Seven open questions requiring founding-member input before v0.2 are documented in §7 of the spec.
+Seven open questions requiring community input before v0.2 are documented in §7 of the spec.
+
+---
+
+## [0.2.0] — TBD
+
+### Specification
+
+- Extend `subject` field to accept DID URIs (any `did:` method) in addition to SPIFFE SVIDs.
+  Previously `^spiffe://` only; now `^(spiffe://|did:)`. Additive, backward-compatible.
+  DID-native runtimes (e.g. AGT `did:mesh:` identities) no longer require a parallel SPIFFE identity.
+  Closes: microsoft/agent-governance-toolkit ADR-0032, agentrust-io/trace-spec#35.
+
+### Schema
+
+- `schema/trace-claim.json`: `subject` pattern updated to `^(spiffe://|did:)`, description updated.
+
+### Reference Implementation
+
+- `TrustRecord.subject` pattern updated to `r"^(spiffe://|did:)"`.
 
 ---
 

agentrust_trace-0.3.0/CNAME

@@ -0,0 +1 @@
+trace.agentrust-io.com

agentrust_trace-0.3.0/LIMITATIONS.md

@@ -0,0 +1,55 @@
+# Known Limitations
+
+This document describes what TRACE does not do, and where layered defenses are needed. Honest scope boundaries prevent misplaced trust.
+
+## What a TRACE claim does not prevent
+
+**Operator-forged software-only records**
+A TRACE claim at Level 0 (software-only signing) is signed by a key held in software. A privileged operator with root access can produce a valid-looking Level 0 record for a run that never happened, or that violated policy. Level 0 is suitable for development and audit-trail tooling only — not for third-party verification.
+
+**Replay of a valid past record**
+A TRACE claim proves a specific run happened; it does not prevent a verifier from being shown a valid record from an earlier run. Verifiers that rely on recency must check the `iat` and `exp` claims, require nonce binding to a challenge, or anchor records to a public transparency log and check for freshness.
+
+**Policy correctness**
+The `policy.bundle_hash` field attests that a specific policy was in force at runtime. It does not attest that the policy achieves the intended security outcome. Policy review is a separate control.
+
+**What happened inside the model**
+The call transcript records tool invocations, arguments, and responses that are observable at the gateway boundary. It does not record the model's internal chain-of-thought, intermediate reasoning, or context window contents. Reasoning that influences behavior without producing a tool call is not captured.
+
+**Cross-boundary data propagation**
+The call graph summary uses temporal adjacency to approximate data flow between tool calls. It cannot definitively prove which specific data from one tool response influenced which subsequent call. The `provenance_disclaimer` field in every call graph summary is required for this reason.
+
+**TEE side-channel attacks**
+Hardware attestation proves the TRACE signing key and policy engine were measured in silicon before execution. It does not protect against side-channel attacks (cache timing, power analysis) targeting the TEE itself. TEE-level side-channel defense is the responsibility of the TEE platform vendor.
+
+**Revocation of the signing key after issuance**
+If the TRACE signing key is compromised after records are issued, existing records remain cryptographically valid. Key monitoring, rapid revocation, and transparency log integration are the required controls — TRACE provides the anchoring mechanism but cannot detect compromise itself.
+
+## What Level 0 does not provide
+
+Level 0 (software-only signing) is suitable for development, internal audit trails, and staging environments. It does not satisfy:
+
+- EU AI Act Art. 12 (tamper-evident logging) — requires Level 1+
+- DORA Art. 9 (ICT risk management) — requires Level 1+ with transparency log anchoring
+- Any claim of hardware-rooted trust — the signing key is held in software and can be extracted by a privileged operator
+
+## What the SDK does not do
+
+- **Evaluate Cedar policy** — the SDK includes the Cedar policy field in the claim; evaluation requires the Cedar engine (included in AGT or cMCP)
+- **Store or index records** — the SDK produces and verifies TRACE claim documents; storage, rotation, and retrieval are the caller's responsibility
+- **Anchor to a transparency log** — the SDK generates records suitable for SCITT anchoring; submission to a transparency log requires a separate SCITT client
+- **Replace a secrets manager** — signing private keys must be stored in a secrets manager (Azure Key Vault, AWS Secrets Manager, HSM); do not store them on disk without protection
+- **Provide an authoritative verification service** — the self-hosted verifier confirms cryptographic validity against the issuer's key; authoritative third-party verification with SLA is a separate commercial service
+
+## Performance
+
+Hardware attestation adds latency at the point of claim generation (not per-tool-call):
+
+| Provider | Typical claim signing latency |
+|---|---|
+| Software (Level 0) | < 1 ms |
+| TPM | 50–200 ms |
+| SEV-SNP | 10–50 ms |
+| TDX | 10–50 ms |
+
+Claim verification (signature check + schema validation) is < 5 ms in all cases.

{agentrust_trace-0.1.1 → agentrust_trace-0.3.0}/MAINTAINERS.md

@@ -4,7 +4,7 @@
 
 | Name | Affiliation | GitHub | Contact |
 |---|---|---|---|
-| Imran Siddique | OPAQUE Systems | @imraan | imran.siddique@opaque.co |
+| Imran Siddique | OPAQUE Systems | @imraan | maintainers@agentrust.io |
 
 The Project Lead has final decision authority on specification changes, AAIF/CoSAI submission scope, conformance requirements, and Maintainer appointments.
 

agentrust_trace-0.3.0/NOTICE

@@ -0,0 +1,21 @@
+TRACE
+Copyright 2026 AgenTrust Authors
+
+This product includes software developed by the AgenTrust project
+(https://github.com/agentrust-io/trace-spec).
+
+---
+
+Third-party components used by the Python SDK:
+
+pydantic
+  License: MIT
+  https://github.com/pydantic/pydantic
+
+jsonschema
+  License: MIT
+  https://github.com/python-jsonschema/jsonschema
+
+jcs (dev dependency — RFC 8785 canonical JSON)
+  License: MIT
+  https://github.com/nicowillis/jcs

agentrust_trace-0.3.0/PKG-INFO

@@ -0,0 +1,106 @@
+Metadata-Version: 2.4
+Name: agentrust-trace
+Version: 0.3.0
+Summary: TRACE v0.1 — hardware-attested governance records for AI agents
+Project-URL: Homepage, https://github.com/agentrust-io/trace-spec
+Project-URL: Repository, https://github.com/agentrust-io/trace-spec
+Project-URL: Issues, https://github.com/agentrust-io/trace-spec/issues
+Project-URL: Changelog, https://github.com/agentrust-io/trace-spec/blob/main/CHANGELOG.md
+License: Apache-2.0
+License-File: LICENSE
+License-File: NOTICE
+Keywords: ai-governance,attestation,confidential-computing,eat,rats,tee,trace
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: Apache Software License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
+Classifier: Topic :: Security
+Classifier: Typing :: Typed
+Requires-Python: >=3.11
+Requires-Dist: cryptography>=42.0
+Requires-Dist: jsonschema>=4.20
+Requires-Dist: pydantic>=2.0
+Requires-Dist: rfc8785>=0.1.2
+Provides-Extra: dev
+Requires-Dist: mypy>=1.10; extra == 'dev'
+Requires-Dist: pytest-cov>=5.0; extra == 'dev'
+Requires-Dist: pytest>=8.0; extra == 'dev'
+Requires-Dist: ruff>=0.4; extra == 'dev'
+Requires-Dist: types-jsonschema; extra == 'dev'
+Description-Content-Type: text/markdown
+
+<p align="center">
+  <img src="docs/assets/icon.svg" width="96" height="96" alt="TRACE"/>
+</p>
+
+# TRACE: Trust Runtime Attestation and Compliance Evidence
+
+<p align="center">
+  <a href="https://trace.agentrust-io.com">
+    <img src="https://img.shields.io/badge/%F0%9F%93%96_Full_Documentation-trace.agentrust--io.com-8251EE?style=for-the-badge&logoColor=white" alt="Full Documentation" height="40">
+  </a>
+</p>
+
+<p align="center">
+  <a href="spec/trace-v0.1.md">Specification</a> &nbsp;|&nbsp;
+  <a href="schema/trace-claim.json">Schema</a> &nbsp;|&nbsp;
+  <a href="examples/">Examples</a> &nbsp;|&nbsp;
+  <a href="https://github.com/agentrust-io/trace-registry">Registry</a> &nbsp;|&nbsp;
+  <a href="https://github.com/agentrust-io/trace-tests">Test Suite</a> &nbsp;|&nbsp;
+  <a href="https://github.com/agentrust-io/cmcp">Reference Impl</a>
+</p>
+
+[![License: CC BY 4.0](https://img.shields.io/badge/License-CC_BY_4.0-lightgrey.svg)](LICENSE)
+[![Spec](https://img.shields.io/badge/Spec-v0.1-0ea5e9)](spec/trace-v0.1.md)
+[![PyPI](https://img.shields.io/pypi/v/agentrust-trace)](https://pypi.org/project/agentrust-trace/)
+[![CI](https://github.com/agentrust-io/trace-spec/actions/workflows/ci.yml/badge.svg)](https://github.com/agentrust-io/trace-spec/actions/workflows/ci.yml)
+[![Discord](https://img.shields.io/badge/Discord-Join-5865F2?logo=discord&logoColor=white&style=flat)](https://discord.gg/grgzFEHgkj)
+
+> **Developer Preview.** Launching at Confidential Computing Summit, June 23 2026.
+
+An open specification for hardware-attested AI agent governance records. TRACE defines the format, anchoring protocol, and verification rules for cryptographically provable evidence that an AI agent ran under a specific policy, in a verified hardware environment, on classified data, invoking identified tools — bound into a single signed artifact rooted in silicon attestation.
+
+A TRACE Trust Record answers: _what ran, where, under which policy, touching which data, calling which tools_ — in a form any third party can verify without trusting the operator.
+
+## Quick start
+
+```bash
+pip install agentrust-trace
+```
+
+```python
+from agentrust_trace import TrustRecord, sign_record
+
+record = TrustRecord(
+    subject="spiffe://trust.example.org/agent/payments-processor",
+    model_id="claude-sonnet-4-6",
+    platform="amd-sev-snp",
+    policy_hash="sha256:b2c3d4...",
+)
+signed = sign_record(record, key=signing_key)
+```
+
+## Resources
+
+| | |
+|---|---|
+| 📖 Full documentation | [trace.agentrust-io.com](https://trace.agentrust-io.com) |
+| 📄 Specification | [spec/trace-v0.1.md](spec/trace-v0.1.md) |
+| 🔍 Schema | [schema/trace-claim.json](schema/trace-claim.json) |
+| 📦 PyPI | [agentrust-trace](https://pypi.org/project/agentrust-trace/) |
+| 🧪 Test suite | [trace-tests](https://github.com/agentrust-io/trace-tests) |
+| 🗂 Registry | [trace-registry](https://github.com/agentrust-io/trace-registry) |
+| 🔗 Reference implementation | [cmcp](https://github.com/agentrust-io/cmcp) |
+| 💬 Discussions | [GitHub Discussions](https://github.com/orgs/agentrust-io/discussions) |
+| 📋 Changelog | [CHANGELOG.md](CHANGELOG.md) |
+
+## Standards alignment
+
+Targeting the [Agentic AI Foundation (AAIF)](https://agenticai.foundation) at the Linux Foundation. Active standardization track in [CoSAI WS4](https://github.com/oasis-open-projects/coalition-for-secure-ai). Builds on [RFC 9711 (EAT)](https://www.rfc-editor.org/rfc/rfc9711), [RFC 9334 (RATS)](https://www.rfc-editor.org/rfc/rfc9334), and SCITT draft-22.
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) and [GOVERNANCE.md](GOVERNANCE.md). All contributors must agree to the [ANTITRUST.md](ANTITRUST.md) policy.

agentrust_trace-0.3.0/README.md

@@ -0,0 +1,72 @@
+<p align="center">
+  <img src="docs/assets/icon.svg" width="96" height="96" alt="TRACE"/>
+</p>
+
+# TRACE: Trust Runtime Attestation and Compliance Evidence
+
+<p align="center">
+  <a href="https://trace.agentrust-io.com">
+    <img src="https://img.shields.io/badge/%F0%9F%93%96_Full_Documentation-trace.agentrust--io.com-8251EE?style=for-the-badge&logoColor=white" alt="Full Documentation" height="40">
+  </a>
+</p>
+
+<p align="center">
+  <a href="spec/trace-v0.1.md">Specification</a> &nbsp;|&nbsp;
+  <a href="schema/trace-claim.json">Schema</a> &nbsp;|&nbsp;
+  <a href="examples/">Examples</a> &nbsp;|&nbsp;
+  <a href="https://github.com/agentrust-io/trace-registry">Registry</a> &nbsp;|&nbsp;
+  <a href="https://github.com/agentrust-io/trace-tests">Test Suite</a> &nbsp;|&nbsp;
+  <a href="https://github.com/agentrust-io/cmcp">Reference Impl</a>
+</p>
+
+[![License: CC BY 4.0](https://img.shields.io/badge/License-CC_BY_4.0-lightgrey.svg)](LICENSE)
+[![Spec](https://img.shields.io/badge/Spec-v0.1-0ea5e9)](spec/trace-v0.1.md)
+[![PyPI](https://img.shields.io/pypi/v/agentrust-trace)](https://pypi.org/project/agentrust-trace/)
+[![CI](https://github.com/agentrust-io/trace-spec/actions/workflows/ci.yml/badge.svg)](https://github.com/agentrust-io/trace-spec/actions/workflows/ci.yml)
+[![Discord](https://img.shields.io/badge/Discord-Join-5865F2?logo=discord&logoColor=white&style=flat)](https://discord.gg/grgzFEHgkj)
+
+> **Developer Preview.** Launching at Confidential Computing Summit, June 23 2026.
+
+An open specification for hardware-attested AI agent governance records. TRACE defines the format, anchoring protocol, and verification rules for cryptographically provable evidence that an AI agent ran under a specific policy, in a verified hardware environment, on classified data, invoking identified tools — bound into a single signed artifact rooted in silicon attestation.
+
+A TRACE Trust Record answers: _what ran, where, under which policy, touching which data, calling which tools_ — in a form any third party can verify without trusting the operator.
+
+## Quick start
+
+```bash
+pip install agentrust-trace
+```
+
+```python
+from agentrust_trace import TrustRecord, sign_record
+
+record = TrustRecord(
+    subject="spiffe://trust.example.org/agent/payments-processor",
+    model_id="claude-sonnet-4-6",
+    platform="amd-sev-snp",
+    policy_hash="sha256:b2c3d4...",
+)
+signed = sign_record(record, key=signing_key)
+```
+
+## Resources
+
+| | |
+|---|---|
+| 📖 Full documentation | [trace.agentrust-io.com](https://trace.agentrust-io.com) |
+| 📄 Specification | [spec/trace-v0.1.md](spec/trace-v0.1.md) |
+| 🔍 Schema | [schema/trace-claim.json](schema/trace-claim.json) |
+| 📦 PyPI | [agentrust-trace](https://pypi.org/project/agentrust-trace/) |
+| 🧪 Test suite | [trace-tests](https://github.com/agentrust-io/trace-tests) |
+| 🗂 Registry | [trace-registry](https://github.com/agentrust-io/trace-registry) |
+| 🔗 Reference implementation | [cmcp](https://github.com/agentrust-io/cmcp) |
+| 💬 Discussions | [GitHub Discussions](https://github.com/orgs/agentrust-io/discussions) |
+| 📋 Changelog | [CHANGELOG.md](CHANGELOG.md) |
+
+## Standards alignment
+
+Targeting the [Agentic AI Foundation (AAIF)](https://agenticai.foundation) at the Linux Foundation. Active standardization track in [CoSAI WS4](https://github.com/oasis-open-projects/coalition-for-secure-ai). Builds on [RFC 9711 (EAT)](https://www.rfc-editor.org/rfc/rfc9711), [RFC 9334 (RATS)](https://www.rfc-editor.org/rfc/rfc9334), and SCITT draft-22.
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md) and [GOVERNANCE.md](GOVERNANCE.md). All contributors must agree to the [ANTITRUST.md](ANTITRUST.md) policy.

{agentrust_trace-0.1.1 → agentrust_trace-0.3.0}/ROADMAP.md

@@ -9,7 +9,7 @@ Announced at Confidential Computing Summit, San Francisco, June 23 2026.
 - Wire formats: EAT/JWT and CBOR-COSE
 - Hardware roots: NVIDIA H100/Blackwell, Intel TDX, AMD SEV-SNP, Azure MAA, GCP Confidential Space, AWS Nitro
 - JSON Schema and three hardware examples
-- Reference implementation: cMCP Phase 1 (runtime trust, no policy enforcement)
+- Reference implementation: cMCP Phase 1 (Cedar policy enforcement, TRACE Level 2 emission)
 
 **Not in v0.1:** MCP profile (normative), A2A profile, vendor platform annexes, OWASP/ATLAS cross-walks, encrypted claims envelope.
 
@@ -45,4 +45,4 @@ Driven by founding-member feedback and open questions from §7 of the spec.
 
 ## Influencing the roadmap
 
-Open a GitHub issue with the `spec` or `roadmap` label. Founding-member and vendor feedback from the CC Summit period (June–September 2026) has priority for v0.2 scope.
+Open a GitHub issue with the `spec` or `roadmap` label. Contributor and community feedback from the CC Summit period (June–September 2026) has priority for v0.2 scope.

{agentrust_trace-0.1.1 → agentrust_trace-0.3.0}/docs/assets/icon.svg

@@ -2,14 +2,16 @@
   <defs>
     <linearGradient id="bg" x1="0" y1="0" x2="1" y2="1">
       <stop offset="0%" stop-color="#f5f3ff"/>
-      <stop offset="100%" stop-color="#e0f2fe"/>
+      <stop offset="100%" stop-color="#ede9fe"/>
     </linearGradient>
     <linearGradient id="brand" x1="0" y1="0" x2="1" y2="1">
-      <stop offset="0%" stop-color="#7c3aed"/>
-      <stop offset="100%" stop-color="#0ea5e9"/>
+      <stop offset="0%" stop-color="#5BD2BE"/>
+      <stop offset="50%" stop-color="#8251EE"/>
+      <stop offset="100%" stop-color="#C661F7"/>
     </linearGradient>
   </defs>
   <rect width="400" height="400" fill="url(#bg)"/>
+  <!-- Shield -->
   <path d="M200,58 L326,112 L326,224 C326,298 268,340 200,360 C132,340 74,298 74,224 L74,112 Z"
         fill="url(#brand)" opacity="0.10" stroke="url(#brand)" stroke-width="3.5" stroke-linejoin="round"/>
   <!-- Eye outline -->

agentrust_trace-0.3.0/docs/crosswalks/owasp-agentic-top-10.md

@@ -0,0 +1,65 @@
+# OWASP Agentic AI Top 10 Evidence Cross-walk
+
+> **Non-normative.** This document is informative only. Nothing here changes TRACE v0.1 schema fields, wire formats, required claims, or conformance requirements. References to "TRACE" mean the TRACE v0.1 Trust Record as defined in [`spec/trace-v0.1.md`](../../spec/trace-v0.1.md).
+
+---
+
+## Purpose
+
+OWASP's Agentic AI Top 10 (ASI01–ASI10) names the principal risk categories for autonomous AI agents. TRACE is an evidence and attestation layer: it does not prevent these risks, but it produces verifiable, hardware-rooted records that support audit, incident review, and governance verification after or during execution.
+
+This page answers a concrete question for each OWASP risk: which TRACE Trust Record claims carry relevant evidence, what that evidence actually proves, and where TRACE v0.1 leaves a gap that a future profile would need to close.
+
+Field names are exact TRACE v0.1 claim names as specified in §3.1 of the spec. Sub-field references such as `policy.bundle_hash`, `runtime.platform`, and `appraisal.status` refer to the nested fields shown in the §3.2 wire-format example.
+
+---
+
+## Mapping table
+
+| OWASP risk | Relevant TRACE claims | Evidence TRACE can provide | Limitations / out of scope | Future TRACE profile need |
+|---|---|---|---|---|
+| **ASI01: Agent Goal Hijack** | `policy`, `tool_transcript`, `data_class`, `runtime`, `transparency` | `policy.bundle_hash` shows which policy was bound at execution time; `policy.enforcement_mode` shows whether it ran in `enforce` or `silent`; `tool_transcript.hash` and `tool_transcript.call_count` show the scope of tool activity; `data_class` shows the sensitivity of data processed; `transparency` anchors the record to an append-only log for independent audit. | Does not capture the agent's internal goal representation or reasoning chain. Does not itself detect or block prompt injection. A hijacked goal that stays within recorded tool boundaries leaves no additional fingerprint in v0.1 claims. | MCP/A2A profile fields for intent binding, goal hash, prompt-to-plan linkage, and per-decision policy outcome records. |
+| **ASI02: Tool Misuse and Exploitation** | `tool_transcript`, `policy`, `data_class`, `runtime`, `transparency` | `tool_transcript.hash` binds the transcript of tool invocations crossing a protocol boundary (MCP, A2A) into the signed record; `tool_transcript.call_count` bounds the observed call volume; `policy.bundle_hash` and `policy.enforcement_mode` show what rules were in force; `data_class` shows the sensitivity classification applied at the call layer; `runtime.platform` and `runtime.measurement` bind the execution environment. | `tool_transcript` covers calls crossing an instrumented protocol boundary. Functions embedded inside the deployed binary are bound only by `build_provenance` and `model`, not by per-invocation transcript records. Does not prove each call was semantically appropriate without per-call policy decision records. | MCP profile for per-call tool identity, parameters, egress data class, and allow/deny decision outcome per invocation. |
+| **ASI03: Identity and Privilege Abuse** | `subject`, `cnf`, `signature`, `runtime`, `policy`, `appraisal` | `subject` carries the SPIFFE SVID binding workload identity to a TEE-held key; `cnf` binds the signing key to the TEE via the hardware measurement in `runtime`; `appraisal.status` records the verifier's judgment of the evidence against policy; `policy.bundle_hash` shows what authorization rules were bound. Together these allow a verifier to confirm that the claimed identity corresponded to a genuine, measured workload at record issuance time. | Does not replace IAM or RBAC systems. Does not prove that external permissions granted to the workload were correctly scoped. Does not cover lateral movement or privilege escalation that occurred at infrastructure layers outside the TEE boundary. | Delegation profile fields for scoped credentials, audience restriction, purpose binding, and per-action authorization evidence. |
+| **ASI04: Agentic Supply Chain Vulnerabilities** | `build_provenance`, `model`, `runtime`, `transparency`, `appraisal` | `build_provenance.slsa_level`, `build_provenance.builder`, and `build_provenance.digest` bind build-time provenance to the running workload; `model.weights_digest` and `model.model_id` bind the model artifact; `runtime.measurement` and `runtime.rim_uri` bind the runtime image to vendor-published Reference Integrity Manifests; `transparency` provides an append-only anchor for the full record. | Does not enumerate every transitive dependency. Does not detect malicious code that was present at build time but is not reflected in measurement divergence. Does not prove model behavior is safe -- only that the identified artifact was the one that executed. | Richer AIBOM/SBOM linkage in the `model` sub-claim; vendor platform annexes specifying per-silicon supply-chain appraisal criteria. |
+| **ASI05: Unexpected Code Execution** | `runtime`, `build_provenance`, `tool_transcript`, `policy`, `appraisal` | `runtime.measurement` shows what workload and container digest were loaded; `build_provenance.digest` and `build_provenance.slsa_level` bind the build artifact; `tool_transcript.hash` captures tool invocations at protocol boundaries; `appraisal.status` records whether the verifier accepted the runtime evidence against current RIMs. | Does not prevent code execution. Does not prove no code ran outside the recorded `tool_transcript` scope: inline code execution embedded in the workload binary is not captured at invocation granularity by v0.1 claims. | Tool and code-execution profile: sandbox identity, command execution transcript hash, filesystem and network boundary evidence per invocation. |
+| **ASI06: Memory and Context Poisoning** | `model`, `data_class`, `tool_transcript`, `build_provenance`, `transparency` | `model.model_id` and `model.weights_digest` identify the model artifact; `data_class` records the sensitivity classification applied to inputs and outputs; `tool_transcript.hash` captures context-retrieval calls that crossed an instrumented boundary; `build_provenance.digest` binds the build artifact that includes any vector-store or RAG client code. | TRACE v0.1 does not bind memory snapshots, RAG corpus roots, embedding-store contents, or poisoning scan results. Context provenance -- where retrieved chunks originated and whether they were validated -- is not a v0.1 claim. | Memory and RAG profile: context source hashes, corpus Merkle roots, poisoning scan status, namespace and tenant boundary evidence. |
+| **ASI07: Insecure Inter-Agent Communication** | `subject`, `cnf`, `signature`, `runtime`, `tool_transcript`, `transparency` | `subject` and `cnf` establish and bind workload identity for each participating agent; `signature` (or the enveloping-signature equivalent) proves record integrity; `runtime.measurement` binds the TEE that produced the record; `tool_transcript.hash` anchors the inter-agent call transcript; `transparency` anchors the record in an append-only log accessible to any verifier. | TRACE v0.1 does not define a normative A2A profile. Message-level semantic validation, nonce binding per message, and delegation chain records across multiple hops are not v0.1 claims. | A2A profile: peer agent identity, per-message hash, audience restriction, nonce, delegation chain, and protocol version binding. |
+| **ASI08: Cascading Failures** | `tool_transcript`, `transparency`, `subject`, `appraisal`, `policy` | `tool_transcript.hash` and `tool_transcript.call_count` provide a bounded activity record for post-incident traceability; `subject` identifies the workload at each hop where a Trust Record was issued; `appraisal.status` and `appraisal.verifier` record the verification outcome; `policy.bundle_hash` shows what controls were bound; `transparency` provides an auditable anchor for reconstructing the sequence of records. | Does not itself detect cascade conditions, stop propagation, or reconstruct full multi-agent lineage unless every participating agent issued Trust Records and those records are correlated at analysis time. Lineage reconstruction requires out-of-band tooling. | Workflow provenance profile: parent/child record references, propagation lineage identifiers, blast-radius counters, and circuit-breaker event records. |
+| **ASI09: Human-Agent Trust Exploitation** | `tool_transcript`, `policy`, `data_class`, `transparency`, `appraisal` | `tool_transcript.hash` records the set of actions the agent took at protocol boundaries; `policy.bundle_hash` and `policy.enforcement_mode` show what rules were in force; `data_class` records the sensitivity class of data involved; `appraisal.status` provides the verifier's assessment; `transparency` anchors the record for independent audit. Collectively these support a post-incident review of what the agent was authorized to do and what it did. | Does not prove what a human was shown in the UI, whether the explanation was accurate, or whether informed consent was obtained. Does not detect social engineering at the human layer. | HITL (human-in-the-loop) evidence profile: approval record, reviewer identity, hash of displayed risk summary, and human decision evidence bound into the Trust Record. |
+| **ASI10: Rogue Agents** | `subject`, `runtime`, `cnf`, `signature`, `policy`, `tool_transcript`, `appraisal`, `transparency` | The full v0.1 claim set combines hardware-bound identity (`subject`, `cnf`), measured execution environment (`runtime`), policy binding (`policy.bundle_hash`, `policy.enforcement_mode`), tool activity (`tool_transcript`), verifier judgment (`appraisal.status`), and transparency anchoring (`transparency`) into one signed, independently verifiable record. A verifier can confirm that the agent presenting this record ran as a measured, policy-bound workload with a TEE-rooted identity at the stated time. | Does not determine behavioral intent. Does not detect rogue behavior that remained within the boundary of recorded claims. A workload can issue a valid Trust Record and still behave in ways the record does not constrain at inference time. | Behavioral integrity profile: declared capability manifest hash, expected tool set, execution baseline hash, and anomaly or quarantine event records. |
+
+---
+
+## What TRACE does not do
+
+The table above surfaces per-risk scope boundaries. These apply across all ten risks:
+
+**TRACE does not prevent OWASP Agentic AI risks.** TRACE is an evidence and attestation layer. It records what happened -- what executed, under what policy, in what environment, on what data class, invoking what tools -- and binds that record cryptographically to a hardware root of trust. Controls that act before, during, or around execution (firewalls, guardrails, RBAC, prompt filters, sandboxing) are out of scope.
+
+**TRACE does not adjudicate model behavior.** As stated in §2.4 of the spec, prompt injection, jailbreaks, hallucination, and alignment drift are permanent scope boundaries. TRACE proves what model artifact executed and what countermeasures were bound; it does not evaluate whether the model's output was correct or intended.
+
+**TRACE v0.1 does not cover intra-binary execution.** `tool_transcript` captures invocations crossing an instrumented protocol boundary (MCP, A2A, or equivalent). Code paths executed inside the deployed binary -- including embedded tool dispatch, in-process memory reads, or direct API calls -- are bound only by `build_provenance` and `model`, not at invocation granularity.
+
+**TRACE does not replace IAM, RBAC, or network controls.** `subject` and `cnf` establish and bind workload identity, but the permissions granted to that identity by external systems are outside the Trust Record. A correctly identified workload can still hold excessive privileges.
+
+**TRACE does not capture UI or human-layer interactions.** What a human sees, approves, or consents to is not a v0.1 claim. This affects ASI09 directly and is a gap for any risk that involves human oversight.
+
+**TRACE does not reconstruct multi-agent lineage automatically.** Records from multiple agents can be correlated by a verifier using `subject`, `transparency`, and `tool_transcript` identifiers, but the v0.1 schema has no normative parent/child record pointer. Lineage reconstruction requires out-of-band analysis tooling and is addressed in the v0.2 workflow provenance profile item.
+
+---
+
+## Relationship to the TRACE roadmap
+
+This cross-walk is a v0.2 roadmap item listed in [`ROADMAP.md`](../../ROADMAP.md). The "Future TRACE profile need" column in the table above describes the additional claim structures that would close each gap; those profiles are separate roadmap items and will be specified in later releases.
+
+The MITRE ATLAS cross-walk (a separate v0.2 item) will address tactics and techniques at a finer granularity than the OWASP risk categories here.
+
+---
+
+## References
+
+- OWASP Agentic AI Top 10: <https://genai.owasp.org/>
+- TRACE v0.1 specification: [`spec/trace-v0.1.md`](../../spec/trace-v0.1.md)
+- TRACE roadmap: [`ROADMAP.md`](../../ROADMAP.md)
+- MITRE ATLAS: <https://atlas.mitre.org/>

agentrust_trace-0.3.0/docs/glossary.md

@@ -0,0 +1,68 @@
+# Glossary
+
+Terms used in the TRACE specification and documentation.
+
+---
+
+**Appraisal**
+The process of evaluating a TEE evidence bundle against a reference integrity manifest (RIM) to produce an `appraisal.status` verdict. An `"affirming"` verdict means the measured environment matches the expected state. Defined in IETF RFC 9334 (RATS).
+
+---
+
+**cnf / JWK**
+The TRACE `cnf` field (from RFC 7800) carries a JSON Web Key (`jwk` sub-field) that contains the Ed25519 public key used to sign the record. It is included in the signed payload so the verifier does not need to retrieve the key out-of-band.
+
+---
+
+**Conformance**
+A trust record is conformant if it passes all test cases required at its declared trust level. Conformance is verified by the `trace-tests` test suite. Partial conformance (record passes some but not all required tests) is not valid.
+
+---
+
+**EAT — Entity Attestation Token**
+A JWT-based format for conveying evidence about a hardware or software entity. TRACE records use the EAT `eat_profile` claim to identify the specific TRACE profile version. Defined in IETF draft-ietf-rats-eat.
+
+---
+
+**GatewayClaim**
+A cMCP claim embedded in a TRACE trust record that binds the record to a specific cMCP session. Contains the session ID, gateway DID, and the Cedar policy bundle hash that governed the session.
+
+---
+
+**JCS — JSON Canonicalization Scheme**
+RFC 8785. A deterministic serialization of JSON objects: Unicode code-point-ordered keys, no whitespace, IEEE 754 double-precision number encoding. TRACE uses JCS to canonicalize the record before computing the Ed25519 signature.
+
+---
+
+**RIM — Reference Integrity Manifest**
+A signed document describing the expected firmware and software measurements for a TEE environment. During Level 1 appraisal, the verifier compares the TEE's runtime measurements against the RIM. The `runtime.rim_uri` field optionally points to a RIM.
+
+---
+
+**RATS — Remote Attestation Procedures**
+The IETF working group and architecture (RFC 9334) that defines the roles and flows for remote attestation: Attester (the hardware), Verifier (checks evidence against RIM), Relying Party (consumes the resulting attestation result). TRACE Level 1 and 2 follow the RATS architecture.
+
+---
+
+**SCITT — Supply Chain Integrity, Transparency, and Trust**
+An IETF draft standard for append-only transparency logs of software and attestation artifacts. TRACE Level 2 records include a SCITT receipt URI in the `transparency` field, anchoring the record to a public or shared log.
+
+---
+
+**SPIFFE / SPIRE**
+SPIFFE (Secure Production Identity Framework For Everyone) defines URI-based workload identities of the form `spiffe://<trust-domain>/<workload-path>`. TRACE requires the `subject` field to be a SPIFFE URI or a DID. SPIRE is the reference implementation.
+
+---
+
+**Trust Level**
+A numeric value (0, 1, or 2) that summarizes the strength of the guarantees carried by a trust record. See [Trust Levels](trust-levels.md) for the full definition of each level.
+
+---
+
+**Trust Record**
+A signed JSON document emitted by an AI agent at the end of a governed session. It asserts the agent's identity, model, policy, data class, tool invocations, and (at Level 1+) hardware attestation state. Defined in full in the [TRACE Specification](../spec/trace-v0.1.md).
+
+---
+
+**Transparency**
+In the TRACE context, transparency means that a trust record has been submitted to an append-only log (SCITT) and can be independently audited by any party with access to the log. The `transparency` field holds the receipt URI. Required at Level 2.