Imagine an agent that manages your company's AWS infrastructure. It has read access to all resources, write access to EC2 instances, and the ability to create and delete S3 buckets within certain prefixes. Yesterday, something went wrong — a bucket was deleted that shouldn't have been.
Now answer this: what happened?
If you're lucky, you have CloudTrail logs and can see that the agent's API key made the DeleteBucket call at 14:32 UTC. But you probably can't answer the harder questions:
- What instruction led to this action?
- What reasoning did the agent apply?
- Was this within the agent's intended scope?
- Which orchestrator or user session triggered the sequence of actions that led here?
These questions aren't academic. They're the questions a security team asks during incident response, a compliance officer asks during an audit, and a regulator asks when something goes badly wrong.
Why current logging is insufficient
Most agent deployments produce three kinds of logs:
LLM provider logs — token counts, latency, occasionally the prompt and completion if you've enabled it. These are optimized for billing and debugging, not governance.
Application logs — whatever your agent framework emits. Usually structured around the framework's internal events, not the external actions the agent took.
Infrastructure logs — CloudTrail, GCP Audit Logs, etc. These capture the effects at the infrastructure level but have no knowledge of the agent context that produced them.
The problem: none of these three logs speak the same language, and there's nothing that joins them together into a coherent causal chain.
You can establish that the DeleteBucket call happened (infrastructure log) and roughly when the agent was running (application log), but you can't easily reconstruct the chain: user session → orchestrator instruction → reasoning step → tool call → API call → effect.
What an agent audit log needs to capture
A proper agent audit event is not just an API call record. It's a structured representation of an agent's decision and action, with enough context to reconstruct intent:
{
"event_id": "01JA8K...",
"timestamp": "2025-10-28T14:32:11.042Z",
"agent": {
"id": "did:agent:example:infra-manager-v3",
"session_id": "sess_9f2k...",
"invocation_id": "inv_3m8p..."
},
"cause": {
"type": "user_instruction",
"session_id": "user_sess_4r7n...",
"instruction_hash": "sha256:a3f..."
},
"reasoning": {
"step": 4,
"total_steps": 7,
"summary": "Deleting bucket as part of environment cleanup for project-staging"
},
"action": {
"type": "tool_call",
"tool": "aws_s3_delete_bucket",
"parameters": {
"bucket": "acme-project-staging-assets"
}
},
"policy_check": {
"result": "ALLOW",
"policy_id": "infra-manager-s3-write",
"evaluated_at": "2025-10-28T14:32:11.038Z"
},
"outcome": {
"status": "SUCCESS",
"duration_ms": 234
},
"signature": "Ed25519:z6Mk..."
}
Several things are worth noting about this structure:
Causal chain linkage. The cause field links this action back to the user session and instruction that triggered it. This enables full reconstruction of the chain from user intent to system effect.
Reasoning capture. The reasoning field records what the agent believed it was doing. This is distinct from the action itself — it's the agent's stated justification, which can be reviewed independently of whether the action was correct.
Policy check record. Every action that was authorized by a policy engine records the policy decision inline. Auditors can see not just what happened but what authorization was claimed.
Cryptographic signature. The event is signed with the agent's key. The log's integrity is verifiable independent of the infrastructure that holds it — this matters when logs might be tampered with or disputed.
The tamper-evidence requirement
Traditional application logs are mutable. Database logs can be altered by DBAs. Cloud provider logs can theoretically be modified by a compromised admin account. For governance purposes, this is a problem.
An agent audit log needs to be tamper-evident: given a log record, any verifier should be able to confirm that it hasn't been altered after the fact. Cryptographic signatures on individual events are a start; a hash-linked structure (similar to a certificate transparency log or a blockchain-inspired append-only log) provides stronger guarantees.
This isn't theoretical — financial services regulators and SOX compliance requirements already demand tamper-evident audit trails for human-facing systems. As agents take on higher-stakes actions, the same requirements will apply to them.
Toward a standard
The Agent Audit Log Format (AALF) we're developing is designed around these requirements. It extends CloudEvents — an existing CNCF standard for event schemas — with agent-specific fields for causal chain, reasoning, and policy decisions.
Our goal is a format that:
- Any agent framework can emit
- Any SIEM or log aggregation system can ingest
- Provides enough context for both real-time alerting and forensic investigation
- Supports cryptographic verification of event integrity
The draft specification is open for comment. We're particularly interested in feedback from security operations teams who deal with agent incidents today, and from compliance teams mapping agent audit requirements to existing frameworks like SOC 2 and the NIST AI RMF.
The AALF specification is in early draft. Feedback and contributions welcome via GitHub.