Agentic Payments on AWS - Where the Spending Limit Is Enforced, and What It Does Not Stop

First Published: 2026-09-03
Last Updated: 2026-09-03

Design a system that lets an agent call paid APIs and the same question always comes back: what happens if the agent gets used without permission. The answer people reach for is that the agent will be told not to overspend. That is not an answer. An instruction is an input to the model, and an input to the model is something an attacker can write too.

This article answers that question with structure rather than instruction.

Amazon Bedrock AgentCore payments is a managed service that provides a pathway for agents to pay for APIs, MCP servers, and web content. A list of features is not what a reader is after. The questions are what stops the overuse, whether that mechanism can be said to be independent of the model's output, and whether the money is gone once it does stop.

Here is the shape of the conclusion, in four parts.

First, the thing that evaluates the limit sits outside the model. The limit configured on a payment session is evaluated outside the agent's execution environment, before the signing. AWS explicitly states that this check is deterministic and runs at the infrastructure layer. The limit is not affected by the content of the prompt. This single point is the core of this article.

Second, the two limits are not symmetric. The expiry is required, and it ranges from 15 to 480 minutes. The spending limit is optional. Call the API directly and omit the spending limit, and the only thing binding that session is a clock. This asymmetry is not visible in the official product description. It shows up only in the required-field markings of the API reference.

Third, this boundary does not stop the recipient. AWS itself states that the session limit bounds the amount, not the recipient. The service does not validate the recipient address; the caller does. Paying the right amount to the wrong party, with the limit fully respected, is a thing that happens.

Fourth, the primary sources disagree about the availability status. On August 18, 2026, the What's New page announced general availability, and the same day's machine learning blog also stated general availability. However, as of September 2, 2026, the AgentCore FAQ page still contains descriptions from the preview stage. This article will address four such discrepancies, including this one, in Section 10.

Every specification and figure in this article rests on a primary source. The verification date is September 2, 2026. Each kind of claim goes to a different primary source. What happens on AWS comes from the official AWS documentation and the API reference. The x402 and Machine Payments Protocol specifications settle what the protocols require. That split is itself part of the subject, so Sections 5 and 10 take it up directly.

1. What the Phrase Giving an Agent a Wallet Hides
2. Where the Limit Actually Sits
3. What Each Resource Owns
4. The Path a Single Payment Takes
5. Two Protocols on Top of HTTP 402
6. Two Orthogonal Levers
7. What This Boundary Does Not Stop
8. Who Has to Approve
9. Seen from the Side That Returns the 402
10. Where the Primary Sources Disagree with Each Other
11. What Gets Recorded
12. Failure Modes and Anti-Patterns
13. Frequently Asked Questions
14. Summary
15. References

1. What the Phrase Giving an Agent a Wallet Hides

1.1 Intended Audience

This article is written for people who design agents that call external paid APIs, MCP servers, or other agents, and who then have to explain internally what happens if those agents get used without permission. They have probably run agents on AgentCore already, and have not yet built payments into one. They are not implementing on the payment provider's side.

Four questions are assumed to be the ones that matter here. First, what mechanisms are enforcing the limits? Second, can it be stated that these limits are not affected by the model's output? Third, if the limit is reached, or if an error occurs during processing, will funds be deducted? Fourth, what does this limit not stop?

1.2 What This Article Does Not Cover

This article does not discuss cryptocurrency prices, specific tokens, or yields. It focuses solely on the API contracts and permission design for payment protocols. It contains no information related to investment decisions.

It also gives no figures for fees, unit prices, gas costs, or exchange rates. Because the subject is microtransactions, it does touch on one structural point: the economics break down once fees exceed the value of the transaction. It stops short of amounts.

It also leaves out the internal implementation of wallets and blockchains. Key storage methods, signature algorithms, and chain consensus mechanisms are outside the scope of this article. From the perspective of an agent developer, these are areas owned by the payment provider you connect to.

It does not write out attack procedures or evasion techniques. It stays on the design of defenses.

It does not address Cedar grammar or default-deny design. Amazon Bedrock AgentCore Policy Implementation Guide owns that. Section 6 shows only that which tool may be called and how much it may spend are orthogonal levers, and hands the rest over.

It also leaves out how a chain of delegated permissions is recorded. Identity Lifecycle for AI Agents owns that. This article owns how much may be spent, not who granted the permission.

It does not cover how to design credential, session, and data lifetimes. Agent Sandboxing and Blast-Radius Isolation on AWS owns those three lifetimes. The expiry of a payment session is a separate, fourth clock, and this article covers only that fourth one.

It does not lay out the history of the protocols. Tool Use and Agent Protocol History and Timeline owns that. This article covers only the current API contract.

It also leaves out the boundary of execution itself. Workload Isolation Levels on Amazon EKS takes on the question of what ends up in the same box.

Finally, it leaves out the side that notices a boundary has been crossed. Detection Engineering on AWS covers the design of detection rules. Section 11 goes as far as naming what a detection would take as input, and stops there.

1.3 It Is Not the Model That Decides

The phrase giving an agent a wallet leaves something out. What it leaves out is whether the wallet carries a spending limit at all, and who is able to move that limit.

Here are three plain ways to control what an autonomously operating agent spends.

The first method is to provide instructions through the system prompt. You write something like: keep spending within this range. However, this is not true control. The agent's input includes external responses, and those external responses could be written by an attacker. Whether the instructions are followed depends on the model's output.

The second method is to count the agent's spending within its own code. Before each transaction, the code checks the cumulative total; if it exceeds the limit, the transaction is stopped. This can provide control, but the decision to stop is made within the agent's execution environment. If other code running in the same environment is modified, or if multiple agents are running concurrently, the counting mechanism can fail.

The third method is to move the record of spending and the evaluation of the spending limit outside the agent's execution environment. The agent can request payments, but it cannot read or write to the spending limit itself. AgentCore payments implements this third method.

The AWS developer guide describes this characteristic as follows:

The infrastructure layer enforces these limits, so prompt injection and model
non-determinism cannot override them.

This is a strong statement. Therefore, this article will, in Section 2, define the scope of what this statement promises, and in Section 7, quantify its limitations. It promises only two things: the amount and the time. It makes no promises beyond that.

1.4 What the Published Articles Already Own

Before you begin, keep the following in mind to minimize confusion.

