Who, What, and Why? The 5 Critical Questions Your AI Audit Trail Must Answer
Who, What, and Why? The 5 Critical Questions Your AI Audit Trail Must Answer
Date: 15 November 2026
Executive Summary
An AI system can produce a plausible answer while still violating access policy, exposing sensitive data, or taking an unauthorized action. The failure is often discovered after the event, when the organization cannot reconstruct which identity initiated the request, which model or tool handled it, what data was used, or why the action was allowed.
The security decision is straightforward: treat the AI audit trail as a security control, not as application logging. It must preserve enough trusted context to reconstruct decisions across users, agents, models, tools, data stores, and policy enforcement points. If the trail cannot answer the five questions in this article, the organization should restrict the system to low-impact use cases until the gaps are closed.
Contents
- Architecture and threat model
- The five questions
- Implementation guidance
- Risks and mitigations
- Deployment checklist
- Frequently asked questions
Architecture and Threat Model
An AI application usually crosses several trust boundaries. A user request may pass through an identity provider, an API gateway, an orchestration service, a prompt or retrieval layer, a model provider, a tool broker, and one or more business systems. Each component may have different credentials, logs, retention rules, and failure behavior.
The model should not be treated as an authority. It generates proposed text or actions. A separate enforcement layer should decide whether an action is permitted. This distinction matters because model output can be manipulated by untrusted content, indirect prompt injection, misleading retrieved documents, or a compromised tool response.
A useful threat model includes at least these actors and conditions:
- An external or internal user who submits an intentionally harmful request.
- A compromised account that uses an otherwise valid AI interface.
- Untrusted content retrieved from documents, websites, tickets, or messages.
- A model that produces an unsafe or incorrect tool-call proposal.
- A compromised connector, plugin, service account, or downstream API.
- An administrator who changes policy, prompts, tools, or model routing.
- An operational failure that causes a timeout, retry, duplicate action, or partial write.
The audit trail must cross-reference events without trusting every event producer equally. Identity-provider records, policy decisions, and transaction records generally provide stronger evidence than free-form model text. Logs should be tamper-evident, access-controlled, time-synchronized where practical, and separated from the system that is being investigated.
The Five Questions
1. Who initiated and who executed the action?
“Who” is not limited to the username in the chat interface. The trail should distinguish the human requester, the calling application, the agent instance, the model provider, the tool identity, and the downstream service account. These identities often differ.
Record stable identifiers rather than relying only on display names. Useful fields include user ID, tenant ID, session ID, request ID, agent ID, service principal, tool name, connector ID, and authentication method. If impersonation or delegated access is used, record both the actor and the subject of the delegation.
Authentication proves that a credential was accepted. It does not prove that the requested operation was allowed. An audit record should therefore preserve the authentication result and the identity context passed to authorization.
2. What exactly happened?
“What” requires more than storing the final response. The record should describe the request, model route, prompt or instruction version, retrieval operations, tool calls, arguments, returned results, policy checks, side effects, and final outcome.
Do not automatically store unrestricted prompts and responses. They may contain personal, confidential, or regulated data. Instead, define a data-classification policy for audit content. Store the minimum content needed for investigation, use field-level redaction where possible, and preserve cryptographic hashes or references when the raw payload must remain in a separate controlled store.
For tool calls, record the intended operation and the actual result. A proposed call to “refund invoice 417” is different from a successfully executed refund. The audit trail must show that difference.
3. Why was the action allowed?
“Why” is the question most systems cannot answer. It requires a decision record from the policy enforcement point, not an explanation generated by the model after the event.
Capture the policy version, rule identifiers, subject, resource, requested action, relevant attributes, decision, and reason code. A reason code should be concise and machine-readable, such as ROLE_ALLOWED, OWNER_MATCH, HIGH_RISK_APPROVAL_REQUIRED, or DENIED_DATA_BOUNDARY.
Model reasoning is not a substitute for an authorization record. The model may explain what it believes, but the enforcement layer must state which policy evaluated the action and what evidence it used.
4. What was the security and business impact?
An audit trail should connect AI events to outcomes. Record whether data was read, transformed, disclosed, written, deleted, sent externally, or used to trigger a business workflow. Include the affected resource or resource class, sensitivity label, destination, transaction identifier, and whether human approval was required.
Impact is not always known immediately. Support updates to the same event or transaction as investigation proceeds. A first record may show that a tool call succeeded. A later record may identify that the returned dataset contained restricted fields or that the downstream action was reversed.
5. Can an investigator prove that the record is complete and trustworthy?
A log is useful only if investigators can establish its provenance and completeness. Use a correlation ID across the request lifecycle and a unique event ID for every material event. Preserve event timestamps, source, schema version, sequence information, and ingestion status.
Protect the audit store from ordinary application administrators where feasible. Use append-oriented storage, restricted deletion, retention controls, access logging, and integrity mechanisms such as signed events or chained hashes when the risk justifies them.
Be precise about what the trail proves. It may prove that a policy service returned “allow.” It may not prove that every component behaved correctly unless those components also produce verifiable events.
Implementation Guidance
Separate four controls that are often confused:
- Authentication: establishes which credential or identity was presented.
- Authorization: evaluates whether that identity may perform an action on a resource.
- Policy enforcement: prevents, modifies, delays, or escalates the action based on policy.
- Auditability: preserves evidence of the request, decision, execution, and outcome.
A system can authenticate correctly and still authorize incorrectly. It can authorize correctly and still fail to enforce the decision. It can enforce correctly and still be impossible to investigate if the audit record is incomplete.
Illustrative event schema:
{
"event_id": "evt_01J...",
"correlation_id": "req_01J...",
"event_type": "tool_call_decision",
"occurred_at": "2026-11-15T10:22:31Z",
"actor": {
"user_id": "user_482",
"tenant_id": "tenant_19",
"agent_id": "agent_77"
},
"action": {
"tool": "payments.refund",
"operation": "create",
"resource": "invoice:417",
"argument_hash": "sha256:..."
},
"authorization": {
"decision": "deny",
"policy_version": "payments-2026-11-01",
"rule": "refund_requires_approval",
"reason_code": "HIGH_RISK_APPROVAL_REQUIRED"
},
"execution": {
"status": "not_executed"
},
"schema_version": "1.0"
}The example intentionally records an argument hash instead of the full argument. A separate protected store could retain the original payload if the investigation policy permits it. The right choice depends on data sensitivity, legal obligations, incident response needs, and retention requirements. Do not assume that one retention period or redaction method fits every deployment.
Illustrative authorization flow:
request = authenticate(incoming_request)
context = build_identity_context(request)
proposal = model.propose_tool_call(context, user_input)
decision = policy_engine.evaluate(
subject=context.subject,
action=proposal.operation,
resource=proposal.resource,
attributes=context.attributes
)
audit.record(proposal, decision)
if decision.effect != "allow":
return denied(decision.reason_code)
result = tool_broker.execute(proposal, scoped_credential=context.credential)
audit.record_execution(proposal, result)
return resultThe tool broker should use scoped credentials and enforce the same decision independently of the model. For high-impact actions, require explicit human approval or a second control. Handle retries carefully: a timeout does not prove that an action failed. Use idempotency keys and record whether the downstream system confirmed, rejected, or left the result unknown.
Risks and Mitigations
| Risk | Why it matters | Mitigation |
|---|---|---|
| Shared service accounts | Investigators cannot attribute actions to a human or agent. | Use delegated identity context and record actor, subject, and service principal separately. |
| Model-generated authorization | Prompt injection or model error can influence access decisions. | Move authorization to a deterministic policy enforcement point outside the model. |
| Over-logging sensitive data | Audit data becomes a second data-exposure target. | Classify fields, redact selectively, hash payloads, and restrict raw-payload access. |
| Missing denied events | Security teams lose evidence of attempted abuse. | Record denied requests with identity, resource, policy version, and reason code. |
| Uncorrelated tool events | It becomes impossible to connect a user request to a downstream action. | Propagate a correlation ID and unique event IDs across every boundary. |
| Silent policy changes | Past decisions cannot be explained reliably. | Version policies, record the active version, and audit administrative changes. |
Deployment Checklist
- Define the human, application, agent, model, tool, and downstream identities in scope.
- Map every trust boundary and assign an audit event owner to each boundary.
- Generate correlation IDs before model orchestration begins.
- Record both allowed and denied authorization decisions.
- Version prompts, policies, tools, models, and routing configurations.
- Use scoped credentials and prevent the model from directly controlling authorization.
- Define redaction, retention, access, export, and deletion rules for audit data.
- Test timeouts, retries, duplicate calls, partial failures, and unknown outcomes.
- Alert on unusual tool use, repeated denials, privilege changes, and policy bypass attempts.
- Run an investigation exercise using only the audit trail and document missing evidence.
Frequently Asked Questions
Should every prompt and response be stored?
No. Store what is needed for security, operations, and accountability. Redact or separately protect sensitive content, and record hashes or structured summaries when full text is not required.
Is application logging enough?
Usually not. Application logs often omit policy versions, delegated identities, tool arguments, downstream outcomes, and administrative changes. An AI audit trail must connect those records across systems.
Can model explanations satisfy the “why” requirement?
No. A model explanation can provide context, but the authoritative reason should come from the policy enforcement point and include the rule and policy version that produced the decision.
How should denied requests be handled?
Record them as security-relevant events. Include the requester, target resource, requested action, decision, reason code, and whether the request was blocked before or after a tool was contacted.
What changes when an external model provider is used?
Record the provider, model identifier, routing decision, provider request identifier where available, data classification, and transfer status. Confirm that the provider's logging and retention behavior matches the deployment's policy.
How long should records be retained?
There is no universal answer. Set retention based on risk, incident response needs, contractual duties, applicable law, and the sensitivity of the logged data. Document the rationale and review it when the system changes.
What is the first control to implement?
Start with end-to-end correlation and a policy decision record. Without those two controls, the organization will struggle to connect an AI request to the authorization decision and the resulting action.
Use AXEC for governed AI-agent security and schedule a 30-minute meeting to discuss your agentic workflow controls.
