Технический разбор: AgentCore payments в Amazon Bedrock и инновации в агентной коммерции
Отрасль входит в мир, где миллиарды генеративных ИИ-агентов действуют автономно, выступая от имени людей, принимая решения и выполняя задачи без человеческого вмешательства. Чтобы поддержать этот сдвиг, Amazon Bedrock AgentCore предлагает модульную полностью управляемую платформу, которая помогает разработчикам создавать, разворачивать и эксплуатировать генеративных ИИ-агентов в масштабе. Скрывая сложности управления серверами, безопасности и интеграций, AgentCore выступает базовым инфраструктурным слоем и позволяет разработчикам сосредоточиться на главном — логике агента.
Этот агентный мир уже меняет то, как работают поставщики контента, API и программного обеспечения как сервиса (SaaS). Автоматизированный трафик на вебе все чаще превосходит человеческий, а agentic AI становится быстрорастущим сегментом. Бизнес-модели переписываются: издатели и поставщики API переходят на модель оплаты по мере использования, адаптированную под доступ агентов. Издатели и сети доставки контента (CDN) начинают блокировать и монетизировать агентский трафик. API тоже смещаются к оплате по факту использования, рассчитанной на agentic-трафик. Этот растущий тренд указывает на будущее, где миллиарды агентов автономно обращаются к миллиардам конечных точек, динамически выбирают сервисы и транзакционируют в реальном времени, чтобы выполнить работу.
Хотя ИИ-агенты способны решать сложные задачи через API, MCP и веб-браузинг, они упираются в стену при доступе к платным сервисам и контенту. Доступ к внешним сервисам требует подписки и управления отдельными биллинг-аккаунтами у каждого поставщика, что создает значительные накладные расходы. Дополняет проблему то, что большинство обращений к API и доступов к контенту стоят лишь считаные центы, а традиционные способы оплаты, например кредитные карты, включают фиксированную комиссию за транзакцию (например, 0,30 доллара США), что делает их экономически нежизнеспособными для частых микротранзакций. Сборка из сторонних кошельков, оркестрации платежей, поддержки агентных протоколов вроде x402 (одного из популярных протоколов machine-to-machine-платежей), обработки крайних случаев и сквозной наблюдаемости может занять месяцы работы. Помимо сложности интеграции, разработчикам нужно с нуля строить контуры управления и бюджетные ограничители, чтобы предотвратить неконтролируемые расходы, а также закрывать жесткие требования безопасности и соответствия нормативным требованиям, которые предъявляют платежные потоки.
Amazon Bedrock AgentCore payments создан именно для того, чтобы снять эту сложность. Сейчас сервис доступен в preview и обеспечивает мгновенные платежи платным внешним сервисам без ручной настройки биллинга для каждого поставщика, поддержку stablecoin для экономичных микротранзакций, делающих экономически возможными платежи на уровне субцентов, а также настраиваемые ограничители расходов, которые дают тонкий контроль над бюджетами агентов и лимитами транзакций. В этой статье мы подробно разбираем AgentCore payments с технической точки зрения.
Введение в Amazon Bedrock AgentCore payments
Amazon Bedrock AgentCore payments — это первый управляемый сервис в составе Amazon Bedrock AgentCore, который помогает ИИ-агентам автономно выполнять микроплатежи за платные API, MCP и контент всего за несколько строк кода. Он поддерживает stablecoin для экономичных микротранзакций и настраиваемые ограничители, позволяющие контролировать расходы агента, сокращая трудозатраты разработчика с месяцев до дней. Построенный на безопасной основе AgentCore, этот полностью управляемый сервис ускоряет вывод на рынок рабочих процессов агентных платежей. На следующей схеме показаны возможности AgentCore payments в preview и то, как он взаимодействует с другими сервисами AgentCore.

