AI Agent Audit Trail Schema: 15 Fields for Reconstruction

What an AI agent audit trail can and cannot prove

It can reconstruct recorded workflow history

A dependable trail can show which recorded identity started a run, which released components and policies were evaluated, what evidence references were available, which decisions and tool attempts occurred, and what state the target system later reported. That supports investigation, operational review and accountable correction.

It cannot prove every recorded assertion is true

A signed event can still contain an incorrect model conclusion, malicious tool response, compromised identity or stale business fact. Provenance and integrity help establish what was recorded and whether it changed; domain owners must still validate the substance.

It cannot replace authoritative business state

An HTTP response or agent message is not necessarily the final business outcome. For consequential writes, preserve an operation identity and reconcile the target system's authoritative state. Record UNKNOWN or PARTIAL honestly when the commit boundary cannot yet be established.

It is not automatically a lawful evidence store

An audit purpose does not authorize unrestricted collection. Data minimization, purpose limitation, access control, regional handling, contractual terms, legal hold and deletion require organization-specific review. A useful schema explicitly supports protected references and retention classes instead of requiring raw content everywhere.

Separate a stable event envelope from typed payloads

Put universal correlation fields in the envelope

Every event needs the same core identity, tenant, workflow, run, event class, schema version, occurrence time, ingestion time, producer, causation, trace, sensitivity and integrity metadata. A common envelope lets collectors reject malformed records and investigators join event families consistently.

Put event-specific facts in a validated payload

A policy decision needs evaluated identity, rule version and disposition. A tool attempt needs tool, operation, target, protected parameters and attempt lineage. A correction needs the superseded event, reason and reviewer. Separate schemas prevent one enormous nullable record from hiding missing evidence.

Version schemas without silently changing meaning

Give the envelope and each payload type an immutable schema version. Document compatible additions, breaking changes, default behavior and migration. Historical parsers should not reinterpret an old field under a new definition merely because its name stayed the same.

Keep large or sensitive content in its governed source

Record a stable object identifier, version, classification, access result and protected digest rather than copying whole documents, message bodies or attachments. The reference must be resolvable by an authorized investigator for the permitted retention period—or explicitly record that the source was lawfully deleted.

Define the event taxonomy before choosing storage

Run and delegation events

Record the start, end, cancellation, parent-child relationship and delegated subrun. This makes a task graph visible and prevents delegated work or restarted runs from appearing as unrelated actions.

Evidence-access events

Record which source object and version was requested, whether access was permitted, which bounded segment was returned and its classification. Do not embed untrusted content as executable log instructions or render it unsafely in an investigator console.

Policy and human-decision events

Record evaluated identity, policy bundle, inputs, result, reason, approval object, approver authority, expiry, rejection, revocation and requested changes. Page096 defines the gate; this event family preserves the decision evidence.

Tool-attempt and target-observation events

Separate planned, authorized, attempted, acknowledged and reconciled states. Give each logical operation a stable ID and every physical attempt its own ID so retries remain visible without being mistaken for distinct business intent.

Correction and review events

Do not overwrite a wrong event in place. Append a correction that references the original, explains the error, identifies the authorized reviewer and states whether derived views must be recomputed. Preserve both the historical observation and current interpretation.

Access, export, retention and deletion events

The audit trail is sensitive infrastructure. Record privileged reads, searches, bulk exports, hold changes, retention expiry, deletion execution and verification. A deletion tombstone may preserve non-sensitive proof that governed deletion occurred without retaining the deleted content.

Field 1: event ID and schema identity

Purpose

Identify one immutable recorded event and the exact envelope and payload definitions used to interpret it. Corrections, alerts, exports and review findings reference this event rather than relying on row order or a mutable database key.

Record

Store a globally unique event ID within the organization's collision model, envelope schema name and version, payload type and version, producer ID and creation result. Choose a generation method that works during partitions and document its ordering properties rather than assuming every identifier is chronological.

Exclude or protect

Do not encode email addresses, customer names, secret values or meaningful business payloads inside the identifier. Avoid sequential identifiers exposed across tenants when they reveal volume or allow enumeration.

