AgentCore payments Spend Limits: Separating Who Sets a Budget from Who Spends It

When you let an AI agent pay for access to web content or APIs, there are two broad things to think about.

One is the mechanism that keeps it from paying more than the amount you set. The other is the decision about which work, which recipients, and how much spending to allow.

On October 13, 2026, Amazon Web Services (AWS) described, on its Machine Learning Blog, a setup that combines Anchor Browser, a cloud browser automation service, with AgentCore payments so that agents can make payments.

Using that post and the related official documentation, this article looks at how to design these two things separately.

This article focuses on small automated payments using HTTP 402.

AgentCore payments handles payments in stablecoins (crypto assets designed to track the value of a currency such as the US dollar), but the regulatory and accounting treatment of crypto assets is out of scope here.

What AWS described: spend limits apply per session and are enforced outside the agent

According to AWS, AgentCore payments is a managed service that lets agents pay for APIs, MCP servers, and web content protected by protocols such as x402.

x402 is a mechanism in which a server returns HTTP 402 (Payment Required), and the client resends the same request with proof of payment attached.

The flow the blog post describes is roughly as follows.

1. When a browser session with x402 enabled starts, Anchor Browser creates a PaymentSession in AgentCore payments.
2. The browser receives an HTTP 402 response and matches the requested payment method against the payment instrument linked to the session.
3. AgentCore payments checks the amount against the session’s spend limit and, if it is within range, signs the proof of payment.
4. The browser resends the original request once with the proof attached, and the merchant verifies and settles the payment.

A PaymentSession is a payment unit with a validity period, and it can also have a spend limit.

Signing here means producing a cryptographic proof that authorizes payment from a wallet.

AWS says spend limits are enforced at the infrastructure layer. Signing takes place within AgentCore payments, without exposing key material to the browser or the agent’s runtime.

The AgentCore payments security guide likewise says that because limits and validity periods are enforced at the infrastructure layer, prompt injection and model non-determinism cannot override them.

Published constraints: Anchor’s built-in feature versus using AgentCore directly

The blog post does not give specific amounts or time limits, but the related official documentation does.

Anchor Browser’s guide “Automatic x402 Payments,” which we checked on October 14, 2026, describes the feature as being in preview. It sets a maximum x402 spend of US$0.01 per browser session, and the payment authorization expires after 480 minutes even if the browser stays open. The same guide says the x402 setting covers payments for access to third-party resources and does not pay for the browser session itself.

When you use AgentCore payments directly, the API requires a session validity period of 15–480 minutes. A session-specific spend limit is optional.

We could not confirm from Anchor’s guide whether users can change the spend limit or the validity period. The US$0.01 limit is stated for Anchor’s feature; it is not a limit on AgentCore payments as a whole.

Before deployment, confirm who can set and change which conditions in your own setup.

Being able to pay within budget is not the same as the spending being necessary

The spend limit is not the only thing AgentCore payments checks before a payment.

According to the troubleshooting documentation, it validates x402 payment requests before signing, including their format, network, currency, amount, and the format of the recipient address, and it rejects malformed or unsupported requests without consuming budget.

Whether the recipient is one the company has approved for payment, however, is a separate question.

The AgentCore payments security guide states that restrictions on the recipient address in the payTo field are not enforced server-side. The application must therefore check whether that recipient is allowed before submitting the payment request.

Its recommendations include keeping an allowlist of pre-verified recipients, never letting the model generate recipient addresses, and restricting recipients through the wallet provider’s policies.

The same guide also notes that session limits bound how much an agent can spend, not who it can pay. It also describes using AgentCore Gateway to restrict tool calls through policies, combining a restriction on which tools can be used with a restriction on how much can be paid and for how long.

Even when the spend limit and the payment request format are in order, that alone does not tell you whether the purchase is needed for the work or whether the same content is being bought twice.

At MIF, we recommend defining spend limits, specifying what the money may be used for, and identifying approved recipients.

Separating the permission to set a budget from the permission to spend it

The AgentCore payments documentation on IAM, which controls who can perform which operations, describes two roles: one for managing payment instruments and sessions, and another for executing payments. In the example, the management role explicitly denies payment execution. The documentation warns against allowing the same role both to create sessions and to execute payments.

The stated reason is that if the payment-executing role can create new sessions, it can create a new session with a larger budget and get around the intended spending limit.

At MIF, we recommend separating the process that allocates a budget from the process that uses it to make payments. Before deployment, check whether the agent or process that makes payments can increase its own budget or create additional sessions.

A separate management process can allocate budgets according to approved business rules. The agent or process executing payments should not be able to change or add to its approved spending allowance.

Also review who can access wallet credentials. The prerequisites documentation warns that if Stripe (Privy) secrets are accessible to anything other than the AgentCore payments service role, wallet operations could be performed outside AgentCore’s budget enforcement and audit controls.

Managing session limits separately from total spending

A session limit in AgentCore payments is the maximum that can be spent within that session. It needs to be kept distinct from the total across multiple sessions.

