]>

george.g@tuta.io

Security Internet Engineering Task Force AI agent audit tamper-evident witness BLAKE3 compliance EU AI Act SCITT supply chain This document specifies the COGITATOR Witness Protocol -- a scheme for producing cryptographically verifiable, tamper-evident records of AI agent execution. A conforming implementation produces a single witness root value that any third party can independently recompute from the same inputs to verify the record was not altered after the fact. The protocol is implementation-agnostic. The reference implementation is COGITATOR (Rust), but any language or framework can produce conforming witness bundles. This document also describes how the COGITATOR Witness Protocol relates to the IETF SCITT architecture, with which it is designed to be used as a payload inside SCITT Signed Statements.

Introduction AI agents deployed in regulated or high-stakes environments issue tool calls with real-world consequences. Existing audit approaches -- log ingestion, post-hoc summaries, model cards -- are reconstructive. They describe what probably happened, not what provably happened. Logs are mutable. Post-hoc summaries are interpretations. The COGITATOR Witness Protocol takes the position that agent execution should be as auditable as a compiled binary in a reproducible build system. The witness root is the runtime equivalent of a content-addressed store path: a cryptographic commitment that ties a specific output to a specific, verifiable execution. This specification is intended to complement, not replace, the SCITT architecture (draft-ietf-scitt-architecture). SCITT provides the outer envelope: a Signed Statement registered on a Transparency Service with a verifiable Receipt. The COGITATOR Witness Protocol provides the inner payload: a structured, hash-chained record of what the agent did, attempted, and was blocked from doing.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here.

Definitions

Run

A single end-to-end execution of an agent against a set of inputs.

Tool call

A discrete action dispatched by the agent to an external or internal tool.

Phantom entry

A record of a tool call that was intercepted and blocked before dispatch.

Witness root

A single BLAKE3 hex digest committing the entire run record.

Policy digest

A SHA-256 hex digest of the policy file in effect during the run.

Canonical JSON

JSON serialised according to RFC 8785 (deterministic key ordering, no insignificant whitespace).

Witness bundle

The complete set of artefact files for a single run.

Signed Statement

As defined in draft-ietf-scitt-architecture: a COSE-signed envelope carrying a payload and subject claim, registered on a SCITT Transparency Service.

Receipt

As defined in draft-ietf-scitt-architecture: a proof of inclusion issued by a Transparency Service confirming a Signed Statement was registered on its ledger.

Witness Bundle Structure A conforming witness bundle MUST contain the following files: / +-- agent_trace.json # Agent steps: inputs, tool requests, outputs +-- tool_transcript.json # All tool calls (real and phantom) with outcomes +-- chaos_profile.json # Fault injection schedule (may be empty) +-- drift_report.json # Replay mismatch report (empty if no drift) +-- hash_chain.txt # Per-call BLAKE3 hashes, one per line +-- meta.json # Witnessed metadata +-- witness_manifest.json # Per-file hashes and bundle hash +-- witness_root.txt # Single hex string -- the tamper-evident root ]]> All JSON files MUST be serialised as RFC 8785 canonical JSON before hashing.

Schema Definitions

meta.json ", "agent_id": "", "seed": "", "policy_digest": "", "started_at": "", "finished_at": "", "cogitator_version": "" } ]]>

• schema_version MUST be 4 for this version of the protocol.
• policy_digest MUST be the SHA-256 hex digest of the policy file bytes, or null if no policy was in effect.
• seed MUST be the fixed random seed used for the run, enabling deterministic replay.

tool_transcript.json " } ]]>

ToolCall Object ", "tool_call_idx": "", "tool_name": "", "request": { }, "response": { }, "chaos_fault": "", "call_hash": "" } ]]> call_hash MUST be the BLAKE3 digest of the RFC 8785 canonical JSON of this object, with call_hash set to the empty string before hashing.

PhantomEntry Object ", "tool_call_idx": "", "tool_name": "", "request": { }, "disposition": "Blocked | Phantom", "rule_id": "", "reason": "", "entry_hash": "" } ]]>

• entry_hash MUST be the BLAKE3 digest of the RFC 8785 canonical JSON of this object, with entry_hash set to the empty string before hashing.
• disposition MUST be one of Blocked (tool call explicitly denied by policy) or Phantom (tool call silently observed but not dispatched).

hash_chain.txt A newline-delimited text file. Each line is the call_hash or entry_hash of one record in the order they were produced, interleaving real calls and phantom entries chronologically.

