SoftTech AI Registry
Amazon Web Services · Amazon Bedrock AgentCore

AgentCore payments — autonomous payment execution

AgentCore payments lets an agent or application pay for paid APIs, MCP servers and web content. ProcessPayment validates the request, checks session spending limits, signs the transaction through the configured external wallet provider (Coinbase or Stripe Privy) and returns payment proof for the merchant, using the x402 protocol or the Machine Payments Protocol (MPP). AgentCore payments is payment infrastructure for agents, not an AI model.

Recorded characteristics

Function
Operational path: agent/application → AgentCore payments → PaymentSession → PaymentInstrument → configured external payment provider/wallet → payment proof/transaction → external merchant or paid resource. ProcessPayment (paymentType CRYPTO_X402 or MPP) validates the request, checks the active session's spending against configured limits (denying it if limits would be exceeded), retrieves wallet credentials from AgentCore Identity, signs the transaction through the configured PaymentConnector and returns signed payment proof; the agent then retries the original request with the proof (X-PAYMENT header for x402, Authorization header for MPP). Supported framework integrations (Strands Agents plugin, LangGraph middleware) can automatically react to HTTP 402 responses, process payment and retry with payment proof. This is not native AgentCore payments scheduling or event triggering: payment occurs when the agent encounters a paid resource.
Data access
Uses the PaymentManager's workload identity in AgentCore Identity to retrieve stored payment-provider credentials; operates on the specified PaymentInstrument (an embedded stablecoin wallet scoped to a user ID) within a PaymentSession. Observability: ProcessPayment telemetry can include payment manager, connector, instrument, session, spend amount and currency, remaining session budget, merchant and agent name where supplied. This does not establish anything about downstream merchant audit records.
Actions
Can take actions
External actions
Yes
Human confirmation
Not established
Permission basis
Mixed
Administrative control
Separation of duties: AWS documents a five-role IAM model separating administrator (control plane), management (sessions/instruments), agent execution (ProcessPayment), service operations (ResourceRetrievalRole) and AWS Marketplace subscription (Coinbase only). AWS warns against granting PaymentSession write permissions (e.g. CreatePaymentSession) and ProcessPayment in the same role, because the caller could bypass payment limits by creating new sessions with elevated budgets. Spending controls: each PaymentSession has an expiry time and an optional budget (maxSpendAmount, currency); further payments are denied once the session expires or the budget is reached. These are automated policy controls, not human confirmation.
Default state
Disabled
Availability
Generally available (AWS announcement 18 Aug 2026; preview launched May 2026) in the AWS Regions AWS lists. Not usable merely because AgentCore exists: a PaymentManager, PaymentConnector with provider credentials, a funded PaymentInstrument with delegated signing granted by the end user, a PaymentSession and the relevant IAM authority must all be configured first.
Licensing
Charged under AgentCore pricing; wallet providers are Coinbase (CDP) and Stripe (Privy).
External model or provider
No fixed AI model: AgentCore payments is payment infrastructure; reasoning comes from whatever agent/framework the developer builds. External payment providers: Coinbase, Stripe (Privy).
Limitations and uncertainty
Human confirmation not_established: AWS documents prior authorisation (funding the wallet, end-user delegation of signing authority, IAM permission, session creation, spending limits) and autonomous payment execution, but no universal platform-enforced human approval immediately before each individual payment. Those prior authorisations are not runtime human confirmation. Framework integrations raise interrupts on payment failure, which is not per-payment approval. Permission basis recorded as mixed because multiple distinct runtime authority mechanisms are documented: the caller's IAM ProcessPayment (payment execution) authority, the PaymentManager's service role/workload identity that retrieves wallet credentials, and the end user's delegated wallet signing authority at the external provider; AWS deliberately separates management from execution authority. Unresolved: whether behaviour, limits and proofs are identical across Coinbase and Stripe Privy; no universal maximum transaction limit is documented beyond the configured session budget; downstream merchant audit records are not established; exact delegated-signing mechanics at each provider are provider-defined. Not credited: unrestricted spending, mandatory per-payment human approval, native payment scheduling or event triggers. Documentation contradiction check: no stale Preview wording found on the current developer-guide pages reviewed on 2 Oct 2026.

Evidence