A proposed audit packet for AI agent spending: owner, delegated authority, approval, endpoint findings, x402 or PSP transaction IDs, plus an IGA access review packet for Okta and Saviynt.
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.
Sources #
Follow Trango Compute on LinkedIn
We post updates on new tools, context engineering patterns, and LLM cost research.