Define a cryptographic profile hook for Agent Trace records

[InvariantSystems]

Summary

We've been looking at how AIIR can bind or reference Agent Trace records for audit-grade workflows, and the recurring gap is not event vocabulary but independent digest reproducibility once vendor metadata and extensions are in play.

For Agent Trace use cases that need audit-grade tamper evidence, the specification should define a narrow, implementation-neutral cryptographic profile hook. The goal is not to require signing for every trace record. It is to make it possible for independent implementations to compute the same digest over the same record bytes and, when needed, attach or reference a signature or transparency entry.

If section 6.6 is the right home for vendor metadata or extension handling, this could fit there as an optional profile for records that need stronger integrity semantics.

Problem

Agent Trace records may be used in workflows where the trace is later reviewed by security teams, auditors, policy engines, or release gates. In those cases, metadata alone is not enough. Consumers need to know which fields were included in the digest, how those fields were serialized, which algorithms are allowed, and whether extension or vendor metadata is covered by the hash.

Without a defined profile hook, vendors can still add their own digests or signatures, but those proofs will be hard to compare across tools and hard for third-party verifiers to reproduce.

Proposal

An optional cryptographic profile mechanism should define, at minimum:

1. Hash input model: the exact set of fields included in the digest input.
2. Serialization or canonicalization: the deterministic bytes to hash.
3. Digest algorithm agility: a field or registry for algorithms such as SHA-256, plus rules for future algorithms.
4. Extension handling: whether vendor metadata is included, excluded, or profile-selected.
5. Test vectors: at least one canonical record, canonical byte string or equivalent representation, expected digest, and a negative vector.
6. Optional signature reference: a way to attach or reference signatures, envelopes, or transparency-log entries without requiring any one signing system.

The profile should be optional. Producers that only need portable event metadata can ignore it. Producers that need audit-grade evidence can emit it.

Non-Goals

• Do not require all Agent Trace records to be signed.
• Do not require one specific signing system, transparency log, or vendor.
• Do not require exposing prompts, hidden reasoning, model internals, or file contents.
• Do not make the core Agent Trace data model depend on any one implementation.

Existing Implementation Experience

AIIR is one public implementation that has worked through these questions in practice. It already publishes canonicalization rules, content-addressed IDs, SHA-256 digests with optional signing semantics, JSON schemas, and test vectors. The main lesson from that work is that the load-bearing distinction is between fields that are merely metadata and fields that are part of the digest input.

Acceptance Criteria

A good resolution would let an independent implementer answer these questions without contacting the original producer:

• Which bytes do I hash for this Agent Trace record?
• Which fields are excluded from the hash?
• Is vendor metadata covered by the digest?
• Which digest algorithm is in use?
• How do I verify the digest against a published test vector?
• If a signature is present, what is signed and where is the signature recorded?