Validation test

Inject duplicate IDs, unknown schema versions, wrong payload types, invalid characters and a correction referencing a nonexistent event. The collector should reject, quarantine or route each case according to a documented rule without silently coercing it.

Field 2: occurrence, observation and ingestion time

Purpose

Distinguish when an action happened, when a component observed it and when the audit service accepted the record. This exposes delay, clock skew, offline buffering and out-of-order delivery instead of presenting ingestion order as historical truth.

Record

Use UTC timestamps with explicit precision, the relevant source timezone for business interpretation, producer clock source, ingestion time and an optional monotonic or local sequence. Preserve uncertainty when the source cannot supply an exact occurrence time.

Exclude or protect

Do not infer exact human behavior from coarse timestamps or hide known clock error. Location-bearing timezones and shift data can be sensitive; retain only what the stated investigation and business purpose requires.

Validation test

Simulate skewed clocks, daylight-saving transitions, late batches, identical timestamps, missing occurrence time and future-dated records. Reconstruction should use causation and sequence evidence without rewriting the original time.

Field 3: tenant, workflow and run identity

Purpose

Place an event inside the correct isolation boundary, released workflow definition and execution instance. This prevents similar agent names or shared infrastructure from merging unrelated customer or business histories.

Record

Store tenant or organization scope, environment, workflow ID and immutable version, run ID, parent run, delegated child run and trigger type. Use pseudonymous identifiers where direct identity is unnecessary, but keep the authorized resolution path documented.

Exclude or protect

Never rely on a display name as the only boundary. Do not place another tenant's identifiers or business labels in a broadly readable index, and do not treat a client-supplied tenant field as trusted without producer authentication.

Validation test

Attempt cross-tenant collisions, a missing workflow version, reused run IDs, an orphan child and a forged tenant field. The pipeline should enforce isolation and preserve a visible rejected-event record without leaking the foreign value.

Field 4: causation, correlation and trace context

Purpose

Connect a request through planners, services, queues, tools and target observations. Trace context improves distributed correlation, while explicit causation identifies which prior event authorized or triggered the next state transition.

Record

Store parent event, cause event, logical operation ID, attempt ID, trace ID and span ID where supported. Keep trace context interoperable and validate incoming values. Treat sampling flags and vendor baggage as untrusted hints, not authorization.

Exclude or protect

Do not place credentials, personal data or business authorization in trace baggage. Do not assume a shared trace ID proves two events have the same owner, tenant, intent or integrity status.

Validation test

Break propagation at a queue boundary, replay an old trace, supply an invalid parent, create two attempts for one operation and inject oversized baggage. The graph should expose gaps and reject unsafe metadata while keeping the business operation distinguishable.

Field 5: agent, model and configuration version

Purpose

Identify the deployed agent role and the exact released model routing and configuration that produced or requested an action. A mutable agent display name or marketing model family cannot support reliable reconstruction.

Record

Store agent deployment ID, role version, service principal, model/provider release identifier, routing decision, relevant inference-configuration version, retrieval configuration, enabled feature flags and deployment artifact digest. Record the effective configuration, not only the intended one.

Exclude or protect

Do not log provider credentials, hidden secrets or unnecessary full configuration blobs. Restrict security-sensitive implementation details and reference a controlled release manifest with an integrity value.

Validation test

Switch model routes mid-run, roll back an agent, omit a feature-flag version, use an unknown deployment digest and delegate to another agent. Reviewers should reconstruct the effective component for every material event.

Field 6: requester, effective identity and delegation chain

Purpose

Show which authenticated person, service, schedule or upstream system initiated or materially changed the run, and under whose authority the action occurred. Effective identity matters when shared sessions, service accounts or delegation are involved.

Record

Store tenant-scoped requester ID, identity type, authenticated session reference, service principal, effective role, delegated-from chain, authentication assurance and relevant consent or authority reference. Resolve mutable directory attributes through versioned decisions rather than copying a current profile later.

