Agentic payments connect an AI agent’s decisions to transactions. A research assistant might pay for information before producing an answer; a store’s operations agent might collect payment, adjust an order, and process a return. The payment system executes individual transactions, while the agent manages the larger task around them.
That distinction matters because permission is not only about whether the next call is allowed. It is also about what the call leaves available afterward. When a credential has a limited scope and can be used only once, spending it on a valid operation may consume the only authority that can serve a later step.
A payment agent therefore needs more than a collection of individually restricted credentials. It needs a way to allocate and use those credentials across the workflow, including branches that have not yet been chosen. ActWithin addresses both decisions: what authority to issue before execution, and which credential to use at each step. A trusted gateway retains the remaining credentials and can execute a bounded number of operations on the agent’s behalf.
The connection between those decisions is easiest to see in an order that might later be returned.
A valid charge that leaves the order unfinished
Imagine an agent working for an online accessories store. A customer buys two USB-C hubs at $40 each. The agent must collect $80. The customer may later return either or both hubs, with each return requiring a separate $40 refund. The longest path therefore contains three payment operations: one charge and two refunds.
All credentials in this example are restricted to this order and are single-use: using one for a charge means it cannot later authorize a refund. The starting allocation is:
| Holder | Credentials | What each credential permits |
|---|---|---|
| Agent | Two broader tokens | One charge up to $80 or one refund up to $40 |
| Gateway | One narrower token | One charge up to $80; no refunds |
Here, a token is a scoped API credential. The gateway is a trusted service that checks requests and executes approved operations with the tokens it keeps outside the agent’s control. Allow it to handle at most one operation for this order; that operation is called mediation and need not involve a person.
Suppose the agent uses one of its broader tokens to collect the $80. That charge is valid, and one token remains available for a refund. But if the customer returns both hubs, the second refund cannot proceed. The agent has no unused refund-capable token, and the gateway’s charge-only token cannot help.
Now keep the same starting allocation and change only the first choice. The gateway collects the $80 with its charge-only token. Both broader tokens remain with the agent, ready for the two possible refunds. Every permitted return path can now complete, with just one mediated operation.
The first charge was valid in both cases. Only one choice preserved the ability to finish the workflow.
Plan the grant before choosing the first token
ActWithin starts with a description of the permitted workflow, the available credentials, and the maximum number of gateway operations. The workflow can include required steps, alternative branches, and groups from which a fixed number of agents will run. Credentials receive exposure weights, and the planner minimizes the total weight issued to agents.
In the hub example, give each token the same weight. Any allocation that supports the three-operation path with at most one gateway operation must issue at least two tokens to the agent. Issuing both refund-capable tokens is one minimum-weight allocation—but, as the example shows, that allocation needs a runtime policy that uses it correctly.
The planner also produces a certificate containing demand and budget summaries. A separate checker recalculates those summaries and verifies that the initial allocation can support every allowed path within the gateway allowance. The split between issued and retained tokens stays fixed for the run: the gateway executes with its own credentials rather than handing them to the agent later.
The compiler is the permission planner. It decides which credentials enter the agents’ environments and which remain at the trusted gateway, labeled “trusted root.” The checker validates the allocation before execution; the runtime selector then works within that fixed allocation.
The model uses separate token pools for different agents and nested permission scopes: a broader token can serve every operation a narrower token can serve. Together with the specified workflow structure, these assumptions make exact planning possible. The completion guarantee is for the paths described by that model.
Choose for the remaining workflow, not just the current call
During execution, the runtime selector considers what would remain after each eligible token is used: the unused credentials, the possible future steps, and the unspent gateway allowance. It first checks that the remaining credentials, across the agent and gateway, can still support every permitted continuation. It then checks how many of those remaining operations may need the gateway, and whether that fits the allowance.
The hub example shows why both checks matter. After a local charge, the system still has two unused tokens in total, but only one can refund. Two remaining tokens are not enough when both remaining operations may require refund permission. After a gateway charge, both unused tokens can refund, so the remaining work needs no further mediation.
For nested permissions, ActWithin can express this reasoning as cumulative capacity checks. In a two-level example, it checks how many remaining calls could require refund-capable tokens, and how many calls could remain in total. With more permission levels, it first checks calls that require the broadest credentials, then progressively includes calls that narrower credentials can also serve.
Once the remaining full token pool can cover every continuation, the largest shortfall between required capacity and remaining local capacity gives the worst-case number of gateway calls still needed. A candidate choice must leave that number within the remaining allowance.
The selector repeats the calculation as the next step becomes known. It does not predict whether a customer will return an item. It preserves enough capability for the return paths that the workflow allows.
Combine local requirements across agents
The same reasoning has to account for workflows in which several agents may act. Because they have separate credential pools, a spare token held by one agent cannot simply be treated as available to another.
If all agents in a group must run, their worst-case gateway requirements add. If any two may run, the workflow must accommodate the two largest requirements. For three candidates needing at most 1, 3, and 5 gateway operations, respectively, allowing any two to run requires an allowance of 8.
There is an important asymmetry here. Gateway demand depends on which agents actually run, but initial exposure counts credentials issued to all candidates—even those that ultimately remain inactive. The planner therefore cannot minimize exposure by pretending it already knows which agents will be selected.
ActWithin uses dynamic programming to combine the per-agent tradeoffs. It compares the exposure costs of different gateway-budget allocations and combines their demand summaries according to the workflow’s required and optional groups. This avoids listing every possible active-agent combination while preserving the worst-case completion requirement.
Separate credential planning from payment approval
The runtime selector answers a resource question: which credential should serve this operation without stranding the rest of the task? The gateway must answer a different question: is the requested operation actually approved?
For the hub purchase, the store’s trusted checkout service can sign an approval record binding the customer, the $80 amount, and the order. The gateway verifies that evidence and its continued validity before using its charge-only token. A hostile message cannot replace an approval from that separate service.
Both execution routes also require enforcement. The runtime design binds each committed operation to consumption of its token, alongside scope, amount, and single-use checks. A copied credential must not create an additional spendable grant. These checks apply whether the operation uses a token issued to the agent or one retained at the gateway.
The solid route uses an issued token. The dashed route uses a retained token after the gateway checks external approval evidence. Both pass through the atomic enforcement step, which records the committed operation together with the token’s consumption.
This distinction also defines the security boundary. The agent’s two refund-capable tokens remain usable within their scopes, including after a compromise. ActWithin minimizes that initial exposure while preserving the ability to complete the workflow. It does not treat every action within a credential’s scope as proof of customer approval.
What the experiments tested
We tested the planner and runtime selector in CPU-only simulations of 253 workflows. These covered purchases from paid APIs listed through x402, permission-limited API calls, and generated branching tasks. Every tested case completed within its gateway allowance under three execution schedules, including interleaved execution across agents.
We also evaluated scale with 24 configurations and three seeds each, for 72 ActWithin runs. The largest workflows contained 1,024 candidate agents and 12,288 tokens. Across those runs, planning took less than two seconds on an M1 Max with 32 GiB of memory. Every returned plan passed checking and completed execution within budget. These timings measure permission-planning computation, not payment-network latency.
The gateway allowance is 128 operations and the time axis is logarithmic. Points show median completed times over three seeds; triangles mark the 10-second timeout. SortedSummary is another exact method that stores lists of the largest requirements within each workflow group. ChainStatic divides the allowance evenly; RobustMarginal allocates it greedily.
The planning and runtime components solve two parts of the same problem. The planner finds a small initial grant that can support the task; the selector preserves that ability as credentials are consumed and branches become known. For a payment agent, having permission to make the next call is not enough. It must also leave enough permission to finish the job.