What should an AI agent audit log record?

A trace is not an audit trail

Model traces help engineers debug prompts, tool calls, and latency. An operational audit trail answers a different question: who or what was allowed to do which consequential action, to which resource, and what actually happened?

NIST's 2026 concept paper on agent identity and authorization explicitly calls out identification, authorization, auditing, and non-repudiation as open requirements for software and AI agents. NIST's AI Risk Management Framework is broader and voluntary; it helps organizations manage AI risk, but it does not prescribe one universal event schema.

A minimum useful event

Start with these fields. Keep them structured and consistent so they can be filtered, compared, and reviewed.

Timestamp

When the decision or action occurred, with timezone or UTC.

Agent ID

A stable identifier for the agent or automation—not merely the model name.

Action type

A clear verb such as read, create, update, delete, publish, send, purchase, or deny.

Target

The resource kind and a non-secret reference, such as an order ID, post ID, or file hash.

Effect

Read-only, data write, public representation, communication, permission change, or financial effect.

Decision

Allowed, denied, or escalated—and the policy or approval basis used.

Outcome

Success, failure, partial, or unknown, plus a bounded evidence reference.

Example event

{
  "timestamp": "2026-09-17T16:42:11Z",
  "agent_id": "publishing-agent-02",
  "action_type": "publish",
  "target": { "kind": "article", "ref": "sha256:9e4…" },
  "effect": "public_representation",
  "decision": "allowed",
  "authorization_basis": "approval-ticket-1842",
  "outcome": "success",
  "evidence_ref": "platform-post-7319"
}

The example uses references rather than raw credentials, prompts, customer data, or message bodies. Your implementation should match your actual risk, retention, and legal requirements.

Separate three kinds of proof

Keeping these separate prevents a common failure: treating a green workflow run as proof that the customer, finance, or publishing outcome is correct.

What should stay out of the log

OWASP's logging guidance recommends removing, masking, sanitizing, hashing, or encrypting sensitive fields rather than recording them directly. For agent systems, the default exclusion list should include:

• Passwords, access tokens, API keys, recovery codes, and one-time verification codes.
• Session identifiers, database connection strings, encryption keys, and payment-card or bank data.
• Raw prompts, model responses, attachments, or message bodies unless they are necessary, authorized, minimized, and protected.
• Customer personal data or commercially sensitive content when a stable reference will do.

Also sanitize untrusted event values before writing them. Log data can contain hostile input, and the log itself needs access control, retention rules, monitoring, and tamper protection.

Hash chains help—but do not prove truth

Linking each event to the previous event's hash can reveal later deletion or alteration. It does not prove that the original event was complete, that the agent was authorized, or that the recorded outcome was true. Protect the signing or hashing process, restrict access, and verify high-risk outcomes independently.

Before an agent can take real actions

1. Define action classes. Separate reads from writes, public posts, messages, permission changes, and spending.
2. Attach an authorization rule. Decide what is pre-approved, what is denied, and what needs a person.
3. Record the decision before execution. A post-hoc log is weaker evidence of authorization.
4. Record platform evidence after execution. Use stable IDs or hashes, not screenshots alone.
5. Verify the business outcome. Confirm the destination state rather than trusting the tool response.
6. Test denial and failure paths. Verify that blocked actions stay blocked and partial failures are visible.
7. Review access and retention. Limit who can read, change, export, and delete logs.