Exclude or protect

Minimize names, addresses, device details and direct personal attributes. Never store passwords, session cookies, bearer tokens or authentication secrets. Restrict identity-resolution tables separately from the general event index.

Validation test

Exercise revoked users, changed roles, shared accounts, delegated sessions, scheduled triggers, missing authentication and a service acting across tenants. The trail should preserve the evaluated identity and failed authority check without exposing credentials.

Field 7: prompt, instruction and policy versions

Purpose

Identify the trusted instruction and deterministic policy set that constrained a decision. This helps distinguish changed behavior caused by content, configuration or policy and prevents investigators from reconstructing an old run with today's instructions.

Record

Store controlled prompt or instruction artifact IDs, immutable versions or digests, policy bundle and rule versions, evaluation engine version and the effective decision. Link to protected originals under separate access control where exact text is legitimately required.

Exclude or protect

Do not copy system prompts containing secrets, defensive logic or proprietary content into a general-purpose log. User and retrieved text are inputs, not trusted policy, even when they contain language that resembles instructions.

Validation test

Change a policy between preparation and execution, supply a missing prompt version, inject a false policy label through retrieved content and roll back a rule bundle. The record should reveal which trusted artifacts were actually evaluated.

Field 8: input provenance and source-state reference

Purpose

Identify the exact version of user input and authoritative business records available to the workflow. Without provenance, a reviewer cannot tell whether a result used the current contract, an obsolete account state or an attachment added after approval.

Record

Store source-system ID, object ID, object version or change token, bounded segment reference, access decision, classification, collection purpose, observation time and protected digest when appropriate. Preserve source precedence when several records disagree.

Exclude or protect

Avoid copying complete documents, message histories and attachments unless a reviewed requirement demands it. Separate content from metadata, minimize personal data and record lawful deletion or source unavailability without resurrecting deleted content.

Validation test

Use stale versions, changed attachments, conflicting sources, deleted objects, denied access and a forged source label. Reconstruction should surface the exact observed version and uncertainty rather than substituting current state.

Field 9: retrieved evidence and transformation lineage

Purpose

Preserve which query, filters, ranked results, chunks and transformations informed a model or deterministic decision. A document URL alone is often insufficient when pages change or a table needs adjacent context.

Record

Store retrieval request ID, query or protected representation, index and retriever versions, source object/version, chunk or region coordinates, ranking position, access result, transformation steps and bounded adjacent context reference. Mark generated summaries as derived evidence.

Exclude or protect

Do not store unrestricted search results or embedded secrets by default. Sanitize control characters and active content before indexing or rendering. Never allow retrieved text to choose the audit destination, retention rule or trusted event fields.

Validation test

Inject conflicting chunks, a changed page, a poisoned document, table cells without headers, inaccessible evidence and an omitted transformation. A reviewer should reproduce the evidence set or see an explicit gap.

Field 10: authorization and human-decision reference

Purpose

Show which identity and policy decision authorized a proposed action and, where required, which human decision applied. This preserves the Page096 gate outcome without confusing notification, acknowledgement and approval.

Record

Store policy-decision ID, evaluated identity, requested scope, disposition, rule/version, decision-object digest, approver ID and effective role, decision, reason, expiry, revocation and quorum position. Bind it to one exact action object.

Exclude or protect

Do not store authentication secrets or expose sensitive reviewer notes broadly. Do not interpret silence, notification delivery or an emoji reaction as approval unless a documented authoritative system defines and validates that structured decision.

Validation test

Use a stale approval, wrong role, expired decision, revoked authority, changed payload, incomplete quorum and one delegated identity in two separated roles. The trail should show the denial and prevent a valid-looking execution link.

Field 11: requested action, target and operation identity

Purpose

Describe the business intent and exact target of a consequential operation independently from any physical request attempt. This keeps retry attempts attached to one intent and distinguishes planning from authorization, sending and effect.

Record

Store tool and connector version, operation name, target type and protected target identifier, normalized action-object digest, logical operation ID, idempotency scope where supported, requested effect and reversibility class. Give each attempt a separate identifier.