Topic	Article That Owns It	Relationship to This Article
Which tool may be called	Amazon Bedrock AgentCore Policy Implementation Guide	A separate, orthogonal lever. This article only shows the connection, in Section 6.
The record of who delegated what	Identity Lifecycle for AI Agents	This article owns how much may be spent.
Credential, execution environment, and data lifetimes	Agent Sandboxing and Blast-Radius Isolation on AWS	The payment session expiry is a fourth, independent clock.
A2A, MCP, and AgentCore Gateway	Agent Interoperability Architecture on AWS	A connection path to paid MCP servers. Referenced in Section 9.
Protocol history	Tool Use and Agent Protocol History and Timeline	This article covers only the current API contract.

2. Where the Limit Actually Sits

2.1 The Payment Session as the Unit

In AgentCore payments, the payment session is the boundary for spending. The developer guide defines the term as follows:

A PaymentSession is a scoped payment context that tracks spending for a single
agent interaction.

The unit is one interaction with the agent. The data plane APIs create a session, not the control plane ones, and the call returns an identifier. The agent receives that identifier, together with the payment instrument identifier.

It is crucial to understand that the agent cannot extend a session. An AWS technical article states:

The agent can’t extend its session, and can’t spend beyond the session payment
limits.

The operation to create a session and the operation to make a payment within that session are separate APIs. As Section 7 shows, the two are separated at the level of IAM roles as well.

2.2 The Two Limits Are Not Symmetric

The official documentation states that a payment session has two configurable limits: the maximum amount that can be spent in the specified currency, and the expiry time. That wording reads as though the two carried the same weight. However, reviewing the API reference reveals that this is not the case.

The request body for CreatePaymentSession is as follows:

Field	Type	Required	Constraint
`expiryTimeInMinutes`	Integer	Required	15 to 480
`limits`	SessionLimits	Optional	`maxSpendAmount` is required when it is present
`paymentManagerArn`	String	Required	ARN of the payment manager
`clientToken`	String	Optional	Identifier for idempotency

The expiry time is required, while the spending limit is optional. This means that a session can be created without specifying limits, and the only constraint on that session is the expiry time. The developer guide's terminology also states that the spending limit can be included optionally.

Each session has a configurable expiry duration and can optionally include
spending limits (maxSpendAmount, currency) that enforce payment limits.

This asymmetry carries a design consequence. If a session is created without a spending limit, it will not result in an error. The session creation will succeed, and payments will process. The session will only be stopped when the expiry time is reached. Given that the maximum expiry time is 480 minutes, payments can run for up to eight hours with no spending limit at all.

The AgentCore CLI can close this hole. Pass --auto-session to agentcore invoke and the CLI creates or reuses a session with the default spending limit you configured on the payment manager. However, the CreatePaymentManager request body in the control plane does not include a field to receive a spending limit. That default is something you set through the AgentCore CLI. It is not an attribute of the payment manager resource that the API can read or write. So if you build on the API or the SDK directly, passing limits is the caller's job.

2.3 Only One Currency Today

An amount and a currency together make up the maximum spending limit. The official product description speaks of a maximum spend amount in a specified currency, which reads as though several currencies were on offer. The AWS CLI reference lists the possible values for the currency field as follows:

Possible values:

  * USD

Only one value is listed. The practical implication is straightforward: a design that anticipates budget management across multiple currencies is not currently supported. This is a value that can change, so read it with a date attached. The verification date for this article is September 2, 2026.

2.4 The Check Runs Before the Signing

When the limit gets evaluated is the heart of this design. The machine learning blog announcing general availability explicitly states the order.

Before signing a payment, AgentCore payments checks the request against the
session budget and rejects requests that would push the session past its cap.
The check is deterministic and runs at the infrastructure layer.

The check comes before the signing. It is not a reversal applied after signing has completed. A request that exceeds the limit never reaches the signing, which is the irreversible step.

A different AWS article puts the same property more bluntly. Note where this one comes from.

Prompt injection can’t lift the cap, because the cap is enforced outside the
model.

That sentence is from the article on built-in guardrails, not from the general availability announcement. The security section of the developer guide puts the same thing more carefully, saying that prompt injection and model non-determinism cannot override these limits.

All three expressions refer specifically to the limits themselves, not to general resilience against attacks. AWS explicitly addresses this point in another article.

The design does not prevent prompt injection. Instead, it assumes untrusted
input can manipulate the model and bounds the runtime's authority by recipient,
asset, network, per-payment amount, session budget, and expiry.

It clearly states that this is not a design to prevent prompt injection. It accepts prompt injection as a premise, and bounds the runtime's authority along six axes instead. Section 7 of this article will discuss which of those six axes the service enforces, and which the caller is responsible for.

2.5 What happens to the budget when something fails?

When using a design with a defined limit, a key concern is how failures are handled. If signing fails and the budget goes down anyway, repeated failures eventually leave nothing to buy with.

Regarding this point, four primary sources describe the same behavior using four different phrases. All four are quoted here, so that the difference in wording can be seen for what it is rather than a difference in behavior.

The feature introduction page states:

If a payment signing fails after budget deduction, the budget does not deduct
the failed payment.

The terminology page describes it as automatically reverting.

If a payment signing fails after a deduction, the amount is automatically
rolled back.

The operations explanation page states that the reservation is released. This phrasing is closest to the actual implementation.

If any step fails, the payment limit reservation is released and the transaction
is recorded as FAILED.

An article focusing on the guardrail simply concludes that failed transactions do not consume the budget.

If signing fails after the service has already deducted from the budget, it
rolls the deduction back, so a failed transaction does not consume budget.

Taken together, these descriptions reveal the implementation details. The limit is a reservation, not a simple deduction. This interpretation is further supported by the troubleshooting page, which states that validation happens before it holds budget or signs. And when a failure occurs, the reservation is released.

This reservation-based approach also aligns with explanations of concurrent execution. AWS technical articles state that even when multiple agents are simultaneously making transactions against the same session, the budget will not be overspent. A deduction-based system would fail during concurrent operations, so it must operate on a pre-allocation basis to function correctly.

Two practical implications follow. First, requests that fail due to validation errors do not consume the budget. The troubleshooting page explicitly states that if the x402 payload is invalid, or if the Machine Payments Protocol (MPP) challenge expires, a ValidationException is returned without consuming the budget. Second, there may be brief moments where the remaining budget appears lower than it actually is, before the reservation is released. If the design relies on the remaining balance to determine the next action, this point must be considered.

2.6 This Expiry Is a Fourth Clock

The expiry of a payment session is a different thing from the lifetimes already present in an agent design. Confuse them and you set what you believe is the shortest clock, while a longer one is the one actually in force.

