AI Agent Audit Log Schema Template: Fields for Identity, Delegation, Tool Calls and Outcomes

When an AI agent does something it should not have done, the first question is who it was acting for and on whose authority, and most agent logs cannot answer it. Framework traces record prompts and latencies, and target systems record that a service account made a change, but nothing ties the two together with the human principal, the delegation chain and the approval. This template gives [Organisation] a ready-to-use audit record schema for AI agents: the fields, their types, whether they are required, and an example record. It is for platform engineers, detection engineers and audit teams. The AI Agent Audit Trails for Regulators Guide explains why each element matters; this page is the schema to implement.

How to use this template

• Replace text in square brackets, such as [Organisation], [SIEM] and [N days], with your own values. Bracketed values are illustrative.
• "Required" fields must be present on every record of that event type; "Conditional" fields are required when the condition applies; "Optional" fields are recommended.
• Field names use an agent_audit.* namespace that NHI Mgmt Group defined for this template. Where an OpenTelemetry GenAI attribute exists, section 11 maps it, so you can emit traces and audit records from the same instrumentation.
• Emit one record per event, not one per run. A run produces several records sharing a run_id.
• Adopt sections 3 to 9 as your logging standard and section 10 as the rule for sensitive content.

1. Purpose

This schema defines the minimum audit record that every AI agent operated by or for [Organisation] must emit, so that any agent action can be attributed to a registered agent, a human or system principal, and an authorisation decision, and so that investigators can reconstruct a run without relying on the agent's own account of it.

2. Scope

The schema applies to internally built agents, agents built on low-code platforms, AI coding agents, and third-party agents that hold credentials in [Organisation] systems, where [Organisation] controls the runtime or gateway. For third-party agents where it does not, the schema is the contractual logging requirement. Chat assistants without tools emit only the session and model call events.

3. Record envelope (all events)

4. Agent identity

5. Principal and delegation

RFC 8693 represents delegation with nested act claims: the outermost names the current actor and nested claims name prior actors. Logging the decoded claims lets an investigator read the full user to agent to service chain.

6. Model call event

7. Tool call event

8. Policy decision and approval events

9. Outcome

10. Sensitive content rules

1. Records must never contain passwords, access or refresh tokens, API keys, session identifiers, connection strings or encryption keys. Log a reference (key ID, token ID, hash) instead.
2. Prompts, model outputs, tool arguments and tool results may contain personal or confidential data. Store them, if at all, in a restricted content store referenced by model.content_ref, with access limited to [named roles] and retention of [N days].
3. Redaction must run before the record leaves the runtime, not in the [SIEM].
4. Where content capture is disabled, hashes of inputs and outputs must still be recorded so that content held elsewhere can be matched later.

11. Integrity, retention and example

1. Records must be sent to an append-only or write-once store outside the agent's control within [N minutes]. The agent's own identity must not be able to delete or alter them.
2. Tamper detection, such as hash chaining or signed batches, must be enabled, and access to logs must itself be logged and reviewed.
3. Retention: [N months] for security-relevant records, longer where a regulation requires it.

Example tool.call record (illustrative values):

{
  "agent_audit.schema_version": "1.0",
  "event_id": "[uuid]",
  "event_type": "tool.call",
  "timestamp": "2026-11-09T10:42:17.215Z",
  "run_id": "[run-id]",
  "trace_id": "[trace-id]",
  "environment": "production",
  "agent": {"id": "agt-0142", "name": "invoice-triage", "version": "3.2.0",
            "owner": "team-ap-automation", "workload_identity": "[service principal ID]",
            "config_hash": "sha256:[hash]"},
  "principal": {"type": "user", "id": "[user subject]"},
  "delegation": {"chain": [{"id": "[user subject]", "type": "user", "via": "sign-in"},
                           {"id": "agt-0142", "type": "agent", "via": "token_exchange"}],
                 "token_claims": {"sub": "[user subject]", "act": {"sub": "agt-0142"},
                                  "scope": "invoices.read", "jti": "[token id]"}},
  "authorisation": {"mode": "on_behalf_of"},
  "tool": {"name": "erp.get_invoice", "type": "api", "operation": "read",
           "target_resource": "invoice/[id]", "arguments_redacted": {"invoice_id": "[id]"},
           "credential_ref": "token:[token id]", "untrusted_in_context": true},
  "policy": {"engine": "[policy engine]", "version": "[bundle version]",
             "decision": "allow", "rule_id": "ap-read-01", "reason": "read within scope"},
  "outcome": {"status": "success", "data_volume": 1},
  "security_relevant": true
}

Implementation guidance

Mapping to OpenTelemetry GenAI conventions

The OpenTelemetry GenAI semantic conventions define agent and tool spans. They are at Development status, so pin the version you emit. Mark arguments, results and messages as opt-in content, as the conventions do.

See the OpenTelemetry GenAI Semantic Conventions for Security Teams for instrumentation choices.

Rolling it out

1. Start at the chokepoint: emit records from the tool or MCP gateway first, where every call passes, then add runtime fields.
2. Pilot with one high-risk agent and test that an investigator can answer five questions from records alone: which agent, for whom, under which rule, with which credential, and what changed.
3. Run redaction tests with seeded fake secrets before enabling production forwarding.
4. Write detections: tool calls with untrusted_in_context true and a write or send operation; credential references used outside their expected agent; approval latency under one second.
5. Version the schema and reject records with unknown versions at ingestion.

Framework mapping

The mapping is NHI Mgmt Group's editorial judgement.

Standards and references

• OpenTelemetry: GenAI semantic conventions
• IETF: RFC 8693 OAuth 2.0 Token Exchange
• OWASP: Logging Cheat Sheet
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Audit Readiness for AI Agents and NHIs, AI Agent Observability and Incident Response Guide, Identity Telemetry Requirements, AI Agent Risk Assessment Template.