Exclude or protect

Do not place credentials in tool identifiers or URLs. Minimize direct customer or employee identifiers and avoid treating provider request IDs as organization-wide idempotency or proof of business outcome.

Validation test

Create two attempts for one operation, two operations with similar payloads, a changed recipient, unsupported idempotency, target redirection and an unknown commit. The event graph should preserve intent and attempts without inventing success.

Field 12: validated parameters, data class and protected digest

Purpose

Preserve enough information to establish what was validated and authorized while keeping secrets and unnecessary content outside the general log. The representation must support comparison across preparation, approval and execution.

Record

Store a canonical parameter-schema version, allow-listed non-sensitive parameters, classification, redaction profile, protected object reference and an access-controlled or keyed digest where its threat model is documented. Record validation failures before transformation.

Exclude or protect

Never write passwords, access tokens, private keys, session IDs, database connection strings or unrestricted personal and proprietary content directly. A plain unsalted hash of a low-entropy secret may still be reversible and must not be treated as safe redaction.

Validation test

Inject token-shaped values, CR/LF log injection, oversized fields, invalid encoding, cross-tenant identifiers and a one-character material change. The collector should sanitize or quarantine safely while preserving evidence that validation failed.

Field 13: before state, after state and authoritative observation

Purpose

Show what the target system reported before and after a consequential write. This separates an API acknowledgement from verified business state and supports recovery when a request times out after a possible commit.

Record

Store bounded before-state version, expected invariant, target-system operation reference, acknowledgement, observation method, after-state version, reconciliation result and observation time. Use protected references when snapshots contain sensitive data.

Exclude or protect

Do not duplicate an entire customer or financial record merely to prove one field changed. Do not infer after state solely from agent output, transport status or a provider's generic success string.

Validation test

Exercise no-op success, partial write, asynchronous completion, timeout after commit, eventual consistency, external reversal and unavailable readback. Preserve UNKNOWN, PARTIAL, DIVERGED or RECONCILED until evidence supports closure.

Field 14: outcome, error and retry lineage

Purpose

Record how every physical attempt ended and why another attempt did or did not occur. This supports failure analysis without collapsing transport, provider and business results into one ambiguous status.

Record

Store attempt number, start and end, normalized transport result, provider result, business-result state, error class, safe diagnostic reference, retry decision, retry owner, backoff policy version, parent attempt and final reconciliation link.

Exclude or protect

Do not dump raw stack traces, headers or bodies into broadly accessible storage without sanitization. Never let error text supplied by a tool instruct the agent or log processor to retry, reveal secrets or change policy.

Validation test

Inject rate limits, validation failures, authentication denial, timeout before send, timeout after commit, duplicate acknowledgement, partial effects and hostile error text. The lineage should show one logical operation and every controlled attempt.

Field 15: review, correction, access and retention lifecycle

Purpose

Preserve how authorized people interpreted or corrected the record and how the record itself was accessed, held, exported, expired or deleted. Audit evidence without a governed lifecycle can become an unbounded surveillance and breach risk.

Record

Store reviewer identity and role, disposition, linked findings, superseded event, correction reason, derived-view rebuild, access/export purpose, retention class, deadline, legal or investigation hold, deletion request, deletion verification and a non-sensitive tombstone.

Exclude or protect

Do not silently overwrite history, extend retention by convenience or use an audit export as an uncontrolled working copy. Reviewer notes, investigation subjects and legal-hold details need narrower access than routine operational events.

Validation test

Attempt an in-place edit, unauthorized export, premature deletion, expired hold, missing correction link and failure to delete referenced protected content. Independent review should reconstruct both the original event and authorized current interpretation.

Read an illustrative event envelope safely

Example: a policy decision event

The following is a fictional shape, not a required OpenMax API or an industry standard. Identifiers use reserved .invalid context, values are synthetic, and the object deliberately references protected content instead of reproducing it.

