How do I build a full agent audit trail tied to the grant, spend cap, and revocation state at each action?

What should I check, step by step?

1. Define the event schema once: action id, time, actor (agent + optional human principal), tool/server, argument hash, outcome, grant_id, policy_version, spend_cap snapshot (per_tx / daily / remaining), revocation_status, and prev_hash for chaining.

2. On every risky call, load the live grant and spend policy first. Refuse if expired, out of scope, over cap, or revoked — then still write a denied row so the trail shows refusals, not only successes.
3. For payments and purchases: set_spend_policy on the credential, call authorize_spend (or your issuer's real-time auth) with amount and merchant, and store the allow/deny receipt id on the trail row.
4. For high-impact non-pay actions: request_human_approval with a hashed action object; verify_human_approval again immediately before the side effect; link approval_id on the same row.
5. Call check_revocation (credential id, key id, or fingerprint) at dispatch; after an incident use revoke_agent / revoke_agent_credential and confirm later rows show revoked.
6. Prefer sequence-aware review (tool order across the session), as Quarry-style rules do, on top of per-call rows — single-call allowlists miss "read secrets then exfiltrate" patterns.
7. Store the trail where the agent cannot UPDATE it (server DB, ledger, SIEM). Keep only ids in session memory.
8. Retain the full grant's trail after revocation for your compliance window; do not delete history when you kill access.

What "full trail" means for agents

Activity logs answer what the system reported. A full trail also answers what the agent was allowed to do when it acted: grant scope, spend ceiling, and revocation bit at that timestamp.

• Cisco's Project Quarry evaluates rules over conversations, tool calls, MCP interactions, and event order, and returns findings with evidence — useful for spotting risky sequences. Your product still decides whether to alert, block, or only log; Quarry does not by itself attach spend caps or revocation state.
• Draft work on delegated agent grants and authority histories (for example DAAP-style grant tokens with hash-chained audit entries, and replayable authority histories) converges on the same idea: admissions name the grant head they were decided on, and budgets meter only admitted actions.

Wire grant, cap, and revoke into every row

set_spend_policy records per_tx_max_minor, daily_max_minor, allowed domains/categories, and optional expiry on a credential; authorize_spend returns a signed allow/deny against that policy (records only — it never moves money).

• request_human_approval / decide_human_approval / verify_human_approval bind a human yes to a hashed action; put approval_id next to grant_id on the trail when money or irreversible tools are involved.
• check_revocation is free and keyless for credential or key fingerprints; pair it with How to revoke an AI agent's access immediately so kill-switch and trail stay consistent.
• record_ai_run can seal a run-level summary (model, hashes, params including tool_call_count and grant_id) onto the ledger; verify_ai_run lets a reviewer check the receipt without trusting the agent's chat export.

What can go wrong?

Trail has tool names but no grant_id or remaining budget, so an auditor cannot tell a $5 allow from a policy that had already been exhausted.

• Revocation updates the IdP but the trail writer caches "active" for the whole session; post-revoke calls still look authorized.
• Only successes are stored; denied and blocked attempts — often the most important evidence — are missing.
• Sequence detectors fire in a SIEM while the only durable store is the agent's editable RunState, which was overwritten on the next turn.