Agentic payments make payment execution part of an AI agent’s work. An assistant could buy a paid API response during research, purchase compute for a job, or manage checkout and refunds for an online store. In each case, payment is not the whole task. It is one step in a workflow that may continue after money has changed hands.
Building such a system means connecting three things: what a user or business has approved, which payment actions the agent can initiate, and how those actions are executed. Integrating a payment API addresses the execution side. It still leaves a developer with an important design decision: how much authority should the agent hold while it carries out the task?
The difficulty is that future steps are not always known. An order might need a shipping adjustment or a refund. Giving the agent credentials for every eventuality makes those paths available, but also gives it more authority to misuse if it is compromised or redirected by malicious content. Keeping every credential behind a trusted service avoids that local exposure, but requires the service to handle every payment operation.
We developed ActWithin to find the space between those two extremes. Given an allowed workflow and a limit on trusted-service involvement, it calculates the least initial authority an agent needs to complete every permitted path. The goal is not to predict what happens next. It is to prepare for the possibilities without giving the agent every available credential.
One order, more than one kind of permission
Consider an agent working for an online keyboard store. A customer has approved an $80 purchase. After checkout, the customer may request one of two follow-ups: express shipping for an additional $10, or cancellation before dispatch with an $80 refund. For this example, at most one of those follow-ups occurs, and it must be authorized before execution.
Suppose the store has two single-use authorization tokens for the order. Here, a token is a scoped API credential: it grants permission for one operation, then is consumed. One token permits only a charge; the other permits either a charge or a refund. Both are restricted to this order and capped at $80 per operation.
The broader token can therefore cover either follow-up. But does the agent need to hold it from the start?
Not necessarily. The store can keep credentials in an authorization gateway, a trusted service outside the agent’s control. The agent submits a request; the gateway checks it and, if approved, executes it using a credential it retains. We call this a mediated operation. Mediation can be automatic—it does not necessarily involve a human approval step—and the credential never has to enter the agent’s environment.
The same task, three ways to place authority
Without gateway involvement, the agent needs both tokens. It can use the charge-only token for checkout and reserve the broader token for the follow-up.
Allow one mediated operation, and the arrangement changes. The agent needs only the charge-only token. The gateway keeps the broader token and handles the shipping charge or refund when required. Allow two mediated operations, and the gateway can handle both steps; the agent needs no payment credentials of its own.
| Maximum gateway operations | Credentials issued to the agent | What the gateway handles |
|---|---|---|
| 0 | Charge-only and charge-or-refund | Nothing |
| 1 | Charge-only | The follow-up, if needed |
| 2 | None | Checkout and any follow-up |
These arrangements support the same approved order. What changes is where the authority sits. In the middle arrangement, for example, a malicious support message cannot make the agent directly use a refund credential it does not possess. It can cause the agent to request a refund, but the gateway must make a separate authorization decision.
With both credentials issued, the agent can refund directly. With the broader credential retained, the gateway must check and execute the refund. In the diagram, “execution domain” is the agent’s environment and “trusted root” is the gateway; c₁ and c₂ are the exposure weights of the narrow and broad credentials.
To compare these arrangements, ActWithin assigns each credential a weight and adds the weights of those issued to agents. This is initial exposure. Let c₁ be the charge-only token’s weight and c₂ the broader token’s weight. These are model inputs; here, broader permissions receive a higher weight. Initial exposure measures authority placed within the agent’s reach, not dollars spent or the probability of an attack.
The three plans therefore have exposure c₁ + c₂, c₁, and zero. Moving a credential to the gateway does not reduce the customer’s approved purchase or refund amount. It reduces the authority the agent can exercise on its own.
Each point is a different initial permission plan. K is the maximum number of gateway-executed operations allowed during the run; a smaller initial grant becomes possible as K increases.
From a checkout example to a permission planner
The keyboard example is small enough to solve by inspection. A workflow with multiple agents, alternative steps, and selections such as “run any two of these five workers” creates many more possible allocations.
ActWithin takes the allowed workflow, the available tokens, their exposure weights, and a gateway-operation allowance. It computes the lowest-exposure allocation that still lets an agent following the plan finish every allowed path within that allowance. A separate checker verifies the plan, and a runtime selector chooses which token to use as the task unfolds.
This result applies to a specific model: tokens are single-use, each agent has a separate token pool, and permissions are nested from narrower to broader scopes. A broader token can perform everything a narrower token can perform, plus additional operations. The workflow describes which steps are required and which combinations may occur. These conditions let the planner account for uncertain future demand rather than assume a particular branch will happen.
The output makes the design choice explicit: for each allowance of gateway operations, how much authority must remain with the agents?
The gateway still needs a reason to pay
A permission plan determines where credentials reside. It does not, by itself, establish that a particular refund is legitimate.
For the keyboard cancellation, a trusted order service could provide a signed approval record binding the original charge, the $80 refund, the original customer, and the order’s current status. The gateway checks that evidence before using its retained token. Because the order service operates outside the agent’s control, text in a support ticket cannot substitute for its approval.
Credentials issued directly to the agent still need scope, amount, and single-use enforcement. They also remain exposed within those limits if the agent is compromised. ActWithin reduces the initial authority in that environment; it does not assume that every decision the agent makes is trustworthy.
What we measured
We evaluated the allocation approach on 85 simulated payment workflows built from public listings of x402 paid APIs. This provides a different payment setting from the store example: an agent purchases API access, a narrow credential covers one endpoint, and a broader credential covers a family of endpoints on the same host. Credential weights represent that permission breadth.
Across all tested gateway allowances, ActWithin’s initial exposure averaged 36.5% of BroadGrant, the baseline that issues every available token. Every tested payment case completed within its allowance, including cases with interleaved operations from different agents.\
Exposure is normalized to BroadGrant. ChainStatic divides the gateway allowance evenly; RobustMarginal allocates it greedily. OfflineOPT knows the future steps and supplies a lower bound. The horizontal axis runs from zero to each workflow’s maximum tested allowance. Five plotted levels illustrate the curves; the 36.5% result averages all tested levels.
ActWithin and the other methods that do not know future steps perform similarly on these workloads. The main empirical pattern is the tradeoff: more gateway involvement allows less authority upfront while preserving completion in the tested model.
For a developer, this turns a broad instruction—“give the agent only what it needs”—into a concrete planning question. Choose how many operations a trusted gateway may handle, then calculate the minimum initial grant that preserves the approved workflow. The agent can be prepared for more than one possible future without holding every payment credential from the start.