[Project Proposal] TRACE Specification #42

Project Name

TRACE Specification (Trust, Runtime Attestation, and Compliance Evidence)

Project Description

TRACE is an open specification for a signed record of an agent run that a third party can check without trusting the operator who produced it. One Trust Record states what model ran (model.model_id, model.weights_digest), where it ran (runtime.platform, runtime.measurement), under which policy (policy.bundle_hash, policy.enforcement_mode), on which data class (data_class), which tools it called (tool_transcript.hash, tool_transcript.call_count), and whether the record is anchored in a transparency log (transparency).

It profiles existing IETF work instead of defining new cryptography: RFC 9711 (EAT) for the claim envelope, RFC 9334 (RATS) for attester, verifier and relying-party roles, RFC 8785 for the canonical form that gets signed, and SCITT for anchoring.

Every record declares a conformance level, so a relying party can set an acceptance policy:

• Level 0, software-signed. Suited to audit trails a team keeps about itself.
• Level 1, bound to hardware evidence. Acceptance requires hardware-evidence appraisal and a trusted binding to the signer; signature verification alone does not establish Level 1. runtime.platform covers Intel TDX, AMD SEV-SNP (bare and behind the Azure paravisor), NVIDIA H100 and Blackwell, AWS Nitro, Arm CCA, Google Confidential Space and TPM 2.0.
• Level 2, adds transparency anchoring. The inclusion-proof format is published in spec/registry-anchor-v1.md, complete enough that a verifier can be written from that document alone.

The project ships the specification and JSON Schema (trace-spec), the agentrust-trace Python reference library for signing and verification, and an eight-module conformance suite (trace-tests) that produces a report a third party can re-run.

History. Launched as a developer preview at Confidential Computing Summit on 23 June 2026. Spec v0.2 is current. The Linux Foundation announced TRACE on 25 August 2026 as its own series, "TRACE Specification, a Series of LF Projects, LLC", developed with AMD, Intel, Microsoft, OPAQUE and TII. The contribution agreement with LF Projects, LLC was executed on 17 August 2026.

Alignment with AAIF Mission

Agents built on AAIF protocols increasingly act across organizational boundaries: a tool call through an MCP server another team operates, a task delegated over A2A to a peer run by a counterparty. The party on the receiving end has to decide whether to accept the outcome, and today it does that on the strength of the other side's logs.

TRACE gives that decision a common, vendor-neutral evidence format. A record produced by one implementation verifies with another, and the conformance suite makes the claim checkable. That is the same interoperability argument AAIF makes for the protocols themselves, applied to the evidence about what happened when they ran.

Relation to Existing AAIF Projects

TRACE changes nothing on the MCP or A2A wire. Records are produced beside the protocol, by the component that observes the action.

• MCP. The tool_transcript claim binds the tool calls made in a session. cMCP (MIT), a gateway that evaluates Cedar policy on each MCP tool call inside a TEE, emits a TRACE record per session. A normative MCP profile, with the claim structure and binding rules for tool-call transcripts, is targeted for v0.3 and is written for review by MCP maintainers.
• A2A. The delegation block (parent_record_hash plus credential_id) links one hop's record to its parent, so a chain of delegated work forms a delegation graph a verifier can check offline. cA2A (MIT), a trust profile layered on A2A, emits a linked record per hop. The normative A2A profile, including mutual delegation, is also targeted for v0.3.
• agentgateway and Agent Router sit at the same boundary cMCP does and are natural producers. No integration exists today.

Example Use Cases and Evidence of Adoption

Use cases. A compliance team proving to an auditor which policy was in force when an agent touched regulated data. A counterparty accepting a delegated A2A task only when the record shows it ran on attested hardware. An MCP gateway operator giving customers evidence of which tools a session called, without giving them access to the gateway.

