Agent payments stop being a demo when the wallet lives outside the model's reach

AWS has published a walkthrough, written with the OpenClaw Foundation, for connecting an OpenClaw agent to Amazon Bedrock AgentCore payments so it can settle an HTTP 402 Payment Required challenge and continue without pausing for a human at every transaction ^[1][2]. The load-bearing part is not the payment itself but the boundary the post draws: wallet-provider credentials and the authority to create or expand a payment session are kept outside the model-facing runtime, which retains only the ability to initiate payments already approved within those limits ^[3].

The economics explain why this is arriving now. Some APIs, content services, compute services and MCP tools price per use, with individual transactions below a dollar or in fractions of a cent, and minimum card-processing fees can make transactions at that scale cost-prohibitive ^[4][5]. Stablecoin payments, per AWS, can support small amounts with near-real-time settlement, which is the argument for HTTP-native schemes such as x402 ^[6]. AgentCore payments is positioned as a consistent payment layer as those protocols evolve, with x402 and the Machine Payments Protocol (MPP) named as the programmatic flows ^[7][8].

The threat model is stated plainly, which is unusual enough to note. The design does not prevent prompt injection; it assumes untrusted input can manipulate the model, and bounds what the runtime is allowed to spend by recipient, asset, network, per-payment amount, session budget and expiry ^[9]. That is six independent dimensions of constraint ^[10], and the point of enumerating them is that none of them are enforced by the model's judgement. A spending limit that the agent's own runtime can rewrite is advisory, not a limit.

In the OpenClaw integration the split is procedural as well as architectural. A human provisions the wallet, creates the payment session, approves recipients and sets the budget from a trusted terminal, while the aws-agents-pay plugin exposes exactly two model-visible tools: get_payment_session_status, which checks the configured session, and get_paid_content, which requests an approved paid URL and completes payment within policy ^[11][12]. The runtime can spend inside an approved session but cannot create, extend or replace one ^[13]. The demonstrated flow is x402 v2: the merchant's 402 challenge is processed through the configured wallet provider, which returns a signed authorization the client uses to replay the request ^[14]. Credentials are held by AgentCore Identity ^[15]. Logs, metrics and traces are available through AgentCore Observability via Amazon CloudWatch and AWS X-Ray, but only when telemetry delivery is configured ^[16].

On the money side, AgentCore payments supports a Coinbase wallet or a Stripe Privy wallet, both embedded stablecoin wallets using AgentCore Identity credential storage and per-session spending limits ^[17]. Funding by stablecoin or by fiat debit card is subject to provider and geographic availability ^[18]. Building any of this yourself means wallet-provider integration, protected credential handling, payment authorization, deterministic limits and payment observability, plus accounting for a model that untrusted input can manipulate ^[19].

Two things to watch. MPP is named alongside x402, but the walkthrough demonstrates x402 v2 only, so the "consistent layer as protocols evolve" claim is still a promise rather than a shown migration ^[7][8][14]. And the walkthrough runs on testnet payments ^[2], so the interesting failure modes, a merchant that is not who it claimed, an expiry that lands mid-workflow, remain untested at mainnet stakes.