AWS documented how Incarna deployed an AI-agent payment flow that buys BlockRun model inference one request at a time through Amazon Bedrock AgentCore payments. For builders, the design moves wallet signing and spending limits into managed infrastructure, so agents can pay an x402-compatible endpoint without placing those controls in the model or prompt.
The challenge: Paying for inference by the request
AWS frames inference purchases as a high-frequency, low-value workload. An agent can make hundreds of calls in a session, including calls priced at fractions of a cent, without a person available to approve each transaction. Building that capability independently entails choosing how funds are held, signing each payment, supporting emerging protocols such as x402, and preventing an autonomous process from exceeding its budget.
The implementation described by AWS uses BlockRun as the seller. BlockRun is a pay-as-you-go inference router that AWS says serves more than 90 models from more than 15 providers through x402. Rather than a standing per-provider billing relationship, each request is quoted, authorized and settled independently.
What AgentCore payments provides
AgentCore payments is a managed Amazon Bedrock AgentCore capability that handles the payment protocol, wallet connection, transaction signing and spending enforcement. In Incarna’s arrangement, each agent wallet is provisioned through the Coinbase CDP connector. The customer owns the wallet and delegates authorization to Incarna for its use.
When BlockRun responds to a paid request with HTTP 402, the agent uses AgentCore payments to complete an x402 payment. The service signs using the configured wallet and returns cryptographic proof for the merchant. AWS says payments in this deployment settle in USDC on Base, allowing individual transactions to be checked on-chain. AgentCore payments also works with other x402-compatible endpoints, including Amazon Bedrock inference endpoints.
The flow: Buying and selling one inference
The request sequence begins when an agent needs a model call through BlockRun. BlockRun returns a payment challenge and a price for that specific call. The agent opens a payment session and invokes ProcessPayment; AgentCore payments checks the quoted charge against the session’s spending policy and signs an authorization from the agent wallet address. After the seller verifies that signature, BlockRun delivers the inference and records the per-call charge.
AWS describes two x402 payment schemes. exact is suited to a price known before the transaction. Under upto, an agent authorizes a maximum for a resource with dynamic pricing, and the provider settles actual usage at the end, up to that ceiling. In either case, a request the agent elects not to make generates no charge.
Keeping spend under control
The payment session is the core guardrail in the example. It carries both a maximum amount and an expiry, while AgentCore payments enforces the maximum outside the model. AWS says that means an agent’s code or prompt cannot change the configured ceiling, including if prompt manipulation occurs. Incarna sizes sessions around a day’s budget; a failure in its agent logic therefore cannot spend beyond the customer-set session limit.
That control does not remove the setup requirements behind the workflow. Teams must create a payment credential provider, Payment Manager, connector and payment instrument. The end user funds the embedded wallet and grants signing permission through a redirect flow. AWS says credentials can be stored in AWS Secrets Manager rather than application code, and that the components can be created through its toolkit, CLI or SDKs.
Results
AWS says Incarna put the flow into production on Base, with BlockRun metering and selling the inference while AgentCore payments governs the transactions. Incarna reported that the integration took three days: one day for implementation and two days for testing. It said the application portion was roughly 200 lines of code, compared with an original estimate of two to three months.
According to the AWS post, the beta processed more than 1,000 payments, with individual calls costing from $0.001 to $0.05 and settling separately on-chain. Those timeline, code-size and beta figures are implementation claims reported by AWS and the participating companies, not independently presented performance measurements.
For a practical starting point, AWS recommends configuring the wallet connection and policies, opening a budgeted payment session before the agent task, then directing the agent to an x402-compatible service and calling ProcessPayment after an HTTP 402 response. Source: AWS Machine Learning Blog
Definition. Pay-per-inference is a model in which an AI agent authorizes and settles payment for each individual inference request.
| x402 scheme | How AWS describes it |
|---|---|
| exact | Used when the price is known before the transaction. |
| upto | Authorizes a maximum for dynamic pricing, with actual usage settled up to that ceiling. |
Key takeaways
- BlockRun returns a price and HTTP 402 payment challenge for each paid inference request.
- AgentCore payments handles wallet connection, transaction signing and spending-policy enforcement.
- Incarna provisions agent wallets through the Coinbase CDP connector, with customers retaining wallet ownership.
- Payment sessions set a maximum amount and expiry to constrain agent spending.
- AWS describes exact pricing for known costs and upto authorization for dynamically priced resources.
- AWS reports the beta processed more than 1,000 separately settled on-chain payments.
FAQ
How does an agent pay for BlockRun inference?
After BlockRun returns an HTTP 402 payment challenge, the agent opens a payment session and calls ProcessPayment through AgentCore payments.
What limits an agent’s spending?
A payment session sets a maximum amount and expiry, and AgentCore payments enforces the policy outside the model or prompt.
Who owns the wallet in Incarna’s arrangement?
The customer owns the wallet and delegates authorization to Incarna for its use.
What are the x402 exact and upto schemes?
Exact is for a price known before the transaction; upto authorizes a maximum and lets the provider settle actual usage up to that ceiling.
