Your AI Agent Is Authenticated. What Is It Allowed to Buy?

Authentication alone does not authorize an AI agent to spend, according to a technical post that separates authentication, delegated authority, purchase approval and payment authorization into four distinct checks with separate evidence. The post walks through a fictional Northwind Labs research agent buying a $42 market report under a policy capping purchases at $50 each, requiring a named human approver above $25, and limiting merchants to an allow-list, and it warns that a $50 per-purchase cap still permits $2,000 across forty purchases unless a cumulative budget is enforced. It recommends atomic budget reservation via a ledger.reserve call to prevent concurrent overspend and idempotency keys such as OpenAI ACP's Idempotency-Key header, with the Delegated Payment Spec returning a 409 when the same key arrives with different parameters.

Your AI Agent Is Authenticated. What Is It Allowed to Buy? Authentication is not authorization to spend. Per-purchase caps, cumulative budgets, retries and concurrency, with a documented AWS AgentCore example and OAuth 2.0 and OpenAI ACP context. An agent presents a valid OAuth token. Your API accepts it. That settled one thing: the caller is who the token says it is. It did not settle whether this agent may buy this item from this merchant for this reason right now. Authentication, delegated authority, purchase approval and payment authorization are separate events with separate evidence. This post shows where each check lives, using a fictional scenario. The scenario fictional A research agent at a made-up company, Northwind Labs, asks to buy a market report. The request: { "agent id": "agent-research-07", "merchant": "reports.example-vendor.test", "amount": 42.00, "currency": "USD", "purpose": "Q4 competitor analysis approved project P-1187 ", "expires at": "2026-10-08T18:00:00Z" } The policy attached to that agent: maximum $50 per purchase , merchants limited to an allow-list, purpose must match an approved project, requests expire, and anything over $25 needs a named human approver. Where each check happens | Event | Question | Who establishes it | Evidence | |---|---|---|---| | Authentication | Who is calling? | Your identity layer | Token, client credentials | | Delegated authority | What was this agent given the right to do? | The agent's owner, in your policy store | Policy record, owner, scope | | Purchase approval | Did an accountable person OK this purchase? | Your application | Approval record tied to request | | Payment authorization | Did the payment network or PSP accept it? | PSP / chain | Authorization ID | An OAuth token can carry scopes, but a scope like purchase does not encode "$50 at this merchant for project P-1187." That logic lives in your application. Application-side policy check python def authorize purchase req, policy, ledger, approvals : if req.merchant not in policy.allowed merchants: raise Denied "merchant" if req.purpose project not in policy.approved projects: raise Denied "purpose" if req.expires at <= now : raise Denied "expired" if req.amount policy.per purchase cap: raise Denied "per-purchase cap" if req.amount policy.approval threshold: if not approvals.has valid req.request id : raise NeedsApproval cumulative budget: reserve atomically, don't check-then-spend if not ledger.reserve req.agent id, req.request id, req.amount : raise Denied "budget exhausted" return Allowed req.request id The atomic ledger.reserve call at the end is the important part; see the section on concurrent purchases below. Per-purchase cap vs cumulative budget They guard different failures. - A per-purchase cap $50 limits the damage of one bad decision. - A cumulative budget say $200 per run or per month limits the sum of many small decisions, each individually legal. An agent that stays under $50 forty times has spent $2,000. Only the cumulative control sees that. Retries and concurrent purchases Agents retry, and they run in parallel. Two failure modes follow: - Retry double-spend. If a network timeout hides a success, the agent retries. Key every purchase by a stable request id and make the ledger and the downstream call idempotent on that key. OpenAI's ACP specs require an Idempotency-Key header, and the Delegated Payment Spec returns a 409 when the same key arrives with different parameters. - Concurrent overspend. Two parallel requests each read "$30 remaining" and each spend $25. Check-then-act races like this are solved by atomically reserving budget before the payment call and releasing it if the payment fails. A documented example, not a ContextIQ feature OpenAI's controlled agentic commerce cookbook https://developers.openai.com/cookbook/examples/partners/aws/controlled agentic commerce with agentcore payments/controlled agentic commerce demonstrates this layering with AWS AgentCore Payments. In the example, a per-transaction maximum amount and a per-run cumulative limit are both enforced by the application, human approval is recorded as an ApprovalGrant with approved by and approved at , and an unapproved request fails with PolicyDenied . The cookbook states that the application checks merchant, purpose, amount and approval before a payment can occur, and its sample runs on synthetic payments unless operators opt in. We cite it as a pattern; ContextIQ is not part of it. Likewise, OpenAI's Delegated Payment Spec https://developers.openai.com/commerce/specs/payment lets a payment credential carry an allowance maximum amount, currency, merchant, checkout session, expiry . That limits the credential, but it does not replace your own policy: your application still decides whether to ask for the credential at all. The pending-approval pattern The OpenID Foundation's AuthZEN working group has approved a draft Access Request and Approval Profile AARP for the case where policy cannot yet authorize an action because an approval, consent or delegated authority is missing; the system signals what is pending and re-evaluates once it is satisfied OIDF announcement https://openid.net/openid-foundation-advances-authorization-for-the-agent-era-with-new-authzen-working-group-drafts/ . It is a working-group draft, and the NeedsApproval branch above is our own simplification of the same idea, not an implementation of AARP. Developer checklist - Authenticate the agent, then look up its policy by agent identity, not by anything in the request body. - Name an accountable human owner for every agent identity. - Validate merchant, purpose, amount, currency and expiry server-side. - Enforce a per-purchase cap and a cumulative budget. - Require approval above a threshold, and bind each approval to one request ID. - Reserve budget atomically; release on failure. - Use idempotency keys end to end. - Log the decision and its inputs, including denials. Where ContextIQ fits ContextIQ does not authorize purchases or enforce spending limits; that belongs to your application. What it offers is endpoint inspection: the Agent Protocol Inspector https://contextiq.trango-compute.com/agent-readiness-detector can scan an MCP, A2A or ARD endpoint, and the x402 Inspector https://contextiq.trango-compute.com/x402-inspector can validate a payment endpoint's 402 challenge before your policy code decides whether to pay it. Sources Follow Trango Compute on LinkedIn We post updates on new tools, context engineering patterns, and LLM cost research. Follow on LinkedIn https://www.linkedin.com/company/trango-compute