Рисунок 1: Возможности AgentCore payments.
По своей сути AgentCore payments предлагает простой API, который абстрагирует сложность обработки платежей. Агенты могут совершать транзакции у поддерживаемых мерчантов независимо от их платежного провайдера, сети или базового протокола через один вызов API. AgentCore payments также обеспечивает интеллектуальную оркестрацию платежей, enforcement бюджета в реальном времени и сквозную наблюдаемость. В следующем разделе мы подробно разберем, почему агентные платежи особенно сложны и как AgentCore payments решает каждую из этих задач.
Проблемы
Чтобы построить платежную функциональность, удобную для разработчиков агентов, команда выделила ключевые проблемы и вопросы, с которыми сталкиваются разработчики, когда они наделяют своего агента возможностью оплачивать платные API, MCP и контент.
Как мне профинансировать моего агента?
Первая критическая задача для разработчика — понять, как финансировать агента, который обеспечивает транзакции. Поскольку на кону реальные деньги, это не только задача инфраструктуры, но и задача безопасности. Интеграция со сторонним платежным кошельком кажется очевидным выбором, но разработчикам нужно убедиться, что ключи аутентификации не скомпрометированы. Они должны подтвердить, что настроены правильные механизмы контроля доступа, что определено, кто именно может выполнять операции с кошельком, что механизмы аутентификации надежны и защищены от подмены, а также что по всей системе есть дополнительные слои защиты от несанкционированного доступа и мошенничества.
Для безопасной аутентификации платежных кошельков AgentCore payments использует AgentCore Identity. Разработчики создают payment connector, то есть ресурс интеграции, специфичный для платежного провайдера. Это автоматически разворачивает provider кредитных учетных данных в AgentCore Identity, который хранит платежные учетные данные в защищенном token vault и выдает tokenized access tokens, не раскрывая исходные секреты. Этот credential provider специально спроектирован для высокопроизводительных и безопасных цифровых подписей. Он поддерживает EdDSA, ECDSA и ES256 для операций с кошельком у платежных провайдеров. Криптографический материал хранится в AWS Secrets Manager и не возвращается из API. Каждый payment connector связан с уникальной AgentCore workload identity. Эта workload identity используется для получения одноразового токена доступа, scoped к конкретной workload, из системы credential provider AgentCore. Криптографическая привязка между workload identity и контекстом пользователя обеспечивает изоляцию multi-tenant.
На входе сервис применяет двойную аутентификацию — OAuth и AWS SigV4 — в одном и том же request pipeline для доступа к API AgentCore payments, создавая гибкий слой безопасности. Для вызовов OAuth входящий bearer token валидируется через AgentCore Identity, а claims JWT извлекаются для определения user identity для downstream-операций. Для SigV4 подпись запроса проверяется с использованием AWS Identity and Access Management (IAM).

Рисунок 2: Безопасное хранение учетных данных для AgentCore payments и AgentCore Identity.
Какой платежный протокол выбрать и что нужно строить поверх него?
Ландшафт agentic payments фрагментирован: существует множество конкурирующих протоколов, и разработчики часто не понимают, какой из них подходит для их конкретного сценария. Освоение одного протокола требует значительного времени и усилий, потому что у каждого есть свои нюансы — версии, потоки аутентификации, модели транзакций, — которые нужно понять еще до того, как что-то будет готово к production. Помимо выбора протокола, разработчикам приходится строить собственный слой абстракции, чтобы справиться со всеми этими сложностями. Задача усложняется по мере роста числа комбинаций: работа сразу с несколькими кошельками у разных провайдеров, разными платежными сетями и протоколами превращает то, что выглядит как одна интеграция, в огромную матрицу сочетаний.
Чтобы решить эту проблему, AgentCore payments поддерживает payment orchestration — базовый движок, специально спроектированный для сложности агентных платежей. Он находится между вашим ИИ-агентом и платежными провайдерами и предоставляет единый интерфейс processPayment, который принимает платежный запрос и возвращает payment proof, который агент может предъявить для доступа к платным сервисам. AgentCore payments скрывает сложность протоколов, автоматически управляя многошаговыми платежными потоками, повторными попытками и крайними случаями в популярных agentic payment-протоколах вроде x402. Он обрабатывает различия между версиями протокола — например, x402 v1 и v2 по-разному структурируют требования к оплате и ожидают разные поля, — преобразуя их в данные транзакций, специфичные для crypto-network, реализуя алгоритмы генерации payment proof и безопасно подписывая транзакции через API провайдера при соблюдении заданных вами лимитов расходов. Оркестратор построен по плагинной модели, где каждый платежный протокол и каждый провайдер реализованы как независимый интерфейс. Это означает, что добавление поддержки нового протокола не требует изменений в основной логике оркестрации или в developer-facing API. Разработчики продолжают вызывать тот же интерфейс processPayment, а оркестратор направляет запрос к нужному connector и обработчику протокола в зависимости от требований к оплате.

