What Evidence Should an Enterprise Keep When an AI Agent Spends?

When an agent spends company money, someone will eventually ask: whose agent was it, what was it allowed to do, who approved this, and did the money go where we expected? Whether you can answer depends on what you recorded at the time.

Recommended design, not a standard. No existing standard defines the packet below, and it is not a shipped ContextIQ feature. It is a proposal to adapt to your own controls.

Two kinds of evidence

Keep them apart. They have different owners, different reviewers and different retention needs.

Access-review evidence answers: should this agent identity have this authority? Reviewed periodically by identity governance.
Financial transaction evidence answers: what happened in this specific purchase? Reviewed by finance, audit and security when something goes wrong.

Mixing them produces packets that are too big to review and too vague to rely on.

The OpenID Foundation's comments on EMVCo's agentic payments draft point the same way: keep agent identity distinct from delegated authority, make accountability foundational, and preserve evidence trails. The packet below is our reading of that direction, not something OIDF or EMVCo has specified.

Proposed audit packet (per transaction)

Section	Contents	Source system
Agent identity	Agent ID, credential or client ID, platform	Identity provider
Accountable owner	Named human or team, contact, date assigned	IGA / HR directory
Delegated authority	Policy version in force: caps, merchants, purposes, expiry	Your policy store
Approval	Approver, timestamp, the request ID approved	Your application
Endpoint findings	Probe time, protocol, fields checked, warnings, what was not checked	Inspection tool output
Transaction identifiers	Request ID, idempotency key, checkout session or payment ID, PSP or chain transaction ID	App, PSP, chain
Settlement evidence	PSP capture record, or on-chain receipt check where supported	PSP / chain
Fulfillment	Order status, delivery confirmation, refunds	Merchant
Exceptions	Denials, overrides, retries, mismatches, who resolved them	Your application

Store the policy version, not just the policy: a later change to caps should not rewrite history.

Worked example (fictional)

Northwind Labs' agent-research-07 buys a $42 report. The packet records: owner j.lee (assigned 2026-09-01); policy v14 (cap $50, approval above $25); approval by m.ortiz at 10:02 for request req-8841; an endpoint inspection at 10:03 showing a well-formed payment challenge, with facilitator reachability listed as not checked; transaction hash 0xabc… (placeholder); a settlement check comparing the paid recipient and amount against what the challenge declared; and no exceptions. If the settlement check had shown a different recipient, the packet would record it as an exception and trigger review.

IGA access review packet for Okta, Saviynt, or other IGA solutions

This is the access-review half. It is about the agent's standing authority, not any one purchase.

Item	What a reviewer needs
Owner	Named accountable person; backup
Permissions	Tools, scopes and spending authority the agent holds
Delegation	Who granted authority, on what basis, for how long
Review decision	Approve, reduce, or revoke, with reviewer and date
Revocation conditions	Owner leaves, project ends, anomaly threshold, credential rotation failure

ContextIQ's Agent Protocol Inspector already generates a deterministic, rule-based IGA Review Packet from an MCP or A2A scan, with export formats for Okta's disconnected-app CSV import and a generic long-format file connector used by Saviynt and SailPoint. See How to Run an IGA Access Review on an AI Agent Before You Approve It. That packet is built from endpoint scan results; it does not contain transaction records, and the fields above that describe spending authority (caps, approvers) come from your own systems.

Where inspection output fits and where it stops

Endpoint findings are one section of the packet. For x402 USDC payments on Base, ContextIQ's Pro-tier receipt verification can independently check a settlement transaction against the chain and compare it with the payee and amount the challenge declared. It does not cover card or PSP settlement, and it does not produce approval or fulfillment evidence. For card flows such as OpenAI's Delegated Payment Spec, the merchant and PSP own settlement, refunds and chargebacks, so their records belong in the packet.

Privacy and retention considerations

Raw card data has no place in the packet; keep vault token IDs and last-four display fields at most. Minimize personal data: approver IDs rather than full profiles where possible. Retention period, access controls and legal-hold handling depend on your jurisdiction, contracts and counsel. This design makes no compliance claim for any regime. Decide who may read the packet, and log reads of it.