The previously published Agent Sandboxing and Blast-Radius Isolation on AWS covers three of them: the lifetime of credentials, the lifetime of the execution environment, and the lifetime of data. The expiry of a payment session is set independently of all three, and it expires independently of all three.

In one line, the fourth clock is how long the authority to spend stays alive. The execution environment can still be running and the credentials can still be valid, and a payment from that environment still fails once the payment session has expired. Conversely, even if the payment session lasts for the maximum 480 minutes, if the execution environment terminates prematurely due to inactivity, the agent will no longer submit any requests. In design terms, you need to know which of the four clocks runs longest.

3. What Each Resource Owns

3.1 The Resources Split Across the Control Plane and the Data Plane

The AgentCore payments resources sit in two different API references. This separation forms the foundation for the IAM role assignments discussed later.

Resource	API Reference	Function
PaymentManager	Control Plane	Top-level resource that manages payment operations.
PaymentConnector	Control Plane	Connects to external payment providers.
PaymentCredentialProvider	Control Plane	Stores credentials for payment providers.
PaymentSession	Data Plane	The boundary for spending.
PaymentInstrument	Data Plane	The wallet the payment is made from.

This separation directly impacts operational design. Creating PaymentManager and Connector resources is a one-time configuration task. Creating a PaymentSession and a PaymentInstrument, and making the actual payments, repeat at runtime. The credentials required to access the former do not need to be the same as those required to access the latter.

3.2 PaymentManager

A payment manager is the top-level resource you create in your AWS account. Two decisions matter when you create it.

The first is inbound authorization. authorizerType is required and takes one of two values. AWS_IAM authorizes with AWS credentials. CUSTOM_JWT authorizes with a bearer token. As Section 7 shows, this choice makes a decisive difference in any deployment that serves more than one end user.

The second is the encryption key. kmsKeyArn is optional. Supply one and a customer managed key encrypts the data at rest. Leave it out and an AWS owned key does.

Creating a payment manager also provisions a corresponding workload identity in AgentCore Identity. This is why the response includes workloadIdentityDetails. The payment manager's own name can be up to 48 characters long, and its status can take one of seven possible values.

One payment manager can hold several connectors as child resources. How you divide them is an operational call, and the developer guide offers three examples: by application, by environment, and by team.

3.3 PaymentConnector

A connector integrates a payment manager with an external payment provider. There are two types: CoinbaseCDP, which connects to the Coinbase Developer Platform, and StripePrivy, which connects to Stripe using Privy's wallet infrastructure.

There are two routes for supplying credentials. You pick between them with provisionMode, and the default is the manual one.

Quick create is only available with Coinbase. After granting consent to Coinbase once in a browser, the service will prepare and store the credentials. You will not need to generate or paste any keys. On this route the connector enters PENDING_AUTHENTICATION, and the call returns an authorizationUrl. This URL is valid for approximately 10 minutes. If it lapses before you authorize, the connector moves to AUTHENTICATION_EXPIRED and you re-create it.

Manual provisioning means bringing credentials you obtained yourself. Stripe with Privy supports only this route. The credentials are stored within AgentCore Identity as a PaymentCredentialProvider and the connector references them using an ARN. AgentCore Identity keeps the actual credentials in AWS Secrets Manager.

When using Coinbase, an AWS Marketplace subscription is required. The release notes state that this subscription is mandatory, and it is enforced both when creating a Coinbase connector and when performing wallet operations with Coinbase. Call a wallet operation without the subscription and the service returns a SubscriptionRequiredException with an HTTP 403 status code. This exception includes the URL of the subscription and the product name.

3.4 PaymentInstrument

A payment instrument is an embedded crypto wallet that an agent uses to pay merchants on behalf of a user. The only supported instrument type is EMBEDDED_CRYPTO_WALLET.

Each instrument is associated with a single blockchain network. The same wallet address cannot be used across chains, so you keep a separate instrument for each network you support. The developer guide states that the ETHEREUM value covers Ethereum mainnet and the supported EVM-compatible Layer 2 networks, and that SOLANA is the value for Solana-compatible chains.

The instrument's status can take one of four values:

Status	Meaning
`INITIATED`	Creation has begun
`ACTIVE`	Ready for use
`FAILED`	Creation failed
`DELETED`	Deleted

The balance of a newly created instrument is initially zero. Furthermore, even if a balance exists, the agent cannot initiate any transactions until the end user explicitly grants permission. Section 8 takes this up.

3.5 Credentials Never Reach the Agent

One property has to hold in the design. Neither the wallet's private key nor the payment provider's API key ever reaches the agent. The security section of the developer guide specifies the agent's visible scope as follows:

The agent’s view stops at "a permission to spend from a user-owned wallet."

The same section says the wallet keys are held by the provider in self-custody, and not by AWS or the developer. It also says never to pass payment instrument details through prompts, tool inputs, or the context window. The agent only possesses the session identifier and the instrument identifier.

4. The Path a Single Payment Takes

4.1 Seven Stages

The developer guide describes the runtime flow when using x402 in seven stages. The order of these stages is itself the argument of this article, so the table keeps the original sequence.

Stage	What Happens
1	The agent calls a paid tool or endpoint.
2	The merchant returns a `402 Payment Required` response, including the amount, recipient, asset, and network.
3	AgentCore payments checks the active session's spending against the configured limits. A request that would exceed them is denied.
4	AgentCore payments retrieves the wallet credentials from AgentCore Identity, constructs the payment proof, and signs it.
5	The agent resends the original request, attaching the signed payload.
6	The merchant validates the proof and settles the payment on the chain. If validation is successful, the content is returned.
7	AgentCore payments commits the transaction and updates the session spending ledger.

The key point of this table is that Stage 3 precedes Stage 4. The spending limit is evaluated before the signing, not after it. If the order were reversed, the spending limit would merely be a record of a past event, and would not serve as a boundary.

When using MPP, the flow is similar, with only the method of presenting the challenge and credentials differing. The merchant returns the challenge in the WWW-Authenticate: Payment header, and the agent resends the credentials in the Authorization header.

4.2 The Same Path as a Diagram

Where the Spending Limit Is Evaluated in a Single Payment

The diagram makes a single claim. The limit is evaluated before the signing, and that evaluation happens outside the agent's execution environment. A request over the limit therefore never reaches the signing, and nothing is left on the chain.

4.3 What ProcessPayment Returns

The status that ProcessPayment returns from the signing at stage 4 takes a single value.

Valid Values: PROOF_GENERATED

This single value indicates a clear division of responsibility. AgentCore payments is responsible for evaluating the limit, signing, and generating the proof. Whether the payment actually completes depends on whether the merchant validates the proof and settles it. This API's response does not indicate whether the payment was successful. It only confirms that a proof has been generated.