If you set a limit of $10 per session and allow 100 sessions, the total can reach $1,000 even though each session stays within its limit. If you also manage spending per task or per day or month, check the total across sessions.

So decide which of these units your spending limits will apply to:

• A single payment
• A single session
• A single task or request
• Daily or monthly totals

Also, even after a payment is denied, the browser and model may keep running and incur usage charges separate from the payment.

We recommend setting the payment limit separately from limits on retry counts and run time.

Deciding what happens after a payment is denied

According to Anchor’s guide, if the merchant response is malformed, no compatible network is offered, the budget is used up, or AgentCore rejects the payment, the original 402 response is returned to the page as is. The AgentCore payments documentation likewise says that when a session expires or reaches its limit, further payment requests within that session are denied.

In other words, what stops first is payment within that session; the agent’s work as a whole does not stop automatically. The calling application needs rules for what happens next: stop the task, try another information source, or ask a person for guidance.

The HTTP 402 response alone may not reveal whether the cause is an exhausted budget, an expired session, or a mismatched payment method.

AgentCore payments can send records to CloudWatch that include the session ID, payment amount, remaining budget, and recipient, but you need to configure log and trace delivery to use them.

Use the payment service’s status information and logs to define the following handling rules:

• Conditions for stopping retries, and limits on their number and duration
• Conditions for notifying a person, and who to notify
• How to keep a failed retrieval from being passed to the next step as a success

The “resend once” that the blog post describes refers to the browser’s payment handling for a 402 response. It does not mean that the higher-level agent is limited to one attempt at the same task.

The payment API’s PROOF_GENERATED status indicates that a signed proof of payment has been created. Before retrying, check whether a payment proof was generated, whether the payment settled, and whether the requested content was retrieved.

The security guide also calls for mechanisms that prevent duplicate payments on retries, and for not retrying indefinitely.

A checklist before allocating a budget

The table below sets out MIF’s suggested checks. Adapt them to the product’s constraints and your own business and approval rules.

What to decide	Questions to answer	Settings, processes, and records (examples)
Spending purpose and limits	What business purpose do the payments serve? How much is allowed per payment, per session, and across the entire task?	Budget approvals, service limits, spend-management controls
Validity period and additional budget	How long may the payment session remain valid? Who approves a longer validity period or additional sessions?	Session settings, management processes, approval records
Approved recipients	Where are permitted sites, APIs, and payment recipients verified and restricted?	Application-side validation, endpoint and wallet policies
Funding source and associated costs	Which funds are used, and who is billed? How are payments to third parties and runtime costs managed?	Service agreements, wallet connections, accounting records
Budget-setting and payment permissions	How are permissions to set budgets kept separate from permissions to execute payments?	IAM permissions, internal roles and responsibilities
Failed or uncertain payments	When should retries stop, and whom should the system notify? How is the status of a payment with an unknown outcome checked?	Error handling, execution-time and retry limits, operating procedures
Records and review	How are recipients, amounts, outcomes, sessions, and the relevant business request linked in the records? Who reviews those records?	Payment records, approval records, monitoring and review procedures

Set the limit based on the business purpose and the amount needed to complete the work. Being able to absorb a loss is not the same as approving the expenditure.

The AgentCore payments security guide likewise recommends keeping the limit to the minimum the task needs, using a short validity period, and starting with conservative budgets that are raised only as the agent proves reliable.

Summary: separate budget-setting from payment execution

The setup described by AWS enforces configured per-session spend limits outside the agent’s runtime and keeps key material out of that runtime.

At MIF, we recommend defining the purpose and permitted scope of spending, then keeping budget-setting permissions separate from permissions to execute payments. Budget allocation can be automated, but the company should still specify who may approve and change the spending rules.

Manage total spending across sessions as well as individual session limits. Define approved recipients, the conditions for authorizing additional budget, and how denied payments or unknown outcomes should be handled.

Before deployment, check that these decisions are implemented in the system’s settings, that payment outcomes can be traced in the records, and that procedures for retries, notifications, and putting work on hold are in place.

Sources and scope

This article draws on the following sources, reviewed as of October 14, 2026.

• Amazon Web Services, AWS Machine Learning Blog, “Building agents that transact with Anchor Browser and AgentCore payments” (October 13, 2026)
• Anchor Browser documentation, “Automatic x402 Payments”
• AWS, Amazon Bedrock AgentCore Developer Guide: “Create a payment session,” “IAM roles for AgentCore payments,” “Security in Amazon Bedrock AgentCore payments,” “Troubleshooting AgentCore payments,” and “Observability with Amazon CloudWatch”; and the API Reference: “CreatePaymentSession” and “ProcessPayment”

Descriptions of the products are based on materials published by AWS and Anchor Browser. MIF has not independently tested their actual behavior or the effectiveness of their controls.

The approaches to budget management, the division of permissions, and the checklist table reflect MIF’s analysis and recommendations based on the published materials.

Anchor’s automatic payment feature is described as being in preview, and spend limits, validity periods, availability, specifications, pricing, and supported wallet providers may change.

If you are considering adoption, please check the latest official information.