{
  "event_id": "evt_01K7FICTITIOUS",
  "schema": "agent.audit.envelope/1.0",
  "event_type": "policy.decision/2.1",
  "occurred_at": "2026-09-06T02:14:05.381Z",
  "observed_at": "2026-09-06T02:14:05.427Z",
  "tenant_ref": "tenant_demo_invalid",
  "workflow_ref": "lantern-ledger@4.2",
  "run_id": "run_W17",
  "cause_event_id": "evt_W17_evidence_ready",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "agent_release": "A12@3.4",
  "effective_requester": "principal_demo_04",
  "policy_ref": "P09@6",
  "decision_object_ref": "protected://objects.invalid/W17/v3",
  "decision_object_digest": "keyed-digest:demo-not-a-secret",
  "disposition": "REVIEW_REQUIRED",
  "data_class": "INTERNAL_SYNTHETIC",
  "retention_class": "RC04-EXERCISE"
}

What the envelope establishes

It establishes recorded event identity, schema interpretation, time, isolation scope, run, causation, trace correlation, released agent, effective requester, policy version, protected decision-object reference, disposition and lifecycle class. It does not prove the referenced content is accurate or that a later action succeeded.

What remains in typed follow-up events

A human-decision event records reviewer authority and decision. A tool-attempt event records operation and attempt identity. A target-observation event records authoritative state. A correction event links new interpretation to the preserved original. Do not force every fact into the policy event.

Why this is not a copy-ready production schema

Identifier formats, digest methods, encryption, access, retention, regional routing, legal hold, event signing and storage architecture depend on the organization's threat model and obligations. Security, privacy, records, legal, audit and product owners must approve the real design.

Complete fictional reconstruction exercise: AL097

Frozen system and 48 workflow runs

Lantern Ledger is a fictional workflow at fictional Cedar Harbor Components. AL097 freezes agent A12, schema ES07, policy P09, identity directory ID09, evidence store EV06, execution broker EB06, clock K05, retention catalog RC04, event classes E01–E11 and reviewer guide RG04. W01–W48 contain synthetic identities, decisions, attempts and state references.

Attempts, reviews and veto failures

The 48 runs produce 72 tool-attempt rows and 48 independent reconstruction reviews. Forty pass the complete audit contract and eight fail. W22 puts a raw synthetic access-token-shaped value in the general log; W41 silently replaces an event instead of appending a correction. Both are predefined vetoes.

Downloads and release state

Use the editable AL097 audit-trail worksheet and complete AL097 run, attempt and review packet. Final state is NOT_RELEASED; production events 0, customer records 0, real secrets 0, external actions 0 and deployments 0.

Reproduce all seven AL097 metrics

Event-envelope completeness: 44/48 = 91.67%

Forty-four of 48 runs contain valid event, schema, tenant, workflow, run, time, producer, class and sensitivity envelope fields at every required material boundary. Four retain missing or inconsistent envelope evidence as failures.

Causal-lineage completeness: 42/48 = 87.50%

Forty-two runs connect parent, cause, operation, attempt and target-observation events without an unexplained gap. A shared timestamp or trace ID alone does not satisfy causation.

Identity-and-version coverage: 45/48 = 93.75%

Forty-five runs preserve effective requester, agent release, model/configuration, trusted instruction, policy and tool versions. Three use a mutable display name or omit an effective version.

Authorization-to-action binding: 41/48 = 85.42%

Forty-one runs bind the recorded policy or human decision to the exact action object and logical operation. Seven expose stale, incomplete or mismatched authorization evidence.

Authoritative-state reconciliation: 38/44 = 86.36%

Only 44 runs contain a consequential write requiring readback, so that is the denominator. Thirty-eight record a supported before/after or final authoritative observation; six remain unknown, partial or wrongly inferred from acknowledgement.

Redaction compliance: 46/48 = 95.83%

Forty-six runs keep prohibited secret-shaped and unnecessary sensitive content out of the general event store. W22 is a veto failure even though the aggregate percentage appears high.

Correction-and-retention closure: 40/48 = 83.33%

Forty runs preserve correction lineage, review disposition, retention class, hold status and verified lifecycle closure where required. W41 silently overwrites history and blocks release.