The paymentType field takes two values. CRYPTO_X402 selects the x402 protocol, and MPP selects the Machine Payments Protocol. The appropriate value is selected based on which protocol the merchant used in its 402 response.

5. Two Protocols on Top of HTTP 402

5.1 Both Use 402, and They Specify Different Things

AgentCore payments handles two protocols. The developer guide states that both use HTTP's 402 Payment Required status code for handling payment requests. While both utilize the same status code, they define different processes.

x402 includes the payment requirements within the 402 response itself. The merchant specifies the amount, recipient, asset, and network, and the agent signs and resends this information.

MPP, on the other hand, utilizes the standard HTTP authentication challenge flow. The merchant issues a challenge using WWW-Authenticate: Payment, and the agent responds with credentials in the Authorization header. MPP's official documentation describes this structure as consisting of three core elements: challenge, credentials, and receipt. It explains that using the 402 status code is intended to differentiate between authentication failures and payment obstacles. This specification has been submitted to IETF as a draft.

5.2 The Two x402 Schemes

x402 payloads specify schemes. AgentCore payments supports two of these.

Scheme	Functionality	Constraints
`exact`	Pays the fixed amount named in the payload.	The default scheme. No allowance handling.
`upto`	Pays a metered amount up to a ceiling.	Requires protocol version 2. EVM networks only.

The upto scheme was added at the general availability stage. It allows for usage-based charges, where the user approves a maximum amount, and only the actual amount consumed is charged. The x402 specification states that the meaning of the amount field changes depending on the stage. During the validation stage, it represents the maximum amount the user approves. During the payment stage, it represents the actual amount being paid. The payment amount must be less than or equal to the maximum amount previously approved.

The upto scheme settles through the Permit2 contract, so the paying wallet must have granted an allowance beforehand. AgentCore payments handles this permission grant through a field called permit2AllowanceLimit. Three things about this field are worth knowing.

First, this field is exclusively for the upto scheme. Using it with exact will result in a ValidationException.

Second, setting the permission overwrites any existing value. The developer guide clearly states that approve sets a value rather than adding to it. Therefore, repeatedly setting permissions on a wallet that has already granted permission will result in unnecessary transactions. Only the initial permission grant is required.

Third, granting this allowance is an on-chain transaction, so the wallet pays the network fees for it. This is separate from any amount challenged.

5.3 MPP Methods and Consent to Network Fees

MPP challenges specify a payment method. There are three methods that correspond to the charge intent through AgentCore payments, and support varies depending on the provider.

Method	Coinbase CDP	Stripe and Privy
`evm`	Supported	Supported
`tempo`	Supported	Supported
`solana`	Not supported	Supported

The payment instrument's blockchain network must match the challenge method. If there is a mismatch, the validation will fail due to a network incompatibility.

The part of MPP that needs the most care is consent to network fees. These fees are separate from the challenge amount, and the methodDetails.feePayer flag indicates who is responsible for paying them. If the merchant sponsors them, the buyerPaysGasFees flag has no effect. If the merchant does not sponsor them, or if the flag is absent, the challenge amount does not show these costs. Therefore, AgentCore payments will not sign transactions unless buyerPaysGasFees is explicitly set to true. Omit it or set it to false, and AgentCore payments returns a ValidationException.

Whether that consent is actually required depends on the method. The developer guide states that for the evm method, the settlement facilitator broadcasts the transaction and pays the gas, so no consent is needed. It also states that currently, the solana method only supports server-sponsored fees. Consent is required only for the tempo method, and only when the merchant does not sponsor the fees.

This design is the central focus of this article. Comparing only the challenge amount against the limit does not tell you what actually leaves the wallet. Therefore, the service requires explicit consent for any costs that are not immediately visible.

MPP also has other limitations. Only one challenge can be fulfilled per ProcessPayment request, and only one header can be provided. The supported intent is only charge, and the mode is only pull. Challenges are also short-lived. Once one expires, AgentCore payments returns a ValidationException and consumes no budget. Request the paid resource again to get a fresh challenge, then retry.

Regarding the returned credentials, the developer guide clearly prohibits certain practices.

Do not decode or modify paymentCredential. It embeds the original challenge and
the signed payload, and the merchant’s HMAC binds to those exact bytes. Attach
the value as returned.

5.4 This Is Not the Agent Payments Protocol

There is another name that can easily cause confusion. The Agent Payments Protocol is a protocol for payments that has been discussed in relation to A2A, but it is not what AgentCore payments implements.

AgentCore payments handles versions 1 and 2 of x402, as well as the Machine Payments Protocol. The API reference limits paymentType to CRYPTO_X402 and MPP, and the service accepts nothing else.

The previously published Agent Interoperability Architecture on AWS draws the distinction directly: AWS shipping an agent payments capability is not the same as AWS shipping this protocol. That statement still holds against the primary sources as of September 2, 2026.

The practical implication is straightforward: Do not assume that because AWS supports agent payments, it necessarily supports a particular protocol. The enumerated values in the API reference settle which protocols the service supports.

5.5 Header Names Are Set by the Version and the Transport

This is a place where implementations trip, so the facts are set out plainly.

The AWS developer guide describes sending a signed proof in the X-PAYMENT header as part of the x402 flow. However, the code examples provided in the same guide pass "version": "2".

Looking at the x402 specifications, header names live in the transport specification, and each version has its own transport document. Furthermore, the differences are not limited to just the header name. The location where payment requirements are specified also varies depending on the version.

Version	Location of Payment Requirements	Header Used by the Client to Attach the Proof	Header Carrying the Merchant's Settlement Result
HTTP transport, version 1	Body of the `402` response	`X-PAYMENT`	`X-PAYMENT-RESPONSE`
HTTP transport, version 2	`PAYMENT-REQUIRED` header	`PAYMENT-SIGNATURE`	`PAYMENT-RESPONSE`

The core x402 specification states outright that transport-specific implementation is out of its scope, and it does not contain the term X-PAYMENT at all.

This is not an error in the AWS documentation. It names the header from the version 1 transport. The implication for implementers is not to hardcode the header name. Match it to the version the merchant used in its 402 response.

The receiving end of AgentCore payments is designed to accommodate these differences. paymentInput.cryptoX402 receives the version as a version parameter, and it takes the payment requirements as a JSON object in payload whichever version they came from. Therefore, the only things the calling application needs to change based on the version are where to read the requirements from and which header to attach the returned proof to. The merchant, not the caller, decides which version is in use.

