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

**Short answer:** A useful agent audit trail is more than a chat export. For every consequential action, record what ran and the authority snapshot at that moment: which grant (or approval) covered it, which spend cap and remaining budget applied, and whether the credential was unrevoked. Sequence-aware detectors such as Cisco Project Quarry show why order matters — reading credentials then calling an external host is a different finding than either step alone — but detection alone is not a trail unless you persist the grant, cap, and revocation fields beside each event. Keep the trail append-only and outside the agent's editable session; pair set_spend_policy and authorize_spend for money paths, request_human_approval for risky steps, check_revocation before dispatch, and record_ai_run when you need a signed run receipt.

## Checklist
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.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "Set a spend policy on this agent credential and show me how to authorize each purchase against it so every allow or deny can sit on our audit trail."

```json
{
  "tool": "set_spend_policy",
  "arguments": {
    "credential_id": "crd_…",
    "currency": "USD",
    "per_tx_max_minor": 2500,
    "daily_max_minor": 10000,
    "allowed_domains": [
      "api.vendor.example"
    ],
    "allowed_categories": [
      "saas"
    ],
    "expires_at": "2026-11-07T03:00:00Z"
  }
}
```
- Needs your API key (owner). set_spend_policy replaces the previous policy; prior versions remain on the ledger. authorize_spend then returns a signed allow/deny per purchase (records only).
- request_human_approval for actions above your threshold; verify_human_approval immediately before the side effect.
- check_revocation before dispatch; record_ai_run when you want a signed run receipt that references grant_id and tool_call_count.
- How to audit which human authorized an AI agent action and How to record MCP tool calls at the gateway with scope-grant binding cover the human-grant and gateway-capture angles.

_Rightshold records spend policies, spend authorizations, human approvals, revocation checks and AI-run receipts for agents that call it. It does not replace your SIEM, run Project Quarry for you, move money, or stop an agent that never asks. Enforce the trail schema and fail-closed checks in your gateway and runners too. Not legal advice._

## Sources
- [Cisco AI Defense: Project Quarry — how Quarry works (sequence rules over tool/MCP events)](https://github.com/cisco-ai-defense/project-quarry/blob/main/docs/how-quarry-works.md)
- [Data Governance Signal: Cisco open-sources Project Quarry for risky agent action sequences](https://datagovernancesignal.com/news/cisco-open-sources-project-quarry-to-flag-risky-sequences-of-ai-agent/)
- [IETF draft: Delegated Agent Authorization Protocol (DAAP) — grants, budgets, hash-chained audit](https://datatracker.ietf.org/doc/html/draft-mishra-oauth-agent-grants-01)
- [IETF draft: Replayable Authority Histories for Auditing Automated Agents](https://www.ietf.org/archive/id/draft-rampertab-audit-agent-authority-history-00.html)
- [Agent spending policies on Rightshold](https://www.rightshold.com/agent-spending-policies)
- [Human approvals on Rightshold](https://www.rightshold.com/human-approvals)
- [Verified AI Runs on Rightshold](https://www.rightshold.com/verified-ai-runs)

## Related
- [How to record MCP tool calls at the gateway with scope-grant binding](https://www.rightshold.com/answers/how-to-record-mcp-tool-calls-at-the-gateway-with-scope-grant-binding)
- [How to audit which human authorized an AI agent action](https://www.rightshold.com/answers/how-to-audit-which-human-authorized-an-ai-agent-action)
- [How to gate an agent wallet or card with per-task caps and an outside-agent spend record](https://www.rightshold.com/answers/how-to-gate-an-agent-wallet-or-card-with-per-task-caps-and-an-outside-agent-spend-record)
- [How to revoke an AI agent's access immediately](https://www.rightshold.com/answers/how-to-revoke-an-ai-agents-access-immediately)

_Not legal advice. Updated 2026-11-06. JSON: https://www.rightshold.com/answers/how-to-build-an-agent-audit-trail-tied-to-grant-spend-cap-and-revocation.json_