The AI Forensics Audit Trail Specification
An open reference draft for tamper-evident, cryptographically-signed audit trails of autonomous AI agents — and the working draft behind what is now shipped in OCSF 1.9.0. The spec's core primitives, the attestation object and the record_integrity profile, were contributed upstream and are now part of the OCSF schema. The normative home for this work is OCSF; the AI Identity platform is the production reference implementation; the archived draft remains the historical record.
May 2026
Draft v1.0 published
Open reference draft released for public review under CC-BY-4.0.
Jul 2026
Contributed upstream
ocsf-schema#1661 merged: the attestation object + record_integrity profile enter the OCSF schema.
Aug 2026
Shipped in OCSF 1.9.0
Released in the OCSF 1.9.0 release. The OCSF schema is now the normative home.
Aug 2026
Draft archived
The spec repo is archived as the historical record; new schema work happens upstream.
The Spec at a Glance
Four pillars, one coherent schema
The spec organizes forensic primitives into four pillars. Each pillar maps to a specific question an auditor will ask after an incident.
| Pillar | The auditor's question | Spec capability |
|---|---|---|
| Identity | Who is this agent? | Per-agent API keys, lifecycle management, scoped credentials. |
| Policy | What is it allowed to do? | Fail-closed gateway, deny-by-default policy evaluation. |
| Compliance | Can we prove rules were followed? | DSSE-signed session attestations, HMAC-verifiable audit logs, automated compliance assessments. |
| Forensics | What happened, provably? | Hash-chained logs, incident replay, export, offline cryptographic verification. |
Built on Standards
Standards-track alignment
The spec profiles existing open standards rather than inventing new ones. It is not a competing schema — it is a forensic-grade composition. That approach is why it could graduate: the OCSF profile now lives upstream.
OCSF
Event envelopeThe spec's event envelope graduated upstream: the attestation object and record_integrity profile shipped in OCSF 1.9.0 (contributed via ocsf-schema#1661).
github.com/ocsf/ocsf-schema/releases/tag/v1.9.0 →
OpenTelemetry GenAI semconv
Span attributesThe spec profiles the GenAI semconv for span attributes, and the OTel-to-OCSF field mapping is published as a crosswalk with derived test vectors. Platform span emission is planned; correlation today rides a per-request ID exposed as OCSF metadata.correlation_uid.
github.com/open-telemetry/semantic-conventions/tree/main/docs/gen-ai →
MITRE ATLAS 2026
Threat taxonomyForensic events tag against ATLAS techniques (T0051 prompt injection, T0040 model theft, etc.) for SIEM correlation.
atlas.mitre.org/ →
SPIFFE / SPIRE
Workload identityPer-agent X.509-SVID or JWT-SVID identity binding optional; required for cross-trust-domain agent federation.
spiffe.io/ →
NIST AI RMF 1.0
Governance mappingAudit chain primitives map directly to MANAGE 4 (incident response) and MEASURE 2.7 (decision traceability).
www.nist.gov/itl/ai-risk-management-framework →
IETF Agent Identity Protocol (AIP) draft
Identity federationTracking the IETF AIP draft for future-proof cross-organization agent identity assertions.
datatracker.ietf.org/ →
§9.1 Capability Matrix
Per-provider logprob exposure
Token-level log-probabilities are the strongest forensic signal — they let a verifier replay sampling decisions deterministically. Not every provider exposes them. This matrix tracks the state of public APIs as of 2026-05.
| Provider | Logprobs | Detail | Forensic sufficiency |
|---|---|---|---|
| OpenAI | Yes | `logprobs` parameter returns top-N log-probabilities per token. Up to 5 alternatives via `top_logprobs`. | Yes |
| Anthropic | No (as of 2026-05) | No public logprob exposure on the Messages API. Forensic attestations rely on response provenance (model_id, system fingerprint, request_id) instead. | Partial |
| Google Gemini | Yes | `logprobs` and `responseLogprobs` available on the GenerateContent API. Up to 5 alternatives. | Yes |
| AWS Bedrock | Varies by model | Claude on Bedrock: no logprobs (parity with Anthropic direct). Other models: provider-dependent. | Partial |
| Self-hosted (vLLM, TGI, llama.cpp) | Yes | Full logprob distribution exposed. Strongest forensic signal — verifier can replay token-by-token sampling decisions. | Full |
See the full spec §9.1 for the verifier algorithm + fallback rules when logprobs are unavailable.
§9 Open Questions
What the draft left open
A specification that hides its uncertainty is not a standard — it's a marketing document. These questions were left open in v1.0 and remain on record in the archived draft. Follow-on work now happens upstream in the OCSF schema and on the AI Identity platform roadmap.
Per-provider logprob exposure
Anthropic and Bedrock-Claude do not expose token logprobs. Forensic attestations rely on response provenance (model_id, system fingerprint) — but this is weaker than logprob-backed replay. Provider API changes are now tracked against the AI Identity platform implementation.
Multimodal context capture
Image, audio, and video inputs are out of scope for v1.0. The draft sketched a v1.1 approach — capture content-hash + MIME + size rather than raw bytes, with optional vendor-specific perceptual hashes — now carried forward on the platform roadmap.
Cross-organization federation
Agent identity assertions across trust domains depend on IETF AIP draft maturity. v1.0 assumes a single-org trust domain; a federation profile was deferred pending the IETF work.
Vendor-hosted agent attestation
Agents running entirely inside vendor-hosted runtimes (Perplexity hosted agents, OpenAI Custom GPTs, Anthropic Claude Projects, Manus, Devin) cannot be intercepted by the gateway-proxy pattern — calls originate inside vendor infrastructure with no operator-controlled injection point. v1.0 supports operator-assertion only (declarative registration, manual artifact logging). The draft planned Level 0 declarative conformance plus a browser-side intercept profile, with vendor-API attestation hooks tracked behind that — work now carried forward on the AI Identity platform. The most strategically important unanswered piece of v1.0.
The work continues upstream
The draft did its job: its core primitives shipped in OCSF 1.9.0, and the spec repo is archived as the historical record. New schema work happens upstream in ocsf/ocsf-schema, and the AI Identity platform carries the production reference implementation. Want to shape what comes next against real deployments? Join the design partner cohort.
Shipped in OCSF 1.9.0 via ocsf-schema#1661 · Archived draft: forensic-audit-trail-spec · Draft license: CC-BY-4.0 (content) + Apache-2.0 (reference impl)