Implement the schema as a controlled logging program

1. Map decisions, actions and reconstruction questions

For each workflow, ask what an investigator must establish: origin, inputs, policy, approval, action, attempt, commit, final state, correction and lifecycle. Begin with manual reconstruction of a few representative runs, reuse trustworthy native audit events, add deterministic collection automation for stable boundaries, and introduce agent-specific correlation only where delegated reasoning or cross-system action creates a real gap. Emit events at those boundaries rather than logging every internal token.

2. Define the envelope, typed payloads and registry

Publish owned schema definitions, compatibility rules, required fields, classifications and example fixtures. Register producers and event types; reject unknown or malformed records into a monitored safe path rather than guessing their meaning.

3. Protect collection, storage, query and export

Authenticate producers, encrypt transport and storage, restrict writers, segment readers, detect alteration, monitor gaps and control bulk exports. Treat audit administrators and analytics pipelines as privileged subjects whose access also needs evidence.

4. Test reconstruction, privacy and failure behavior

Rebuild normal and failed runs across service boundaries. Inject late events, clock skew, missing parents, duplicate IDs, hostile strings, secrets, cross-tenant values, unknown commits, corrections, holds and deletions. Verify both usable evidence and data minimization.

5. Review, release narrowly and rerun after change

Security, privacy, records/legal, audit, product and operations owners review failures and vetoes. Start with a bounded workflow and monitored retention. Rerun after schema, producer, agent, model, policy, tool, identity, target system or legal requirement changes.

Human review and operational governance

Assign accountable owners across the lifecycle

Schema owners define meaning and compatibility; security and privacy owners control threat and data scope; records/legal owners set retention and hold; platform owners operate availability; workflow owners validate business reconstruction. One team cannot silently assume all five roles.

Review gaps and dangerous successes

Sample missing sequences, unusual exports, redaction failures, unresolvable references, clock anomalies, repeated corrections and apparently successful actions without authoritative results. Average completeness can hide a single exposed secret or overwritten event.

Preserve a safe degraded state

When audit collection is unavailable, decide which low-risk work may continue, which consequential actions must stop and how buffered events are protected and reconciled. Never let the agent disable evidence collection because a log write is inconvenient.

How OpenMax can support traceable agent work

Suitable workflow-history role

Where configured, OpenMax can help associate agent roles, shared context, permitted tool activity, approvals and human review within an operating workflow. Current product documentation supports this bounded coordination context, not an undocumented universal audit-storage guarantee.

Authoritative controls remain external and shared

Identity providers, policy systems, target business applications, evidence stores, retention catalogs and security monitoring remain authoritative for their domains. Integrations must collect their results and apply organization-specific access, integrity and deletion controls.

Simpler logging may fit narrow deterministic work

For a single application with fixed events and no agent delegation, an existing structured logger and native audit facility may be easier to maintain. Add agent-oriented correlation only where multi-step context, decisions or cross-system effects create a real reconstruction need.

Limits of an AI agent audit trail

More data can reduce safety and usefulness

Indiscriminate transcripts increase exposure, storage cost, investigation noise and deletion complexity. Record the minimum evidence needed for a declared purpose and keep sensitive source content under its stronger existing controls.

Tamper-evident does not mean infallible

Integrity controls can reveal alteration, but a compromised producer may create a well-formed false event. Independent target observations, producer authentication, cross-signal correlation and human review remain necessary.

Sampling creates explicit evidence gaps

Operational telemetry may be sampled for cost and performance. Consequential audit events need a deliberate recording policy; if sampling or loss occurs, record the limitation rather than presenting an incomplete trace as complete history.

Retention and deletion cannot use one universal number

Purpose, data class, jurisdiction, contract, litigation or investigation hold and source-system obligations affect lifecycle. This page supplies fields and tests, not a legal retention schedule.

Common audit-trail failures and repairs

Logging a narrative without identifiers

Failure: a readable summary lacks run, version, operation, cause and target state. Repair: emit typed events with stable correlation and preserve the summary only as a derived field.