6. Two Orthogonal Levers

6.1 Which Tool May Be Called, and How Much It May Spend

Two separate questions get tangled together when you design agent spending. Which paid tool may the agent call, and how much may that call spend? AWS answers them with two separate mechanisms.

Policy in AgentCore intercepts every call to a paid endpoint exposed through the AgentCore Gateway. Its Cedar engine reads the agent's identity, the tool name, and the parameters, and decides whether to allow the call. This evaluation does not consider the cost.

The payment session limit, by contrast, weighs amount and time. This evaluation does not consider the tool name.

The security section of the developer guide summarizes this relationship as follows:

Policy controls who calls which tool with what parameters.
Payment sessions control how much can be spent and for how long.

6.2 The Two Levers as a Diagram

Two Orthogonal Levers, and the Question Neither One Answers

The two are not in a hierarchy. Neither contains the other, and neither substitutes for the other. Design one and the hole that matches the other stays open.

Design only the Cedar side and a path remains in which permitted tools are called until the budget is gone. Design only the payment session side and a path remains in which an expensive tool that should never have been called is called, comfortably inside the budget.

6.3 The Cedar Side Is Delegated to a Published Article

Amazon Bedrock AgentCore Policy Implementation Guide owns the Cedar grammar, the design that denies when nothing matches, and how the policies get written. This article does not rewrite any of it.

The one thing this article can add is this. Designing a spending limit is not designing tool authorization. The security section of the developer guide also tells you to deny high-cost tools to agents that do not need them, and it assumes you use the two together.

7. What This Boundary Does Not Stop

7.1 It Does Not Stop the Recipient

AWS states the limit of this boundary in a single sentence.

Session limits bound how much an agent can spend, not who it can pay.

The same page spells out what follows from it.

The payTo address specifies the recipient wallet. AgentCore payments does not
enforce payTo restrictions server-side, so your application must validate the
address before calling the ProcessPayment API.

The service does not validate the recipient address. The correct amount can reach the wrong recipient with the limit fully respected.

The developer guide lists the measures that close this gap. These are the ones that finish on the calling side.

Keep an allowlist of pre-verified merchant addresses, and reject anything else.
Never let the model generate recipient addresses.
Validate against the merchant you expected, when processing an x402 response.
Prefer discovery through AgentCore Gateway, which supplies verified addresses.
Apply Cedar policies to constrain which addresses an agent can pay.
Do not cache addresses across sessions. Use the address the merchant supplies now, checked against the allowlist.

The second one is this article's own subject, restated. If the model's output settles the recipient, the value of having the limit at the infrastructure layer drops sharply. The limit only restricts the amount; it does not restrict the recipient.

The same list also includes two measures that cannot be completed on the calling side. One is recipient screening, where the developer guide states that the wallet can, based on its own policies, refuse payments to specific recipients, and it points to guidance for each wallet provider. The other is the payment provider's own policies, which restrict wallet actions such as signing and transfer. In other words, these recipient restrictions are features of the payment provider, rather than limitations imposed by the payment session itself.

7.2 The User Identifier Is Not Always Verified

There is a second gap, and which configuration you choose decides whether it opens. The developer guide states:

On an IAM-configured inbound authorization payment manager, your backend asserts
the X-Amzn-Bedrock-AgentCore-Payments-User-Id header, and AgentCore payments
does not verify it. You are responsible for setting this value correctly.

When the payment manager authorization method is set to AWS_IAM, the user identifier is the value asserted by the backend, and the service does not validate it. The same page also states that end users and agents must not be allowed to influence this header directly.

For configurations that handle multiple end users, the developer guide recommends using CUSTOM_JWT. That configuration hands the service a verified end-user identity. Under AWS_IAM, by contrast, something outside the service identifies the end user. The concept of per-user budgets relies on this identifier.

7.3 Does it stop someone from raising the limit?

A limit is a boundary only when whatever it binds cannot move it. In this regard, AWS presents an IAM design based on five roles.

Role	What it can do
`ControlPlaneRole`	Manages the service, handling payment managers, connectors, and credential providers.
`ManagementRole`	Configures sessions and payment instruments. Explicitly denied the ability to `ProcessPayment`.
`ProcessPaymentRole`	Executes payments.
`ResourceRetrievalRole`	Assumed by the service at runtime. Fetches session and credential state.
`AWSMarketplaceManageSubscriptions`	Subscribes the account to the Marketplace listing, for Coinbase. An AWS managed policy attached to the administrator, not a role that anything assumes.

The developer guide summarizes the intent of this design in a single sentence.

With this pattern, no single role can both raise a budget and spend against it.

A single role cannot both increase the budget and utilize that budget. This is the condition that establishes the limit as a boundary. Conversely, in a configuration where this separation is broken, the meaning of having the limit at the infrastructure layer diminishes. If the agent using runtime credentials can call CreatePaymentSession, that agent can effectively create a new budget for itself.

It is worth noting that some AWS articles describe the same design using four roles. The difference lies in whether the Marketplace subscription is counted as a role; in practice, the core concept remains the same.

7.4 It Does Not Stop a Payment That Buys Nothing Useful

There is one structural limitation worth naming. The system enforces a monetary limit, but it does not verify whether the value received corresponds to that amount.

Consider this: an agent makes a paid API call within the defined limit, successfully completes the payment, and receives the expected content. However, that content proves to be useless. Despite this, the process completes without interruption. The budget goes down, and the record shows a success.

This is not a defect; it is a consequence of how boundaries are defined. Judging whether the content was worth anything belongs to the model and the application, not to the payment infrastructure. The developer guide advises starting with a conservative budget and raising it only as the agent proves reliable. That is the practical answer to this limit.

7.5 It Does Not Stop Costs You Cannot See

As Section 5 showed, network fees are incurred separately from the amount in the challenge. Granting the allowance for the upto scheme is itself an on-chain transaction, and it carries the same fees.

What the official documentation names as the target of the payment session limit is the payment amount. Network fees come out of the wallet's balance of that network's native token. Whether these fees should be included in that limit was not confirmed in the primary documentation. Not having confirmed something is not grounds for stating that it is not counted. That said, if the fees were counted, MPP would have little reason to demand explicit consent on its side. The safer design is to treat the fees as sitting outside the limit.

7.6 In Summary