Рисунок 3: Движок оркестрации платежей AgentCore payments.
Как убедиться, что агент не выйдет за рамки бюджета?
Агенты по своей природе автономны, а значит, неконтролируемые расходы — вполне реальная возможность. Разработчикам нужны механизмы, которые в реальном времени и детерминированно ограничивают расходы, чтобы агент, действующий от имени пользователя или бизнеса, не мог превысить заданные бюджеты — ни на уровне сессии, ни на уровне пользователя. Без таких ограничителей одна неудачная агентная сессия может привести к значительным непредвиденным затратам.
Когда агент выполняет пользовательскую задачу, например бронирует поездку, он может одновременно инициировать несколько платежей (авиабилеты, отель, аренда автомобиля), черпая средства из одного и того же бюджета. Если одна операция прочитает доступный баланс до того, как другая завершит запись, получится устаревшее состояние и перерасход. При реальной конкурентной нагрузке это не крайний случай, а ожидаемое поведение, и ошибка здесь быстро подрывает доверие клиентов. AgentCore payments обеспечивает встроенное enforcement лимита расходов на уровне инфраструктуры, рассчитанное на работу в масштабе. Лимит расходов настраивается как часть payment session — scoped, ограниченного по времени контекста для платежной активности агента с встроенным enforcement лимита расходов — до обработки транзакции. После этого каждый вызов processPayment проходит трехфазный workflow транзакции: сначала доступный лимит расходов резервируется атомарным вычитанием запрошенной суммы. Затем платеж обрабатывается через провайдера. В конце транзакция коммитится при успехе или откатывается при ошибке, возвращая зарезервированную сумму в доступный баланс. Неважно, работает один агент или тысячи одновременно совершают транзакции против одного и того же бюджета: нет устаревших чтений, нет перезаписи и нет перерасхода. Разработчики получают контроль расходов в масштабе без построения собственной логики конкурентности или блокировок.

Рисунок 4: Трехфазный протокол атомарной проверки бюджета.
Как аудитировать расходы агента и измерять успех?
Для агента, который совершает транзакции автономно, разработчикам нужна полная видимость его платежного поведения. Это означает возможность просматривать и аудировать каждую совершенную транзакцию, связывать расходы с конкретными сессиями или задачами и получать высокоуровневые метрики по платежным операциям, таким как общие расходы, процент успешных транзакций и стоимость выполнения задачи. Без надежной observability разработчики не могут оптимизировать издержки, выявлять аномалии или демонстрировать ROI.
AgentCore payments снимает эту нагрузку. Он предоставляет трехкомпонентную managed observability-систему — metrics, logs и traces — которая публикуется напрямую в ваш AWS account и не требует кода инструментирования. Каждая операция API автоматически отправляет метрики Amazon CloudWatch по числу успешных вызовов, числу ошибок и задержке, с разрезом по операциям и платежным ресурсам. processPayment дополнительно отправляет сумму расходов по типу токена, чтобы вы могли точно отслеживать, что именно тратят ваши агенты по каждому типу токена. Структурированные логи доставляются через асинхронный пакетный pipeline и содержат контекст платежного ресурса и request ID для сквозной корреляции. Распределенные трассировки построены на распространении W3C trace context с spans, совместимыми с OpenTelemetry. Эти spans обогащаются платежными атрибутами, включая сумму расходов, оставшийся бюджет и telemetry credential provider, которое показывает производительность многошаговой цепочки подписей на верхнеуровневом span. Вместе это дает разработчикам и бизнесу полную видимость каждого платежного события с трассируемостью по всему стеку выполнения, обеспечивая прозрачность и контроль над тем, что их агенты делают с деньгами.