witness_manifest.json ", "tool_transcript.json": "", "chaos_profile.json": "", "drift_report.json": "", "hash_chain.txt": "", "meta.json": "" }, "bundle_hash": "" } ]]>

• Each file hash is the BLAKE3 digest of the raw file bytes.
• bundle_hash is the BLAKE3 digest of the RFC 8785 canonical JSON of the files object.

witness_root.txt A single line containing the BLAKE3 hex digest of the RFC 8785 canonical JSON of the complete witness_manifest.json object (including bundle_hash). This is the only value that needs to be published for a third party to verify the entire bundle.

Witness Root Computation The witness root is computed as follows:

1. Serialise each bundle file to RFC 8785 canonical JSON (or raw bytes for text files).
2. Compute BLAKE3(file_bytes) for each file to produce the files map.
3. Compute BLAKE3(RFC8785(files)) to produce bundle_hash.
4. Serialise witness_manifest.json including bundle_hash.
5. Compute BLAKE3(RFC8785(witness_manifest)) to produce witness_root.
6. Write witness_root as a single lowercase hex string to witness_root.txt.

A verifier replays steps 1-6 from the bundle files and asserts the computed root matches the published witness_root.txt.

Policy Protocol The policy layer is optional. If no policy file is provided, all tool calls are implicitly allowed and policy_digest MUST be null in both meta.json and tool_transcript.json. When a policy file is provided:

1. The policy file bytes MUST be SHA-256 digested before any run begins.
2. The digest MUST be committed to meta.json and tool_transcript.json before the first tool call.
3. Every tool call MUST be evaluated against the policy before dispatch.
4. Blocked or phantomed calls MUST produce a PhantomEntry committed to the witness chain.
5. The CallHistory MUST be updated after every verdict, including blocked calls.

Policy Verdicts

Verdict	Tool dispatched?	Agent receives	Chain entry
allow	Yes	Real tool response	ToolCall
block	No	blocked: true	PhantomEntry(Blocked)
phantom	No	blocked: true	PhantomEntry(Phantom)

Deterministic Replay A conforming implementation MUST support replay mode. Given the original agent_trace.json, chaos_profile.json, policy file (identified by policy_digest), and seed, a replay run MUST produce an identical witness_root to the original run. Any deviation MUST be reported as a DriftIssue in drift_report.json.

Conformance An implementation is conforming if:

1. It produces all required bundle files.
2. All JSON files are RFC 8785 canonical before hashing.
3. The witness root computation follows the algorithm in Section 6 exactly.
4. Phantom entries are produced for all blocked and phantomed calls.
5. The policy digest is committed before the first tool call when a policy is in effect.
6. Replay of the same inputs produces an identical witness root.

Integration with SCITT The COGITATOR Witness Protocol is designed to be used as a payload within the SCITT architecture (draft-ietf-scitt-architecture). The RECOMMENDED integration pattern is:

1. After a run completes, the witness bundle is produced as specified in this document.
2. The witness_root value and run_id from meta.json are embedded as the payload of a COSE-signed SCITT Signed Statement, with the subject header set to the agent identifier.
3. The Signed Statement is registered with a SCITT Transparency Service via the SCRAPI interface (draft-ietf-scitt-scrapi).
4. The resulting Receipt is stored alongside the witness bundle.

This provides two independently verifiable guarantees: the SCITT Receipt proves the witness root was registered at a specific time; the witness root proves the bundle contents have not been altered since computation.

Relation to Regulatory Frameworks The COGITATOR Witness Protocol is designed to address requirements of:

• EU AI Act (2024) Articles 12 and 9 -- tamper-evident record-keeping and risk management for high-risk AI.
• FCA AI and machine learning guidance -- audit trails for automated decision systems in financial services.
• NIST AI RMF (2023) -- traceability and accountability for AI systems.

Versioning This document describes protocol version 1.0, corresponding to schema_version 4 in bundle files. Breaking changes will increment both version numbers together.

IANA Considerations This document has no IANA actions.

Security Considerations The integrity guarantees of the witness root depend on the collision resistance of BLAKE3. As of the date of this document, BLAKE3 is not known to have practical collision attacks. The protocol does not provide confidentiality. Witness bundles may contain sensitive agent inputs and outputs. Implementors are responsible for access controls on bundle storage and transmission. The policy digest commits to the policy file bytes but does not authenticate the provenance of the policy file itself. Deployments requiring policy provenance guarantees should sign policy files independently before committing the digest.

Normative References Informative References