The Question	What Answers It
How much can one session spend?	AgentCore payments, deterministically, at the infrastructure layer.
How long does one session stay alive?	AgentCore payments. 15 to 480 minutes.
Which tool may be called?	Policy in AgentCore, evaluated by Cedar.
Is the recipient the right one?	The calling application, through an allowlist.
Is the recipient under sanctions?	The payment provider's policy and screening.
Is the user identifier correct?	The backend, under `AWS_IAM`. The service, under `CUSTOM_JWT`.
Who pays the network fees?	The wallet. The service only demands consent when the merchant does not sponsor them.
Was what was bought worth anything?	Nothing answers this.

8. Who Has to Approve

8.1 Funding and Delegation Are Separate Decisions

A payment instrument starts with a zero balance, and the agent cannot transact through it. Getting from there to a usable state takes two decisions, and the end user makes both of them. The developer guide places both outside the agent.

Funding and delegation are two separate end-user decisions, and both are made
out-of-band from the agent:

The first is funding. The end user deposits funds through the payment provider's portal. The developer guide explicitly states that the agent does not have an API endpoint for funding and must not prompt the user or initiate the funding process itself.

The second is delegation. The end user grants the agent signing permission through the wallet interface. Different mechanisms are available depending on whether it is being used with Coinbase or Privy.

8.2 Delegation Is Not Permanent

The developer guide provides a clear warning about the nature of delegation.

Do not assume delegation is permanent, because users can revoke it at any time.
Handle revoked delegation gracefully.

Users can revoke delegation at any time. Attempt a payment after the user revokes delegation and the service returns an error saying the delegated signing grant is no longer active. The troubleshooting page suggests, as a solution in these cases, redirecting the user to the wallet hub URL in the payment instrument response.

The design implications of this are that this path should be treated as a normal branch, rather than an exception. If an agent is designed to operate for an extended period, delegation can be revoked while it is still running.

8.3 Consent Is a Precondition for the Limit, Not a Substitute for It

The AgentCore FAQ puts the requirement for explicit end-user consent before any payment inside its governance section.

Before any payment can be made, end users must provide explicit authorization,
delegating the agent to transact on their behalf.

That consent and the payment session limit sit on different layers. Consent is a one-time decision that this agent may transact on the user's behalf. The limit is a repeated decision about how much a single interaction may spend under that consent.

Consent does not let a payment through that exceeds the limit. Staying under the limit does not get a payment signed once consent has been revoked. The two apply on top of each other.

9. Seen from the Side That Returns the 402

9.1 This Is Not Only About the Paying Side

Everything so far has been the design of the paying side. However, there's also a side responsible for returning a 402 status code within that same process. This section sets out what you take on once you are the one offering a paid API.

AWS clearly distinguishes between these two sides. The agent side is handled by AgentCore payments, and the merchant side can be built from Amazon CloudFront combined with Lambda@Edge. AWS provides reference implementations for both sides.

9.2 What the Returning Side Takes On

Becoming a merchant means, at a minimum, taking on the following.

First, you return the payment requirements in a form a machine can read. For x402, this means returning a payload that includes the amount, recipient, asset, and network. For MPP, it means returning the challenge header. The merchant decides which protocol is used. As Section 5 showed, the paying side adapts to that choice.

Second, you validate the proof. This involves verifying that the received proof is genuine, that the amount matches what was requested, and that it has not expired. The PROOF_GENERATED response from AgentCore payments indicates that this validation is the merchant's responsibility.

Third, you settle. You decide whether to settle on chain yourself or through a settlement facilitator. The upto scheme requires the facilitator's address in the challenge.

Fourth, you design the failure response. The MPP specification states that a 402 status code should be returned even if credential verification fails, distinguishing it from the 401 status code used for authentication failures.

And asking for payment does not stop the callers who never intended to pay. A paid endpoint keeps receiving them, and that load lands before the 402 is ever returned. Therefore, the merchant's design needs a layer that filters requests, separate from the payment layer. AWS WAF for Generative AI covers the same kind of load against generative AI endpoints, and what to do about it. The payment session limits bound the buyer's budget, not the merchant's resources.

9.3 Being Discoverable

Becoming a merchant also means becoming discoverable. AgentCore payments offers the Coinbase x402 Bazaar MCP server through the AgentCore Gateway. The developer guide states the scale of the endpoints exposed by this server as follows:

a ready-to-use Coinbase x402 Bazaar MCP server, which exposes 10,000+
pay-per-use x402 endpoints through the AgentCore Gateway

This figure is AWS's own, not a measurement taken for this article. Listing counts move, so read it with a date attached. The verification date for this article is September 2, 2026.

Being discoverable has two design implications. First, from the paying side, a recipient address obtained through the Bazaar arrives through a verified path. As Section 7 showed, the developer guide recommends discovery through the Gateway as one way of keeping an allowlist, and this is why. Second, from the merchant's side, being listed means you cannot choose who calls you. Controlling who calls is a design at the authorization layer, not the payment layer.

Connecting to a paid MCP server in the first place is the AgentCore Gateway's role, and that role belongs to Agent Interoperability Architecture on AWS.

9.4 What Being a Microtransaction Forces

The most significant difference from traditional payment systems, from the merchant's side, is the scale of the transaction amounts. The developer documentation cites this as a key reason for the system's design, explaining that many transactions involve very small amounts, making them economically unfeasible with traditional payment methods that impose minimum fees.

The structural point to hold on to is a single one: the economics break down once fees exceed the value of the transaction. This constrains the merchant's pricing design. If a single call is worth less than the fee, it cannot be metered at all. This article does not go into amounts, so the observation stops at that structure.

10. Where the Primary Sources Disagree with Each Other

Comparing the primary source materials, four discrepancies were identified. Each one can only be resolved on the reader's side, so they are recorded here as they stand. All dates of verification are September 2, 2026.

10.1 The Same Feature Is Called Both Generally Available and Preview

The What's New post dated August 18, 2026, announced that AgentCore payments is now generally available. The machine learning blog, also dated August 18, similarly states that it is generally available.

However, the section on payments in the AgentCore FAQ remains unchanged.

At Preview, you can build agents that can make instant micropayments with
stablecoins using 3P wallets (Coinbase or Stripe) using x402 or MPP protocol and
enforce session-level spending limits deterministically at the infrastructure
layer.

The AWS for Industries blog states that the feature is available in preview. It is natural that blog posts, being dated documents, reflect the state of the feature at the time of their publication. What makes the situation complex is that the FAQ, a permanent page, still contains the same wording.

Furthermore, the release notes in the developer guide do not mention a general availability announcement. While there are three entries related to payments in the August 2026 section, all describe feature additions. An entry announcing the transition to preview is found in the May 2026 section.