Рисунок 5: Наблюдаемость, выдаваемая сервисом AgentCore payments.
Как начать работу с Amazon Bedrock AgentCore payments
Чтобы начать, см. раздел prerequisites в документации AgentCore payments. Настроить и использовать AgentCore payments можно через несколько интерфейсов:
- AWS SDK for Python (Boto3).
- AWS Management Console.
- Amazon Bedrock AgentCore SDK.
- Strands Agents и плагин для agent-native интеграции со встроенными hooks x402.
Следующий раздел показывает фрагменты кода, демонстрирующие, как настроить и использовать Amazon Bedrock AgentCore payments.
Одноразовая настройка
Перед регистрацией в AgentCore payments вам нужны API-учетные данные от вашего платежного провайдера. Для Stripe получите secret API key в Stripe Dashboard в разделе Developers → API Keys. Для Coinbase создайте CDP API key в Coinbase Developer Platform, которая выдает имя ключа и пару private key.
AgentCore payments использует эти учетные данные для создания payment connector — интеграции, специфичной для провайдера, которая служит мостом между AgentCore payments и выбранным вами провайдером. Payment connector регистрируется под payment manager — верхнеуровневой сущностью, которая объединяет ваши connectors и instruments и предоставляет единый execution engine, управляющий платежным потоком от provision кошелька до обработки платежа.
Эти учетные данные вы предоставляете один раз на этапе настройки. Далее AgentCore Identity берет на себя хранение учетных данных, используя защищенный token vault, чтобы секреты не были доступны во время выполнения. Сам агент не имеет доступа к исходным учетным данным. Ротация токенов обрабатывается инфраструктурой прозрачно, а вы сохраняете полный контроль над правами доступа credential provider. Только авторизованные роли имеют доступ к генерации одноразовых краткоживущих токенов через AgentCore Identity. Следующий код выполняет одноразовую настройку одним вызовом через AgentCore SDK.
from bedrock_agentcore.payments import PaymentClient
# Создание PaymentClient
payment_client = PaymentClient(region_name="us-west-2")
# Создание payment manager с connector и credential provider
response = payment_client.create_payment_manager_with_connector(
payment_manager_name="myPaymentManager",
payment_manager_description="myPaymentManager description",
authorizer_type="AWS_IAM",
role_arn=ROLE_ARN,
payment_connector_config={
"name": "myPaymentConnector",
"description": "myPaymentConnector description",
"payment_credential_provider_config": {
"name": "myCoinbasePaymentCredential",
"credential_provider_vendor": "<PROVIDER>",
"credentials": {
"api_key_id": API_KEY,
"api_key_secret": API_KEY_SECRET,
"wallet_secret": WALLET_SECRET,
},
},
}
)
# Извлечение деталей из ответа
payment_manager_arn = response["paymentManager"]["paymentManagerArn"]
payment_connector_id = response["paymentManager"]["paymentConnectorId"]
Настройка платежного инструмента
Когда payment manager настроен, вы создаете payment instrument, ссылаясь на payment manager и payment connector. Payment instruments — это то, чем ваш агент пользуется для автономных транзакций. Payment instrument по сути является встроенным кошельком, self-custodial wallet address, поддерживаемым платежным провайдером, но управляемым конечным пользователем.
После создания инструмент нужно пополнить, а также выдать разрешение на подпись, прежде чем агент сможет совершать транзакции. Это действия конечного пользователя, которые следует выполнить до использования payment instrument в агенте. Поток зависит от провайдера платежей:
- Coinbase — в ответе payment instrument вы получаете
redirectUrl, который ведет в WalletHub, размещенный Coinbase. Перенаправьте туда пользователя, чтобы он выдал разрешение на подпись и перевел средства. - Stripe — вы используете предоставленный шаблон URL, чтобы разместить фронтенд-страницу, где конечные пользователи могут выполнить те же действия.
Оба провайдера поддерживают три сценария:
- Crypto-to-crypto — перевод из существующего crypto wallet.
- Fiat-to-crypto — перевод с кредитной или дебетовой карты либо из сторонних кошельков вроде Apple Pay через hosted UI.
- Delegated signing — агент подписывает от имени пользователя с использованием delegated key.
from bedrock_agentcore.payments import PaymentManager
# Инициализация manager
manager = PaymentManager(
payment_manager_arn=payment_manager_arn,
region_name="us-west-2"
)
instrument = manager.create_payment_instrument(
user_id="test-user-123",
payment_connector_id="codeverifymycoinbaseconnector-sfp0lynfjc",
payment_instrument_type="EMBEDDED_CRYPTO_WALLET",
payment_instrument_details={
"embeddedCryptoWallet": {
"network": "ETHEREUM",
"linkedAccounts": [{
"email": {
"emailAddress": "test@example.com"
}
}]
}
},
)
Создание payment session
Вы создаете payment session, привязанную к пополненному инструменту и конечному пользователю, с необязательными явными лимитами платежей и временем истечения. Эта сессия — финансовая граница агента; она определяет, сколько именно можно потратить и в течение какого времени. Идентификатор сессии и идентификатор инструмента передаются агенту при старте задачи. Агент не может продлить свою сессию и не может тратить больше лимитов, заданных для session.
# Создание payment session
session_response = manager.create_payment_session(
user_id="test-user-123",
limits={
"maxSpendAmount": {
"value": "100.00",
"currency": "USD"
}
},
expiry_time_in_minutes=60
)
Автономная обработка платежей
Когда агент получает пользовательскую задачу, он может вызывать платные конечные точки для сервисов, API или контента. Эти платные конечные точки возвращают агенту статус 402 Payment Required. AgentCore payments понимает платежный протокол x402, включая x402 версии 1 и версии 2, и точно знает, как сгенерировать payment proof, необходимый агенту для разблокировки сервиса.
Агент вызывает ProcessPayment, передавая ID сессии, ID инструмента и x402 payload платежа. Внутри AgentCore payments оркестрирует обработку платежа. Он извлекает атрибуты, необходимые для криптографических транзакций, применяет ограничители payment-limits и подписывает транзакцию, чтобы создать payment proof. Эта аккуратная последовательность действий помогает убедиться, что даже если несколько агентов одновременно совершают транзакции против одной и той же session, бюджет не будет перерасходован.
payment_response = manager.process_payment(
user_id="user-123",
payment_session_id=PAYMENT_SESSION_ID,
payment_instrument_id=PAYMENT_INSTRUMENT_ID,
payment_input={
"cryptoX402": {
"version": "1",
"payload": {
"scheme": "exact",
"network": "base-sepolia",
"maxAmountRequired": "5000",
"resource": "https://premiousEndpoint",
"description": "Premium AI joke generation",
"mimeType": "application/json",
"payTo": PAY_TO_ADDRESS,
"maxTimeoutSeconds": 300,
"asset": "0xxxxxxxxxxxxxxxxxxxxxxxx",
"extra": {"name": "USDC", "version": "2"},
},
}
}
)
Сценарии использования AgentCore payments
Когда платежный стек уже на месте, ваш агент может обрабатывать x402-платежи через один вызов ProcessPayment. Те же базовые элементы — сторонние кошельки, бюджеты, привязанные к сессии, и протокол x402 — поддерживают широкий спектр agentic-нагрузок.
| Нагрузка | Что делает агент | Как оплачивает |
| Research agent | Запрашивает несколько платных источников данных в рамках бюджета, чтобы собрать анализ. | Вызывает платные API по HTTP или MCP. Payment plugin обрабатывает обнаружение 402, подпись и повторную попытку для каждого источника. |
| Финансовый аналитический агент | Получает доступ к рыночным данным, торговым сервисам и закрытым базам данных за paywall. | Использует один и тот же платежный паттерн для разных мерчантов через единый payment stack. |
| Browser agent | Переходит по сайтам за paywall, чтобы извлекать контент с множества сайтов. | Перехватывает 402 в headless browser session, оплачивает и вставляет proof header при повторной попытке. |
| Pay-per-intelligence agent | Направляет задачи к наиболее подходящей ИИ-модели и оплачивает по токенам. | Платит провайдеру модели за каждый вызов вместо поддержки подписок на модель. |
| On-demand storage agent | Разворачивает временное хранилище с тарифом pay-per-use. | Платит за вычисления и ресурсы хранения в момент запроса, без предварительно выделенной мощности. |
Каждая нагрузка использует тот же API для разработчика. Разница лишь в том, что агент делает с оплачиваемым контентом, а не в том, как он платит. Следующий пример показывает research agent, который может платить за платный контент.
Глубокий разбор: ИИ-помощник для исследований
Финансовый аналитик обращается к своему ИИ-агенту: «Проанализируй акции Amazon и сравни их с отраслевыми бенчмарками».
Агенту нужны три платных источника: API финансовых данных (0,50 доллара США за запрос), поставщик аналитики цепочек поставок (1,20 доллара США за отчет) и база бенчмарков (0,80 доллара США за набор данных). Backend приложения создает session с бюджетом 10,00 доллара США и передает агенту ID сессии и ID инструмента.