Treating trace IDs as authorization

Failure: events sharing a trace are assumed to share tenant, intent or permission. Repair: validate tenant, effective identity, policy decision and action binding independently.

Copying raw secrets and private content

Failure: broad logs become a second sensitive database. Repair: classify fields, reject prohibited values, reference controlled sources, restrict export and verify deletion.

Equating acknowledgement with final state

Failure: a tool's success response closes the event graph. Repair: distinguish attempt, acknowledgement and authoritative observation; retain unknown or partial states until reconciled.

Correcting history by overwriting it

Failure: investigators cannot see what was originally recorded or why it changed. Repair: append a correction with reviewer, reason and supersession link, then rebuild derived views.

Implementation checklist and next steps

Before accepting an event producer

Verify producer identity, tenant isolation, schema version, field validation, time behavior, classification, secret rejection, integrity control, failure route and monitoring. Use synthetic adversarial fixtures before real data.

Before releasing a workflow

Reconstruct normal, rejected, expired, retried, partial, corrected, exported, held and deleted cases. Resolve all veto failures and obtain named security, privacy, records/legal, audit and product review.

During operation

Monitor missing sequences, ingestion delay, clock skew, schema rejection, redaction, unauthorized access, bulk export, integrity alerts, unresolved state, expired holds and deletion verification. Revalidate after material change.

Frequently asked questions (FAQ)

Should complete prompts and outputs be logged?

Only when a documented purpose, authority, access model and retention rule require them. Prefer released artifact references, classifications, bounded redacted excerpts or protected digests for sensitive content.

Is an append-only database enough?

No. Producer authentication, schema validation, tenant isolation, integrity monitoring, access and export controls, availability, correction semantics and governed retention are also required.

Are trace IDs and span IDs audit identifiers?

They are valuable correlation fields. They do not replace event, run, operation, attempt, identity, policy, approval or authoritative-result evidence.

Can an incorrect audit event be deleted?

Usually preserve the original and append a correction. Protected referenced content may still need lawful deletion; use a non-sensitive tombstone and follow approved records/legal policy.

How long should agent events be retained?

Set retention by documented purpose, data classification, jurisdiction, contract, operational need and legal or investigation hold. Do not use this guide as a universal period.

Can a complete exercise authorize production release?

No. AL097 is synthetic. Named owners, actual-system behavior, security/privacy review, legal and records decisions, load/availability evidence and accountable product approval remain necessary.

Where does OpenMax fit?

OpenMax can support structured coordination of roles, context, tools, approvals and review where configured. The organization's identity, policy, target, integrity, retention and evidence systems retain authority.

Sources and editorial method

OpenMax product context

• OpenMax — AI agent platform — roles, tools, permissions, logs, review and operating-workflow context.

Log-management and governance sources

• NIST SP 800-92 — Guide to Computer Security Log Management — final high-level enterprise log-management guidance published in 2006.
• NIST SP 800-92 Rev.1 — Cybersecurity Log Management Planning Guide — Initial Public Draft published in 2023; cited as planning context, not a final standard.
• NIST — Generative AI Profile — governance, privacy, security and content-integrity risk context.

Telemetry and security sources

• OpenTelemetry — Signals — current distinction among traces, metrics, logs and other signals.
• OpenTelemetry — Context propagation — cross-process signal correlation and security considerations.
• W3C — Trace Context Recommendation — interoperable trace-context propagation; correlation does not establish authorization.
• OWASP — Logging Cheat Sheet — event attributes, untrusted sources, exclusions, protection, verification and disposal.
• OWASP — LLM01:2025 Prompt Injection — untrusted retrieved and tool content boundaries.

Editorial method

OpenMax editors reviewed the exact official or primary sources above on September 6, 2026 and separated sourced product, logging, telemetry and security context from original operational synthesis. AL097 is transparently fictional; its runs, attempts, reviews and percentages are not a benchmark, certification, customer result or OpenMax performance measurement. Qualified human and actual-system review remain required.