Integrations maintained by third parties in agentrust-io/integrations. Nineteen bind to TRACE, each with its own integration.yaml naming the maintainer and the release it was tested against. Nine are Verified tier, meaning the integrations maintainers ran them end to end against released packages: SOVP (Litzki Systems), the ramen-ai cMCP adapter (ramen-ai), Agent Passport System (aeoess), Agent Replay (Altru.dev), Bernstein MCP verifier (Bernstein), EPI Recorder (EPI Labs), Nobulex (Ed25519 action receipts), OntoGuard Decision Authorization (OntoGuard AI) and Parmana (Parmana Systems). The other ten are Community tier, which means the registry checks structure, manifest and links without running the code; maintainer-reported test results are identified separately below: AAIF Authority Comparison Runner (Alakris Research), comply54 (African regulatory compliance), ComputeID AgentPassport (ComputeID, identity evidence carried through references[], added 10 September in #176), DecisionAssure, EvidenceBound Core (EvidenceBound), Frequency Agent Execution Assurance (Altru.dev), Observed-effect references (probityai), Agent Sentinel, SAGE AgenTrust Bridge and Agentic SpendGuard.

Integration scope and maintainer-reported results:

• SAGE AgenTrust Bridge. A proxy in front of a stock SAGE node that checks an attestation before POST /v1/memory/submit. It does not integrate with SAGE core or consensus and guards no other endpoint. Its maintainer reports re-running against agentrust-trace 0.10.0, cmcp-runtime 0.5.0, agentrust-trace-tests 0.5.1 and SAGE v11.19.22, correcting the profile URI and signature canonicalization, and bounding dependencies in integrations#197. Both paths reportedly pass Level 0 and fail Level 1 because they are software-only. See the maintainer's correction.
• Agent Passport System integration (integrations/aeoess-aps in agentrust-io/integrations). An external-evidence-source claiming no conformance level. Its maintainer reports testing against agentrust-trace 0.10.0 and agentrust-trace-tests 0.5.1. APS decisions lack the model, data_class and build_provenance fields needed to produce a TRACE Trust Record; verify_record rejects the mapper's output. See the maintainer's correction and integrations#178 / #195.

Implementations and related artifacts in repositories outside agentrust-io, with each artifact's scope identified:

• bernstein (sipyourdrink-ltd/bernstein, 1,259 stars). TRACE 0.2 Trust Record emitter in src/bernstein/core/observability/trust_record.py, shipped as the bernstein[trace] extra pinned to agentrust-trace>=0.11,<0.12, with emitter tests depending on agentrust-trace-tests>=0.6,<0.7. Its maintainer filed #4760, #4761 and #4799 when the emitter diverged from the v0.2 schema; the canonicalization fix merged in #4814 on 30 August.
• epi-recorder (mohdibrahimaiml/epi-recorder). Exports a sealed recording as a Level 0 Trust Record, validated through agentrust_trace. Fail-closed signed export landed 10 September.
• castrum (patschmittdev/castrum). Governance for Copilot CLI child agents over ACP. Pins the TRACE v0.2 schema at commit 25013c5 with a fixture digest, in docs/reference/external-contracts.md.
• Agent Passport System crosswalk (aeoess/agent-governance-vocabulary). An informative field mapping in crosswalk/agentrust-trace.yaml, pinned to TRACE v0.9.0 with no claim about trace-spec main. This is a separate artifact from the integration above and is not an APS implementation of TRACE.
• Action State Group. trace-trust-record is a provisional entry in the Canonical Payload Binding registry (scitt-payload-binding#67, merged). agent-action-capsule#95, open and under discussion, would let a Capsule cite a TRACE record by digest and accept a hardware-measurement claim only when the cited record verifies.

Organizations with a public relationship to the project, as listed with evidence at agentrust-io.com/community:

• AMD and Intel, founding partners. The implementation verifies SEV-SNP report signatures to the AMD root and TDX DCAP v4 quotes to the Intel SGX Root CA.
• TII, founding partner, anchoring the work in sovereign-AI deployment requirements.
• Action State Group operates the independent witness for the TRACE transparency registry. Its log countersigned registry checkpoint 1 on 7 September 2026 (leaf 936 of a 937-leaf witness tree), and the receipt verifies offline from the published evidence packet.
• PRONATIVE AI, training and adoption partner, with TRACE, cMCP and cA2A planned for its engineering curriculum.
• XRSI, governance and ecosystem sustainability partner.

Implementations by the project's own contributors, listed for completeness and not counted as independent:

• cMCP and cA2A, described above.
• Framework adapters in agentrust-io/integrations for NVIDIA OpenShell (tested against v0.0.105), Google ADK, LangChain, LlamaIndex, OpenAI Agents SDK and OpenTelemetry GenAI.
• Agent Governance Toolkit (microsoft/agent-governance-toolkit). ADR 0032 and trace_sink.py emit TRACE v0.1 records. The ADR and sink were authored by the TRACE Project Lead.

No production deployment is claimed in this proposal. ADOPTERS.md is maintained by adopters themselves. Its one entry, added by Sip Your Drink Ltd for Bernstein on 20 September in trace-spec#378, reports Level 0 use with no hardware attestation and no third-party relying party.

Technical Committee Sponsor (if identified)

None identified.

GitHub Repository URL

https://github.com/agentrust-io/trace-spec

License

Specification text and schema: Community Specification License 1.0. Code, SDK, tests and examples: Apache-2.0. Documentation: CC BY 4.0. See Additional Information.

Governance Model

Established as "TRACE Specification, a Series of LF Projects, LLC", governed by GOVERNANCE.md under the Community Specification framework, adopted in August 2026 with the LF standards team. Governance transitions to a Technical Steering Committee under CHARTER.md when the technical charter takes effect.

• Roles: Contributor, Reviewer, Maintainer, Project Lead, with published advancement criteria.
• Consensus is determined by the Project Lead and documented. Where consensus cannot be determined, Maintainers vote by majority, two-thirds for breaking changes.
• Due-process requirements modelled on ANSI Essential Requirements: openness, lack of dominance, balance, consideration of objections, and an appeal route.
• Specifications move through Pre-Draft, Draft, Final and Deprecated. Final versions are additive only; a breaking change requires one of four stated conditions, a 30-day minimum comment period, and a backward-compatibility statement.
• Sponsorship and affiliation confer no specification authority.

CI/CD & Release Workflow

• CI (GitHub Actions, every PR and push to main): ruff, mypy, pytest with coverage on Python 3.11 and 3.12, and a house-style check. On main on 15 October 2026 the suite ran 4,033 passing tests, with 48 skipped. Separate workflows run CodeQL, OpenSSF Scorecard, SBOM generation, actionlint, and a runtime-evidence job. A maintainer-approval status check runs on every pull request from a non-maintainer.
• Releases are tag-driven. publish.yml builds and publishes to PyPI through OIDC trusted publishing, with no stored token, and third-party actions are pinned to commit SHAs.
• Cadence: 13 releases of agentrust-trace between 5 June and 25 September 2026 (0.1.0 to 0.11.0). agentrust-trace-tests is at 0.6.2.
• The conformance suite moved into trace-spec/conformance on 2 October 2026 (trace-spec#455) and runs in its own Conformance CI workflow on the same pattern.

Public-Facing Contribution Process for Specifications

Documented in CONTRIBUTING.md.

• A normative change opens as an issue from the Spec change proposal template.
• Minimum comment periods: 5 business days, or 30 days for anything touching wire format, algorithms or required fields.
• Normative text is accepted with an organizational sponsor willing to implement and maintain it. A Maintainer can carry an unsponsored proposal, and it is not rejected for lacking one.
• Changed normative text is marked in the PR and recorded in CHANGELOG.md.
• Editorial changes, examples, conformance tests and informative crosswalks need no sponsor.
• All commits carry a DCO sign-off, and specification contributions are made under the Community Specification CLA.

Publicly Accessible Issue Tracker

• https://github.com/agentrust-io/trace-spec/issues

External Project Dependencies

Runtime dependencies of agentrust-trace 0.11.0:

rfc3986-validator is used for URI format checking in place of jsonschema[format], which pulls in the GPLv3 rfc3987.

Maintainers & Contributors

Rishabh Poddar and Aaron Fulkerson, the former Spec Editors, are listed as Emeritus in MAINTAINERS.md.

Since 14 June 2026:

• 290 pull requests have merged, excluding Dependabot: 165 from the Project Lead and 125 from 27 other accounts.
• Other contributors with a stated affiliation include Proofpane, Altru.dev, Robert Bosch GmbH and Agent Passport System.
• 118 issues were opened, 84 of them by 28 accounts other than the Project Lead.

MAINTAINERS.md states an open call for maintainers from independent organizations, particularly silicon vendors, cloud providers and regulated-industry deployers.

Leadership Team & Decision Process

Leadership is the Project Lead and the Repository Maintainers listed above. Reviewers can approve pull requests but cannot merge breaking specification changes without Project Lead approval. Decisions follow the consensus process in GOVERNANCE.md:

• The Project Lead determines and documents consensus.
• Where consensus cannot be determined, Maintainers vote by majority, and breaking changes need two-thirds.
• Maintainers disclose commercial interest in a proposal on the PR before reviewing it.
• Maintainers elect a successor Project Lead if the post is vacant for 30 days.
• Vendor-co-authored platform annexes are informative and reviewed by the vendor author plus one Maintainer.

Roadmap

ROADMAP.md. Next, v0.3:

• Normative MCP and A2A profiles.
• A claim for agent memory and persistent state.
• An encrypted-claims envelope (JWE or COSE-Encrypt).
• A MITRE ATLAS crosswalk.
• Co-authored vendor annexes for NVIDIA NRAS, Intel Trust Authority, AMD CoRIM, Azure MAA and GCP Confidential Space.

v1.0 (2027) covers:

• TSC governance.
• A post-quantum signature profile.
• A canonical profile URI assigned by the standards home.
• Verification libraries in TypeScript, Go and Rust.

Security

• Private reporting through GitHub Security Advisories, per SECURITY.md.
• Response targets: 24 hours for a forgeable record or broken verification chain, with a 7-day fix target; 48 hours for a verification bypass, with 14 days.
• Published advisory: GHSA-vc4p-h84j-7qxj (a cnf.jwk confirmation key could carry private key material), fixed in 0.10.0.
• Automated checks: CodeQL and OpenSSF Scorecard run in CI.
• Not yet in place: an OpenSSF Best Practices badge.
• Documented limits: LIMITATIONS.md lists what a record does not prevent: operator-forged Level 0 records, replay, policy correctness, and signing-key compromise after issuance.

Website URL

https://trace.agentrust-io.com

Documented Governance Practices (if any)

GOVERNANCE.md, CONTRIBUTING.md, MAINTAINERS.md, CHARTER.md, Governance/Scope.md, ANTITRUST.md, CODE_OF_CONDUCT.md, SPONSORS.md, all in the repository root or Governance/.

Links to Social Media Accounts

Discord: https://discord.gg/grgzFEHgkj. GitHub Discussions: https://github.com/orgs/agentrust-io/discussions. The project has no dedicated social media accounts.

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the AAIF.

Details of Existing Financial Sponsorship

AgenTrust is an independent open-source project. No company funds, owns or directs it; contributions are voluntary. OPAQUE Systems sponsored early development until October 2026. There is no cash sponsorship. See SPONSORS.md.

Infrastructure Needs or Requests

Standard Sandbox infrastructure:

• GitHub Actions at current volume.
• PyPI trusted-publisher configuration for agentrust-trace and agentrust-trace-tests.

The documentation site runs on GitHub Pages at trace.agentrust-io.com, with the conformance documentation at trace.agentrust-io.com/conformance/ (tests.agentrust-io.com redirects there). That is a subdomain of a domain that also serves other projects, and the Discord server is shared with them too. We would move documentation to an AAIF-controlled domain and move discussion into AAIF channels, and not transfer either shared asset.

Additional Information

Stage requested: Sandbox.

Contributing entity: TRACE Specification, a Series of LF Projects, LLC, which holds the project under the contribution agreement executed on 17 August 2026. Imran Siddique signs as TRACE Project Lead. OPAQUE Systems, named as contributor when this proposal was filed, wound down on 12 October 2026 and is no longer the contributor or sponsor.

Scope of this proposal: agentrust-io/trace-spec, including the conformance suite in conformance/ (published as agentrust-trace-tests), consolidated there from agentrust-io/trace-tests on 2 October 2026. agentrust-io/trace-tests is archived. The transparency registry (agentrust-io/trace-registry) is operated separately and is not part of this proposal.

Licensing. Specification text and the normative schema are under the Community Specification License 1.0. It was adopted in August 2026 on the recommendation of the Linux Foundation's standards team during formation of the LF Projects series. Section 4 of the Project Proposal Process accepts an open specification licence alongside OSI-approved permissive licences. All code is Apache-2.0. Patent terms are those of Section 2 of the Community Specification License 1.0: each contributor grants a royalty-free licence to its Necessary Claims for implementations, and no Exclusion Notices are recorded in Governance/Notices.md. There is no separate company patent grant. If the TC prefers Apache-2.0 for specification text, as MCP has adopted, we are open to that change, which requires contributor consent under the current CLA.

Sandbox thesis.

Who uses it. Producers sit where an agent's actions become observable: MCP gateways, A2A peers, sandbox runtimes, orchestrators, governance toolkits. Consumers are whoever has to accept the result without access to the producer's systems: an auditor, a counterparty receiving delegated work, a customer's security team, a regulator. The format exists for the consumer. A record only the producer's own tooling can read is a log. With TRACE, a relying party can run trace-tests, or write a verifier from the specification, and reach the same verdict as the producer.

Why neutral governance matters before adoption settles. Signed records are durable. Once a producer emits records in a given layout, relying parties archive them, and changing the layout strands the archive. TRACE reached that point at three months old. The project now treats new versions as additive only. One consequence: the delegation block carries a single parent_record_hash, so fan-in delegation is already a breaking change and no longer a cheap one. The implementations listed above are fixing the field layout now. This is the lifecycle policy's first Sandbox example: a protocol whose adoption signal is whether others implement against it.

There is a second reason, particular to evidence. A relying party has little reason to trust a record format governed by the vendor whose runtime produced the record. The LF Projects series already holds TRACE's IP neutrally. AAIF adds the community that builds the producers, and the v0.3 MCP and A2A profiles cannot be settled well without maintainers of those protocols reviewing them.

What would justify Growth, in order of weight:

1. Production use by two unaffiliated organizations, entered in ADOPTERS.md by those organizations.
2. Normative MCP and A2A profiles merged, each reviewed by at least one maintainer of the protocol it binds to.
3. A verifier in a language other than Python, written from the specification by someone outside the maintainer team, passing trace-tests.
4. Named committers from at least two organizations. Besides the Project Lead, two Repository Maintainers hold commit rights today (Louie Lu of Proofpane, and Rajnish Tiwari), and contributors other than the Project Lead account for 125 of 290 merged pull requests since June.

Current limits.

• The reference library is Python only.
• The Project Lead authored most merged changes.
• verify_record() checks profile, schema, signature over the canonical form, freshness and, when given a source, revocation. It does not appraise hardware quotes: that appraisal is implemented in cMCP and agent-manifest, both run against genuine hardware quotes. A Level 1 acceptance policy needs one of those or an equivalent appraiser, plus a trusted binding to the signer.
• The SAGE bridge maintainer flags a gateway-key trust limitation: the cMCP claim path checks signatures and policy hashes, but the gateway key is unanchored unless the verifier pins it through verify_trace_claim(..., trusted_public_key_hex=...). An unpinned valid signature does not establish the claimed agent's identity or hardware trust. This proposal does not claim that the bridge establishes Level 1 or that key pinning alone provides hardware-evidence appraisal.

Application contact name(s) and email(s)

Imran Siddique, [email protected]

Contributing or sponsoring entity signatory information

If an organization: