How to Audit AI Agent Spending
When a stakeholder asks "why did the agent spend $2,000 last week?", you need an answer in minutes, not a week of log archaeology. The fix is a tamper-evident audit trail that captures every spend decision, ties it to a policy version, and survives review. Here is the 5-step playbook.
The minimum audit fields per transaction
| Field | Why it matters |
|---|---|
| agent_id | Which agent made the spend |
| session_id | Which session/task context |
| merchant | Where the money went |
| amount | How much (in USD) |
| category | LLM, compute, tools, payment |
| intent | What the agent was trying to do |
| timestamp | When (UTC, precise to ms) |
| decision | APPROVED / BLOCKED / FLAGGED |
| policy_version | Which ruleset produced the decision |
If any of these fields is missing, the audit trail is incomplete and will not hold up under review.
The 5-step playbook
1 Capture every transaction
Log every spend decision — approved, blocked, and flagged — with all the fields in the table above. Blocked transactions matter as much as approved ones: they show where your controls fired. A log that only records approved spend hides the controls that are working.
{
"agent_id": "research-bot-01",
"merchant": "anthropic.com",
"amount": 0.05,
"category": "llm",
"decision": "APPROVED",
"policy_version": "v2026-07-18",
"timestamp": "2026-07-18T14:23:01.442Z"
}2 Make logs tamper-evident
Append-only storage and hash chaining — each log entry includes the hash of the previous entry, so any modification or deletion breaks the chain and is immediately detectable. This is the same technique used for financial audit trails and blockchain ledgers. A database you can edit is not an audit trail.
3 Track policy versions
Every decision records which policy version produced it. When you change a rule (e.g., raise the per-transaction cap from $50 to $100), the version increments. Without version tracking, you cannot answer "was this spend allowed under the rules in effect at the time?" — which is the first question any reviewer asks.
4 Define a review cadence
Three cadences: daily anomaly review (were there any blocked or flagged transactions?), weekly spend review (is spend within budget, trending up, or anomalous?), monthly compliance review (does the policy match the team's intent, and are there exceptions to investigate?). Without a cadence, the log exists but is never read.
5 Automate exception reports
Generate reports of blocked, flagged, and out-of-policy transactions automatically. The report should surface: the top merchants by spend, the agents with the most blocked transactions, any FLAGGED items still awaiting human review, and any policy-version changes in the period. sipi.bot produces this report from the audit log.
What a good audit trail lets you answer
- "Why was this $500 transaction approved?" → the policy version and the rule that matched.
- "Which agent spent the most last week?" → aggregate by agent_id.
- "Did any spend happen outside the allowlist?" → filter blocked transactions.
- "Has the policy changed since the incident?" → policy version history.
- "Is the log complete and unmodified?" → hash-chain verification.
Frequently asked questions
How do I audit my AI agent's spending?
Capture every transaction with agent id, merchant, amount, intent, timestamp, and policy version; make the log append-only and hash-chained; track policy versions; define a review cadence (daily, weekly, monthly).
What makes an agent spend log tamper-evident?
Append-only storage and hash chaining — each entry includes the hash of the previous entry, so any modification breaks the chain and is detectable.
What fields should an agent spend audit log contain?
Agent id, session id, merchant, amount, category, intent, timestamp, decision, and policy version. Without policy version, you cannot reconstruct why a transaction was allowed or denied.