For readers, the implication is that the availability status should not be determined based on a single page. Dated documents and permanent pages need to be told apart. Different teams update the What's New announcements, the release notes, and the developer guide, and at different rates. This article reads What's New, the release notes, and the developer guide together, treating them collectively as representing general availability.

10.2 A Developer Guide Example Reads Fields the API Reference Does Not Define

The payment session section of the developer guide provides three examples of calling GetPaymentSession. The example using the AWS SDK demonstrates how to extract the status and amount spent from the response.

In contrast, the GetPaymentSession response documented in the API reference contains a single element called paymentSession, which holds the creation time, the expiry, limits, and availableLimits. Neither a status field nor a spent-amount field appears in the definition of the response. The equivalent of the remaining balance is found within availableLimits, specifically in the availableSpendAmount field.

The implication for readers is that the response structure should be verified against the API reference. If you directly copy the examples provided on the page, you will encounter errors due to missing keys. And if you work with the remaining balance, note what the name says: what comes back is what is left, not what was spent.

10.3 The Connector States Do Not Agree on a Count

The developer guide's operational overview describes connector states in a two-tiered system. It outlines six core states shared by the payment manager, with an additional four states specific to Coinbase's Quick Create, bringing the total to ten.

The control plane API reference lists twelve values under Valid Values. There are two values not mentioned in the developer guide's description: one representing a deletion state, and another indicating that an AWS Marketplace subscription is required.

However, a third count exists. On the same API reference page, the descriptive text accompanying the status field lists seven values. This contradicts the twelve listed under Valid Values, as they appear on the same page. The descriptive text does not include the four values specific to Quick Create, nor does it include the value indicating that a subscription is required.

The implication for readers is that if the state drives a branch, Valid Values is the authority. The developer guide is a document that simplifies functionality, and the descriptive text in the API reference has inherited that same simplification. The value indicating that a subscription is required is a state that can actually be encountered in Coinbase-based configurations, and it is worthwhile to define how it should be handled.

10.4 x402 Header Names Vary by Version

This relates to the content discussed in Section 5, and it is being documented here as a record of discrepancies.

The AWS developer guide, in its prose description of x402, says to attach the signed proof to the X-PAYMENT header. The examples in the same guide pass protocol version 2.

However, the x402 specifications indicate that header names live in the transport specification. The version 1 HTTP transport defines X-PAYMENT, while version 2 uses PAYMENT-SIGNATURE. Furthermore, the location where payment requirements are included differs: version 1 includes them in the response body, while version 2 uses the PAYMENT-REQUIRED header. The core specification states that transport-specific implementation is out of its scope, and it does not contain the term X-PAYMENT.

The implication for readers is that the header name must not be taken from prose. The version the merchant uses determines the name. Since AgentCore payments accepts payloads for both versions, the implementation will need to support both.

10.5 The Rule Running Through All Four

One thing runs through all four. What is wrong is not the content, but that nothing says which document, of which date, the claim rests on. Availability status is settled by the announcement channel, response shape by the API reference, enumerated values by the API definition, and header names by the transport specification and the version.

Therefore, the solution is also singular: When referencing specifications, always indicate which document and which version you are referring to. The repeated inclusion of verification dates in this article is due to this reason.

11. What Gets Recorded

11.1 Vended Logs and Vended Spans

The observability of AgentCore payments is available in Amazon CloudWatch and AWS X-Ray. The developer guide clearly specifies the level of granularity.

Customers can access vended logs (application logs published automatically to
your CloudWatch log group) and vended spans (trace records viewable in AWS
X-Ray) for every data plane API call

The unit is one data plane API call. Session creation, payment instrument creation, and payment processing all land in the record.

The two carry different things. A vended log is a line in your CloudWatch log group. A vended span is a trace record in AWS X-Ray, and the security section of the developer guide describes those spans as full payment lifecycle traces. A log answers what one call did. A span answers where a single payment spent its time and which step it failed at.

Amazon Bedrock AgentCore Implementation Guide Part 3 owns the vended logs mechanism itself, meaning the delivery destinations and the routes. This article focuses on what payment-related information is included within that mechanism.

The security section of the developer guide names what a log line carries.

Every data plane call is logged (who, what, how much, and to whom).

Four things: who, what, how much, and to whom. As seen in Section 7, while the recipient of the payment (corresponding to "to whom") is not enforced by the service, the record carries it anyway. What the service does not enforce, it nevertheless records.

11.2 What can you ask of this record?

Three questions this record can answer, from a design perspective.

First, whether the limit was reached. AgentCore payments rejects a request over the limit before it reaches the signing, and the rejection still lands in the record. Hitting the limit often means either that the limit does not match the work, or that the agent is calling more than anyone expected. The distribution of the logs will reveal which is the case.

Second, the distribution of recipients. The developer guide lists three examples of potential indicators of unusual spending. These include payments to addresses not on the approved list, an unusually high number of different recipients, and a sudden change in the addresses of known recipients. The list is illustrative, not exhaustive. Nevertheless, all three examples are about recipients. As Section 7 showed, this is the part the service does not actively shut down, so the design relies on detection to compensate.

Third, the breakdown of failures. The type of exception returned indicates whether a request failed validation, whether delegation was revoked, whether a subscription is missing, or whether the wallet provider rejected the signing request.

11.3 Do Not Rely on the Agent's Own Logging

The developer guide includes a brief warning in the observability section.

Don’t rely on agent code to log its own actions.

The reason is the same as the subject of this article. A log that the agent's own execution environment produces assumes that environment can be trusted. The logic behind placing limits in the infrastructure layer and retrieving logs from the infrastructure layer is the same.

Detection Engineering on AWS covers the design that follows, which is how you turn this record into detections. This article will focus on defining the input.

12. Failure Modes and Anti-Patterns

12.1 Design Failures

Using a session in production without specifying an expenditure limit. Since limits are optional, the session can be created even if they are not provided. As Section 2 showed, the only thing binding such a session is the clock. This allows for a maximum of 480 minutes of payments without any limit. While the default settings apply when using the CLI, they do not apply when directly accessing the API.

Granting the authority to create sessions to runtime credentials. As discussed in Section 7, the design of the five roles separates the ability to increase the budget from the ability to use it. If the same credentials can call both CreatePaymentSession and ProcessPayment, the significance of having limits enforced at the infrastructure layer diminishes.

Letting the model decide the recipient. The limit binds the amount, not the recipient. Making sure the recipient came from a trusted source is the caller's job.

Choosing AWS_IAM in configurations that handle multiple end users. Because the user identifiers are not validated, the assumption of a budget per user is not valid.