Рисунок 6: Архитектура research assistant, показывающая сквозной поток платежей.
Агент обращается к каждому сервису мерчанта. Каждый из них возвращает HTTP 402. AgentCore payments атомарно проверяет бюджет сессии, подписывает транзакцию через настроенного провайдера кошелька и возвращает криптографическое подтверждение. Затем агент повторяет запрос с proof и получает платный контент. Три мерчанта, три платежа, по одному вызову API на каждый. Общие расходы составили 2,50 доллара США из бюджета 10,00 доллара США, осталось 7,50 доллара США. Аналитик получает полный анализ без ручного вмешательства.
Весь вклад разработчика в платежный поток — это несколько строк конфигурации плагина. Логика агента целиком сосредоточена на качестве исследования: какие источники запрашивать, как синтезировать выводы и когда остановиться.
Работает с любым фреймворком и любой моделью. Этот поток одинаков независимо от того, как вы строите агента. В Strands Agents встроенный AgentCorePaymentsPlugin автоматически обрабатывает платежи. Для других фреймворков ProcessPayment — это обычный REST-вызов. То же относится и к выбору модели. Неважно, рассуждает ли агент с Anthropic Claude, OpenAI GPT, Google Gemini или Meta Llama, платежный поток остается одинаковым.
Комбинируется с остальными сервисами Amazon Bedrock AgentCore. Поскольку payments работают на уровне tool-call, они естественно сочетаются с другими сервисами AgentCore. Начните с приведенного выше примера research agent, а затем добавьте следующее:
- AgentCore Gateway — находите платные MCP tools на Coinbase x402 Bazaar без регистрации у каждого провайдера по отдельности. Один платежный стек дает доступ к более чем 10 000 endpoints.
- AgentCore Memory — сохраняйте результаты исследований между сессиями. Если агент уже купил отчет по цепочкам поставок вчера, memory извлечет этот результат.
- AgentCore Tools — используйте управляемые инструменты, такие как Browser и Code Interpreter, в одном workflow. Browser проходит по сайтам за paywall и оплачивает контент inline. Code Interpreter обрабатывает платные данные: выполняет анализ, строит графики и преобразует наборы данных. API
ProcessPaymentостается тем же, независимо от того, какой инструмент инициировал оплату. - AgentCore Runtime — разворачивайте агента с помощью
agentcore deploy.ProcessPaymentRoleenforced на уровне инфраструктуры.
Добавление новых возможностей AgentCore не требует изменений в конфигурации платежей. Когда платежная инфраструктура уже управляется сервисом, вы можете сосредоточиться на улучшении самого агента: добавлять новые источники данных, уточнять логику синтеза и выходить в новые домены. Перечень сервисов AgentCore здесь не исчерпывающий. По мере развития сервиса те же платежные примитивы будут распространяться на новые возможности.
Очистка ресурсов
После использования очистите ресурсы и смотрите раздел AgentCore pricing для подробностей о стоимости.
Заключение
В этой статье мы разобрали, как AgentCore payments берет на себя платежную инфраструктуру, чтобы вы могли тратить время на главное — создание агентов, способных совершать транзакции в масштабе. Тот же платежный стек, который обслуживает одного research assistant, масштабируется до multi-agent системы, развернутой на AgentCore, с бюджетами на каждого агента, multi-provider wallet и полной observability.
Чтобы начать эксперименты, репозиторий AgentCore payments samples проведет вас через весь путь разработчика. В примерах также есть end-to-end шаблоны сценариев, например оплата данных агентами, оплата API и оплата контента — как отправная точка для собственных рабочих процессов agentic payment.
Начните с этих ресурсов:
- Документация AgentCore payments
- AgentCore payments FSI Symposium Keynote
- AgentCore payments samples: tutorials and end-to-end use-case patterns
- Документация Amazon Bedrock AgentCore, чтобы изучить Gateway, Memory, Tools и Runtime и расширить возможности вашего агента.
AgentCore payments доступен в preview. Начинайте строить агентов, которые могут совершать транзакции.
Материал — перевод статьи с английского.
Оригинал: Technical deep dive: AgentCore payments and innovation in agentic commerce