Skip to main content

Intelligent Purchase Authorisations

An Intelligent Purchase Authorisation (IPA) is an ongoing authorisation for an agent to execute purchases on a user’s behalf over a window of time. Where a single is a point-in-time authorisation, an IPA carries that authorisation through a preflight, into execution, and across multiple runs until it expires or is cancelled.

How it composes with PINTs

An IPA is backed by one or more signed PINTs. The scopes on those PINTs define what the agent is allowed to do:
  • sr:us:pint:perpetual:search?time=… — create and run the IPA for the given window
  • sr:us:pint:spend:execute?max=…&asset=…&chain_id=… — authorise on-chain purchase execution
Each run against the IPA draws on those scopes; per-scope parameters (amount cap, asset, chain) are enforced at execution time.

What the model looks like

The IPA record separates three concerns — origin, execution, and pre-flight workflow — into distinct identifiers:
  • originating_agent_task — the agent task the IPA was created from (surfaced via expand=originating_agent_task). originating_chat_id on the create request carries through the chat session for traceability.
  • executing_agent_task — the agent task that carries the IPA into execution (surfaced via expand=executing_agent_task). Populated during pre-flight once the execute workflow has been spawned, so it is available before approval is granted. See the lifecycle reference for exact timing.
  • preflight_workflow_id — the durable workflow that validates the intent and the linked PINT’s scopes before the IPA becomes executable.
A user can have many IPAs; each has its own lifecycle and its own backing PINTs.

When a partner uses one

  • Perpetual search flows — the user expresses an intent (“find me concert tickets under $200 in the next month”), and the IPA authorises the agent to surface and execute matches across that window.
  • Agent-executed checkout — the agent holds the IPA; the user is not present for each purchase.
  • “Authorise once, execute over a window” patterns — anywhere a partner needs durable, scope-bound authorisation rather than a per-transaction prompt.

See also

Referenced from