Setting the expiry to the maximum instead of to the work the agent has to do. 480 minutes is a ceiling, not a recommendation. The developer guide advises the smallest amount you need and a short TTL.

12.2 Implementation Failures

Modifying the merchant's payload before passing it on. The troubleshooting page says over and over to forward the amount, the asset address, and the recipient address unmodified. A validation error caused by your own edit becomes indistinguishable from a malformed payload on the merchant's side.

Decoding or modifying MPP credentials. The merchant's HMAC binds to the original bytes, so any edit makes verification fail.

Passing permit2AllowanceLimit every time. Permission settings are overwritten, not additive. Pass it to a wallet that already holds the allowance and the service broadcasts another on-chain transaction for nothing. It only needs to be sent once.

Passing permit2AllowanceLimit with the exact scheme. This will result in a verification error. This field is exclusively for the upto scheme.

Copying response examples directly from the developer guide. As seen in Section 10, the example for GetPaymentSession reads fields that are not present in the API reference.

Delaying the authorization URL for Quick Create. This URL is valid for about 10 minutes. If it expires, it will be necessary to recreate the connector.

12.3 Operational Failures

Treating a revoked delegation as an exception. Users can revoke at any time. In a long-running agent, the revocation lands while the agent is still working.

Deciding the next action from the remaining balance. As Section 2 showed, the limit is evaluated as a reservation. Until a reservation is released, the remaining balance can read lower than it really is.

Not watching the distribution of recipients. This is the part the service does not stop, so the record is the only place it can be seen.

Assuming that Region coverage matches AgentCore as a whole. As of September 2, 2026, the Regions where AgentCore payments is available are fewer than the Regions where AgentCore runs. There are Regions where AgentCore Runtime works and payments does not. Asia Pacific (Tokyo) is one of them. Do not carry your own exhaustive list; check the official supported-Regions page.

Choosing Coinbase without arranging the Marketplace subscription. Both connector creation and wallet operations fail with a 403. Subscribing needs administrator-side permissions, so this is not always something the developer can resolve alone.

13. Frequently Asked Questions

Can the spending limit be moved through prompt injection?

No. The limit itself cannot be overridden. The AWS developer guide states that the infrastructure enforces these limits and that prompt injection and model non-determinism cannot bypass them. However, this applies specifically to the limit itself, and not to overall resilience against attacks. AWS explicitly states in another article that this design does not prevent prompt injection; it accepts prompt injection as a premise and bounds the authority instead.

When the limit is reached, is money deducted?

No. AgentCore payments rejects a request over the limit before the signing. When a request fails after signing, the service releases the reservation. Requests that fail due to validation errors will not consume any budget.

Do all payment sessions require a budget?

No. The limits parameter in CreatePaymentSession is optional. The required one is the expiry, which must fall between 15 and 480 minutes. If omitted, the session is only constrained by the clock.

Can an agent extend its own session?

No. AWS explicitly states that agents cannot extend their sessions. Furthermore, the role responsible for setting up the session is explicitly denied the ProcessPayment action.

Do the limits restrict the recipient?

No. AWS states that the session limits bound the amount, not the recipient. Validating the recipient address is the caller's responsibility.

What protocols does AWS support for agent payments?

It supports version 1 and version 2 of x402, as well as the Machine Payments Protocol. The paymentType value in the API reference can only be CRYPTO_X402 or MPP. Any inferences suggesting support for other similarly named protocols are invalid.

Which protocol is chosen?

The paying side does not choose it. The merchant does, through its 402 response, so the implementation has to be ready for both.

Can you select a currency?

Essentially, no. As of September 2, 2026, the AWS CLI reference lists only one possible value for the currency parameter. The current design does not support budget management with multiple currencies.

Does the agent have access to the wallet keys?

No. The keys are held by the payment provider. The agent holds only the session identifier and the payment instrument identifier. The developer guide says never to pass payment instrument details through prompts, tool inputs, or the context window.

Does end-user consent happen only once?

Not necessarily. Funding and delegation are separate decisions, and both are made outside the agent. Delegation can also be revoked at any time, so revocation has to be handled as a normal branch.

Does Policy in AgentCore remove the need for a spending limit?

No. Cedar decides who may call which tool with what parameters. The payment session decides how much may be spent and for how long. The two are orthogonal, and designing only one leaves the matching gap open.

Are network fees counted against the spending limit?

This could not be confirmed. What the official documentation names as the target of the limit is the payment amount. Whether network fees are counted against that same limit could not be confirmed from the primary sources. Fees are incurred separately from the challenge amount, so the safer design treats them as sitting outside the limit.

Is AgentCore payments generally available, or in preview?

The What's New announcement of August 18, 2026, states general availability, and the developer guide and release notes are consistent with that. However, as of September 2, 2026, the FAQ page and some blog posts still contain descriptions from the preview period. It is best not to make a determination based on a single page.

14. Summary

It is not the model that decides the limit. The payment session limit is evaluated outside the agent's execution environment, before the signing. AWS states outright that this check is deterministic and runs at the infrastructure layer.

The two limits are not symmetric. The expiry is required, and it ranges from 15 to 480 minutes. The spending limit is optional. Omit it while calling the API directly and the boundary is a clock and nothing else. This asymmetry is not visible in the product description; it shows up in the required-field markings of the API reference.

A request that never reaches the signing does not consume the budget. The limit evaluation is a reservation, not a deduction. Validation failure and signing failure both release it. Four primary sources describe the same behavior in four different wordings. However, once signing succeeds and the merchant settles the payment, the budget will not be returned, regardless of the content received.

There are two protocols: x402 and the Machine Payments Protocol. Both sit on top of HTTP 402, and they specify different things. Support for a protocol with a similar name is not something to infer. Header names are set by the version and the transport, so do not take them from prose.

Whether a tool may be called and how much it may spend are orthogonal. Cedar settles the first, the payment session settles the second. Design one and the hole that matches the other stays open.

This boundary does not stop the recipient. AWS itself states that the session limits bound the amount, not the recipient. Validating the recipient is the caller's responsibility, and constraining the recipient is a feature of the payment provider.

For a limit to truly be a boundary, the entity being limited must not be able to modify that limit. The intention behind the five-role IAM design is to ensure that one role cannot both increase the budget and utilize it. In configurations that break this separation, the meaning of the limit being at the infrastructure layer diminishes.

Designing a limit is not only settling an amount and a time. Who is able to move those two, who vouches for the recipient, and where you observe the things that did not stop all belong to the same design.

15. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi