AgentPay MCP

Совместим с x402 V1/V2 + Stripe MPP — протокол-агностический контроль расходов.

agentpay-mcp — это человеко-ориентированный уровень доверия и политик поверх товарных платёжных рельсов (x402, ACP, UCP). OWS-совместимый уровень доверия — работает поверх MoonPay Open Wallet Standard. Протокол-агностический уровень доверия — работает и с x402, и со Stripe MPP. Пока x402 обрабатывает $600 млн в годовом исчислении — при этом 40% активности протокола приходится на ИИ-агентов (март 2026) — недостающим звеном является не исполнение платежей. А управление: кто одобрил, сколько можно потратить и что происходит, когда агент пытается превысить свой бюджет. Именно это и обеспечивает agentpay-mcp.

ACP управляет тем, что агенты ПРОДАЮТ. agentpay-mcp управляет тем, что агенты ПОКУПА. ACP (Agent Commerce Protocol) позволяет агентам публиковать услуги, вести переговоры и получать платежи. agentpay-mcp — это дополняющий слой — контроль того, что агенты тратят при потреблении платных API, инструментов и сервисов. Разные задачи, совместимые решения.

Когда ваш агент получает HTTP 402 Payment Required, ему нужно заплатить и повторить попытку — с вашего одобрения, в пределах установленных вами лимитов. AgentPay MCP — это сервер Model Context Protocol, который даёт Claude, Cursor и любому MCP-совместимому агенту платёжный кошелёк с жёсткими лимитами расходов, режимом одобрения человеком и полным ончейн-аудитом.

Экосистема MCP теперь насчитывает 97M+ ежемесячных загрузок и 10 000+ активных серверов — agentpay-mcp — это единственный MCP-нативный полный слой исполнения платежей.

✅ Интегрирован в NVIDIA/NeMo-Agent-Toolkit-Examples (PR #17 объединён) — платёжная инфраструктура для официального агентского тулкита NVIDIA.

📌 Флагманское предложение AgentIndex и песочница для демонстрации платежей: Как агенты безопасно покупают вызовы API и результат доверия AgentPay MCP.

📌 Контекст листинга экосистемы x402 отслеживается в docs/x402-ecosystem-submission.md.

Кто использует agentpay-mcp?

agentpay-mcp создан для трёх типов покупателей, которых объединяет одна проблема: автономные агенты тратят деньги без контроля.

Команды FinOps: agentpay-mcp — это первый слой управления, созданный для ваших рабочих процессов — не только для разработчиков. Лимиты бюджета, пороги одобрения и атрибуция затрат, которые встраиваются в ваши существующие инструменты FinOps.

Related MCP server: 402-mcp

Почему доверие имеет значение

Исследование McKinsey 2026 года по зрелости ИИ-доверия количественно подтверждает то, что уже чувствуют разработчики: возможности агентов опередили управление агентами.

Разрыв доверия — это разрыв развёртывания. Предприятия не говорят, что агенты не работают — они говорят, что инфраструктура надзора (рабочие процессы одобрения, защитные ограничения расходов, проверка личности, аудит-трейлы) не поспевает.

AgentPay MCP решает это напрямую:

• Режим человеческого одобрения — транзакции выше вашего порога требуют явного подтверждения человеком перед исполнением

• Ончейн-лимиты расходов — лимиты смарт-контракта AgentAccountV2, которые код приложения не может переопределить, когда владелец кошелька настроил их в контракте. Инструмент set_spend_policy устанавливает отдельную внутрипроцессную политику (см. docs/security-posture.md для точных границ контроля)

• Аудит-трейл — неизменяемая ончейн-история событий AgentAccountV2 через get_transaction_history (получатель, сумма, номер блока). Попытки платежей, отклонённые до достижения цепочки, не записываются

• Fail-closed — любая ошибка движка политик приводит к отклонению, а не к одобрению

• Некастодиальный — приватные ключи никогда не покидают локальную машину

Когда 88% предприятий имели инцидент безопасности агентов, «доверие по умолчанию» — не жизнеспособная архитектура. AgentPay MCP построен на принципе «проверь, затем доверяй» — это единственная модель, которая масштабируется.

Почему управление затратами важно для MCP-агентов

Протокол Model Context Protocol даёт агентам доступ к мощным инструментам — но в самом протоколе нет встроенного механизма контроля того, сколько стоят эти инструменты. Это не теоретический пробел. Руководство WorkOS 2026 по безопасности MCP явно называет ограничение скорости, атрибуцию затрат и лимиты расходов на вызов нерешёнными проблемами на уровне протокола MCP. Каждый MCP-сервер может взимать плату. Ни один MCP-клиент не обеспечивает соблюдение бюджетов.

Результат: агент с доступом к 10 MCP-серверам может накапливать неограниченные затраты между сессиями, без стандартного способа атрибуции расходов по инструментам, ограничения экспозиции на вызов или остановки зацикленных процессов до того, как они опустошат кошелёк.

AgentPay MCP закрывает этот пробел на уровне инфраструктуры:

Если вы создаёте агентов, которые взаимодействуют с платными API, лимиты расходов MCP и управление затратами MCP — не опция, а разница между демо и продакшн-развёртыванием. AgentPay MCP — это эталонная реализация с открытым исходным кодом для решения этой задачи на границе протокола.

Безопасность и зависимости

AgentPay MCP создан для корпоративных MCP-развёртываний, где безопасность цепочки поставок имеет значение.

• Нулевая зависимость от LiteLLM. Никакой прямой или транзитивной зависимости от LiteLLM или какого-либо тяжелого слоя маршрутизации LLM. Когда версии LiteLLM 1.82.7-1.82.8 были скомпрометированы на PyPI (март 2026), пользователи AgentPay MCP не пострадали.

• Аудируемое минимальное дерево зависимостей. Сервер работает на viem, @modelcontextprotocol/sdk и небольшом наборе аудируемых npm-пакетов. Никакого PyPI. Python runtime не требуется.

• Сигнал доверия для предприятий. Интегрирован в официальные примеры NeMo Agent Toolkit от NVIDIA (PR #17, объединено). Процесс проверки NVIDIA подтвердил уровень безопасности перед объединением.

• Некастодиальная архитектура. Закрытые ключи никогда не покидают локальную машину. Ончейн-лимиты расходов обеспечивают соблюдение ограничений, даже если агент или его ключ скомпрометированы.

• Усиление безопасности развертывания на Vercel. Если вы развертываете ИИ-агентов на Vercel, ознакомьтесь с контрольным списком усиления безопасности развертывания на Vercel перед повторным подключением платных инструментов после любого раскрытия OAuth, панели управления, CI или переменных окружения.

• Готовность x402 к сканированию. Для платных API-демо, которым требуется поддержка x402, читаемая сканером, используйте рецепт готовности x402 к сканированию.

• Наблюдаемость x402 Bazaar. Для платных MCP-инструментов, попадающих в доступные для поиска каталоги Bazaar, используйте рецепт наблюдаемости x402 Bazaar, чтобы охватить поисковые метаданные WithBazaar, единую аутентификацию и обратное чтение EXTENSION-RESPONSES.

• Каналы пакетных расчетов x402. Для повторяющихся платных MCP-вызовов, использующих потоки депозитов, ваучеров, возвратов и претензий, используйте рецепт каналов пакетных расчетов x402, чтобы обеспечить производственную безопасность хранения каналов, лимитов ваучеров, восстановления и аудиторских журналов внецепочечных расчетов.

• Паритет пакетных расчетов x402 для нескольких SDK. Для провайдеров, тестирующих клиенты пакетных расчетов x402 на TypeScript и Go, используйте рецепт паритета пакетных расчетов для нескольких SDK, чтобы подтвердить общее состояние каналов, поэтапные результаты e2e, разделение подписантов, видимость возвратов/восстановления и форму пакета доказательств.

• Готовность x402 к TVM. Для предложений точной оплаты TVM/TON из новых примеров x402 используйте примечание о готовности x402 к TVM, чтобы убедиться, что неподдерживаемые требования TVM закрываются отказом до появления осознанной поддержки подписи, газа, jetton и расчетов.

• UX пополнения x402 MCP. Для сравнения размещенных ссылок на пополнение и управляемых кошельков используйте бенчмарк UX пополнения x402 MCP, чтобы отделить скорость адаптации от шлюзов одобрения, ежедневных лимитов, аудита и некастодиального контроля.

• Готовность к интроспекции каталогов. Для Glama, Smithery и других MCP-каталогов используйте примечание о готовности к интроспекции каталогов для проверенных путей npx, Docker, имени MCP и некастодиальных метаданных.

• Совместимость x402 v2.11 с платным MCP. Используйте подтверждение совместимости для Payment-Signature, payment-response, mcp-session-id, открытых заголовков CORS, порядка инициализации Streamable HTTP, ссылок на квитанции и перехода с Base Sepolia на Base mainnet.

• Метаданные уровня каталога. Используйте подтверждение реестра/листинга, docs/mcp-registry-listing.json, glama.json, smithery.yaml и llms.txt для поисковых роботов каталогов и агентов-покупателей.

• Нейтральный к блокчейну профиль шлюза x402. Используйте подтверждение нейтрального к блокчейну профиля шлюза, схему и фикстуру, чтобы документировать поддерживаемые сети, метаданные фасилитатора/расчетов, политики пробного периода/возврата и манифесты каталогов, не допуская утечки предположений, характерных только для Base, в не-EVM обнаружение.

• Нормализация квитанций x402 для нескольких реестров. Используйте подтверждение нормализации квитанций для нескольких реестров, схему и фикстуру XRPL, чтобы нормализовать метки реестров, активы, цели расчетов, Payment-Signature, payment-response, статус проверки, некастодиальные границы и отказы для неподдерживаемых реестров перед подписанием.

• Профиль предварительной проверки действий кошелька. Используйте профиль предварительной проверки действий кошелька и фикстуру TRON, чтобы требовать симуляцию, лимиты цепочки/ресурсов, разрешенные списки, подтверждение получателя и суммы, рекомендации по nonce и текст одобрения перед необратимыми переводами, обменами или покупками ресурсов.

• Пакет листинга в каталоге машинных платежей. Используйте пакет листинга в каталоге и JSON листинга для каталогов MPP и платных MCP, не заявляя о поддержке неподдерживаемого не-EVM подписания.

• Подтверждение паритета пяти инструментов x402. Используйте подтверждение паритета пяти инструментов и машиночитаемую карту, чтобы сопоставить потоки поиска, проверки, выборки, кошелька и оплаты с локальным подписантом AgentPay и контролем на основе одобрений.

• Граница эскроу и репутации. Используйте подтверждение границы эскроу/репутации, чтобы отделить авторизацию платежей x402 от эскроу задач, идентичности, репутации и подтверждения работы.

• Готовность платного MCP-прокси и обнаружения. Используйте пакет готовности платного прокси и обнаружения и JSON листинга для прокси и каталогов в стиле Toolstem/Cinderwright.

• Динамический дрейф манифеста платного MCP. Используйте подтверждение дрейфа динамического манифеста, схему и фикстуры Rug Munch, чтобы проверять свежие снимки .well-known/x402, предупреждения об устаревших метаданных, ясность отсутствия пробного периода/ценообразования, поддерживаемые сети и свежесть конечных точек каталога перед подписанием агентами-покупателями.

• Установка Smithery для платного MCP. Используйте подтверждение установки Smithery и examples/smithery-paid-mcp-installation для Smithery CLI, Vercel AI SDK MCP, @smithery/api, шлюзов одобрения, лимитов расходов по умолчанию и проверок свежих x402-манифестов. Не заявляйте о живой проверке Smithery, пока листинг не будет подтвержден.

• Нативный x402 против MCP на основе Stripe-прокси. Для разработчиков, сравнивающих AgentPay MCP с новыми репозиториями MCP на основе Stripe-прокси, используйте примечание «нативный x402 против Stripe-прокси», чтобы отделить шлюзы одобрения, лимиты расходов, строки аудита и некастодиальное подписание от заявлений о прокси-биллинге.

• Проверка размещенного x402-прокси. Прежде чем агент заплатит размещенному x402 MCP-шлюзу, используйте контрольный список покупателя размещенного x402-прокси, чтобы проверить заголовки payment-required, ненулевой payTo, разрешенные списки сетей и активов, состояние одобрения, лимит расходов, корреляцию аудита и блокировку объединенных токенов.

• Обнаружение платного MCP и бюджетный ответ. Для сравнения обнаружения, учета и бюджетных платформ в стиле SettleGrid используйте ответ об обнаружении платного MCP и бюджете, чтобы отделить обнаружение каталога от авторизации покупателя x402.

• Паритет потока покупателя для однокомандных x402-инструментов. Для сравнения покупательских CLI в стиле AgentScore Pay используйте контрольный список паритета потока покупателя AgentPay, чтобы подтвердить обнаружение, проверку, пробный запуск, оплату, лимиты расходов, типизированные ошибки оплаты, квоты, отказы без списания, идемпотентность, MCP-доступность и аудит перед подписанием.

• Усиление безопасности платного MCP-шлюза. Для шаблонов Worker в стиле create-mcpay используйте контрольный список усиления безопасности платного MCP-шлюза, чтобы протестировать регистрацию, разбор вызовов, выпуск ключей, атомарный биллинг, области по умолчанию, отказы валидации без списания и строки аудита покупателя.

• Подтверждение работоспособности платного провайдера. Для публичных каналов работоспособности провайдеров в стиле Voidly используйте контрольный список подтверждения работоспособности платного провайдера, чтобы проверить процент успешных операций провайдера, устаревшие серии, состояние квитанций, сеть x402, актив, payTo и маршрутизацию с отказом по умолчанию перед подписанием.

• Пороги качества платных инструментов. Для каталогов с рейтингами в стиле Strale используйте подтверждение порогов качества платных инструментов, чтобы проверить свежие поля оценок, предупреждения об устаревших оценках, снимки работоспособности провайдера, отклонение по минимальному качеству и шлюзы одобрения перед подписанием x402.

• Авторизованные сканирования кибербезопасности. Для платных инструментов безопасности в стиле AgentAegis используйте профиль оплаты авторизованного сканирования кибербезопасности, чтобы требовать авторизацию цели, привязку разрешенных доменов, лимиты расходов на цель, политику частоты сканирования, запросы на одобрение и язык аудиторских квитанций.

• Постквантовая совместимость конвертов расходов. Для вопросов покупателей в стиле PQSafe используйте оценку постквантового конверта расходов, чтобы сопоставить лимиты расходов, разрешенные списки, квитанции x402, шлюзы одобрения и метаданные аудита, не заявляя о реализации ML-DSA.

• Критически важные для платежей закрепления зависимостей. Для путей проверки и подписания x402 AgentPay закрепляет viem точно на версии 2.52.2, применяет то же переопределение корня и запускает дымовую проверку чистой установки перед выпуском. См. политику закрепления зависимостей.

• Элементы управления агентами WhatsApp и SMB. Для нативных для каналов платных агентов используйте рецепт элементов управления платными агентами WhatsApp и SMB.

• Контроль партнерских выплат канальных агентов. Для партнерских и реферальных долей дохода в стиле Axon используйте спецификацию контроля партнерских выплат канальных агентов, чтобы отделить лимиты выплат, одобрение по каждому контакту, строки аудита и опциональные расчеты x402 от одобрения расходов на платные инструменты.

• Дрейф цепочек x402. AgentPay MCP отслеживает базовую линию шаблона пейволла x402 Foundation с точной версией viem 2.52.2 и отключается с отказом для несопоставленных цепочек. При изменениях PaymentWrapper и шаблона пейволла следуйте примечанию о совместимости дрейфа цепочек x402.

Если ваша команда безопасности проверяет зависимости MCP-сервера после инцидента с LiteLLM, npm ls в agentpay-mcp даст вам короткое, проверяемое дерево с нулевой подверженностью цепочке поставок Python.

Доверие и управление — согласование с протоколом A2A

Протокол Agent2Agent (A2A) от Google (v1.0.0) определяет, как агенты обнаруживают друг друга, проходят аутентификацию и взаимодействуют через организационные границы. Спецификация построена на карточках агентов (Agent Cards), схемах безопасности и управлении задачами с участием человека, но она намеренно не определяет управление расходами на уровне протокола.

agentpay-mcp заполняет этот пробел в качестве дополнительного уровня управления. Вот как наши элементы управления соотносятся с архитектурой A2A:

Что это означает на практике

Когда два A2A-совместимых агента совместно выполняют задачу, включающую платные вызовы API:

1. Обнаружение — вызывающий агент читает Agent Card удаленного агента (спецификация A2A)

2. Аутентификация — взаимная аутентификация через объявленные security schemes (спецификация A2A)

3. Управление расходами — agentpay-mcp обеспечивает соблюдение бюджетных лимитов, ведет журнал транзакций и ставит высокоценные платежи на утверждение человеком (уровень agentpay-mcp)

4. Аудит — полный след транзакций в блокчейне обеспечивает доказательства соответствия, независимые от внутреннего состояния любого из агентов

Это позиционирует agentpay-mcp как уровень управления расходами для A2A-совместимых экосистем агентов — дополняя идентичность и управление задачами протокола финансовыми контролами, которые предприятия требуют перед развертыванием автономных агентов.

Примечание: Спецификация A2A v1.0.0 не определяет механизм оценки доверия или сигналов доверия на уровне протокола. Контроли управления agentpay-mcp (лимиты расходов, утверждение человеком, следы аудита в блокчейне) спроектированы так, чтобы быть совместимыми с будущими расширениями, связанными с доверием, по мере развития экосистемы A2A.

Обнаружение AI-агентами

AgentPay MCP спроектирован для обнаружения и использования AI-агентами. Совместим с:

• claude-mem — Состояние платежей (история транзакций, бюджеты, токены сессий) сохраняется как память агента между сессиями через уровень наблюдения claude-mem

• AgentSkills — Устанавливается как кросс-фреймворковый навык в любой совместимой среде AgentSkills (Claude Code, Cursor, Gemini CLI, Antigravity)

• Chrome DevTools MCP — Используется в паре как платежный уровень для браузерных агентов

Установка как навык

Добавьте в конфигурацию любой MCP-совместимой среды:

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x..."
      }
    }
  }
}

Работает с Claude Code, Cursor, Gemini CLI, OpenClaw, Windsurf и любым MCP-клиентом.

Поток 402 — Что это на самом деле делает

Agent calls a paid API
        │
        ▼
   HTTP 402 ←── "Payment required: 0.50 USDC on Base"
        │
        ▼
AgentPay MCP evaluates your policy:
  • Is 0.50 USDC under your per-tx cap?  ($5 limit → ✅)
  • Is this recipient allowlisted?        (api.example.com → ✅)
  • Require human approval?              (under $1 threshold → auto)
        │
        ▼
  Payment sent → API retried with payment proof → 200 OK
        │
        ▼
Agent gets the data. Full tx on basescan.org.

agentpay-mcp против x402-mcp — В чем разница?

Оба проекта обеспечивают платежи агентов. Они решают разные задачи на разных уровнях.

Когда использовать x402-mcp: Вам нужно максимально простое интегрирование платежей x402 без требований к управлению. Ваш агент работает с неограниченными бюджетными полномочиями.

Когда использовать agentpay-mcp: Вам нужны контроли расходов, соблюдение бюджета, рабочие процессы утверждения человеком или поддержка нескольких протоколов. Ваши агенты работают с реальными корпоративными бюджетами, где неконтролируемые расходы являются блокирующим фактором развертывания.

x402-mcp добавляет платежи вашему агенту. agentpay-mcp добавляет управляемые платежи — лимиты расходов, лимиты сессий, утверждение человеком и следы аудита, которые предприятия требуют перед развертыванием агентов против производственных бюджетов.

FAQ: Нативный x402 AgentPay MCP против прокси-решения Stripe MCP

Публичные репозитории MCP-платежей начинают использовать формулировки x402 и Stripe Agent для обнаружения. Относитесь к этому как к рыночному сигналу, а не как к доказательству того, что каждый прокси выпустил полный контроль расходов.

В чем основная разница?

AgentPay MCP сохраняет решение о платеже внутри границ политики агента. Агент запрашивает x402_pay, AgentPay проверяет состояние утверждения и политику расходов перед подписанием, а след аудита записывает инструмент, сумму, мерчанта, квитанцию и результат политики. Паттерн прокси Stripe обычно размещает платежный или биллинговый прокси перед нижестоящим сервисом.

Почему не использовать прокси для каждого платного вызова MCP?

Прокси может помочь с биллингом и агрегацией счетов. Он не отвечает автоматически на вопросы о том, кто утвердил расход, остался ли агент в рамках бюджета задачи или была ли заблокирована подпись до утверждения политики. AgentPay MCP обрабатывает эти контроли до выполнения платежа.

Какие доказательства каталог или покупатель может проверить уже сегодня?

• npm: agentpay-mcp@4.1.9 или новее

• Glama: https://glama.ai/mcp/servers/up2itnow0822/claw-pay-mcp

• Метаданные каталога: glama.json и smithery.yaml

• Пути установки: npx и Docker

• Интроспекция: 27 MCP-инструментов, включая x402_pay, check_budget, set_spend_policy и otel_evaluate_spend

Как это соотносится с Lightning Wallet MCP?

Lightning Wallet MCP — это Bitcoin-кошелек MCP с работой над бейджами для Glama и позиционированием с запасным вариантом x402. AgentPay MCP сосредоточен на управлении платежными инструментами x402: шлюзы утверждения, жесткие лимиты расходов, локальное подписание без кастодиального хранения, метаданные каталога и строки аудита, привязанные к платным вызовам инструментов.

Полный чек-лист см. в Паттерны нативного x402 AgentPay MCP против прокси-решения Stripe.

Для размещенных шлюзов платных MCP используйте Чек-лист проверки покупателя размещенного прокси x402 перед подписанием. Он проверяет заголовки payment-required, payTo, цепочку, актив, лимит расходов, шлюз утверждения, журнал аудита и блокировку объединенных токенов.

Для сравнения однокомандного покупательского CLI используйте Чек-лист паритета покупательского потока AgentPay. Он превращает обнаружение, проверку, пробный прогон, оплату, лимит расходов, типизированные ошибки платежей, квоты, сбои без списания, идемпотентность, MCP-доступ и аудит в фикстуру fail-closed. Для платных шаблонов Worker используйте Чек-лист усиления шлюза платного MCP перед тем, как считать каркас готовым к производству.

Быстрый старт

1. Установка

npm install -g agentpay-mcp

2. Настройка Claude Desktop

Добавьте в ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x...",
        "CHAIN_ID": "8453"
      }
    }
  }
}

3. Настройка Cursor

Добавьте в .cursor/mcp.json или ~/.cursor/mcp.json:

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x...",
        "CHAIN_ID": "8453"
      }
    }
  }
}

4. Установка лимитов расходов

После запуска скажите своему агенту:

Set my spend policy: $1 per transaction, $10 per day, only send to allowlisted addresses.

Или вызовите set_spend_policy напрямую:

{
  "tool": "set_spend_policy",
  "arguments": {
    "perTxCapEth": "0.0004",
    "dailyLimitEth": "0.004",
    "allowedRecipients": ["0xapi-provider-address..."]
  }
}

Теперь ваш агент может платить за API — и не может потратить более $1 за раз или $10 в день, независимо от того, что ему поручено делать.

Режим утверждения человеком (по умолчанию)

По умолчанию транзакции выше вашего порога автоматического утверждения ставятся в очередь на проверку человеком. Агент не может обойти это.

$0.50 USDC request → under $1 threshold → auto-approved → paid → result returned
$5.00 USDC request → over $1 threshold → queued → you get notified → approve or reject

Чтобы утвердить платеж из очереди:

{
  "tool": "queue_approval",
  "arguments": {
    "action": "approve",
    "tx_id": "0x..."
  }
}

Чтобы отклонить его:

{
  "tool": "queue_approval",
  "arguments": {
    "action": "cancel",
    "tx_id": "0x..."
  }
}

Агент видит результат и решает, что делать дальше (использовать кэшированные данные, спросить пользователя, прервать).

Ценные пакеты — Три производственных паттерна рабочих процессов

1. Агент платных API

Что делает: Находит подходящий платный API для потребности в данных, платит один раз, кэширует результат.

Когда использовать: Вашему агенту нужны данные (рыночные данные, обогащение, геокодирование), и вы хотите, чтобы он обрабатывал платеж автоматически, а не завершался с ошибкой 402.

Agent: "I need current options flow data for AAPL"
  │
  ├─ Tries free sources → insufficient data
  ├─ Finds paid API → gets 402 for $0.25 USDC
  ├─ Checks: $0.25 < $1 cap → auto-approved
  ├─ Pays with x402_pay → gets data
  ├─ Caches result at ~/.clawpowers/state/market:AAPL:options
  └─ Returns data + payment receipt

Используемые инструменты: x402_pay, check_spend_limit, get_transaction_history

Пример обмена:

User: Get me the options flow for AAPL for the last 7 days.

Agent: Checking free sources... insufficient. Found paid API at data.example.com.
Cost: $0.25 USDC (under your $1 auto-approve cap). Paying now.
[x402_pay → 200 OK, paid 0.25 USDC, tx: 0xabc...]
Here's the options flow data: [results]
Total cost today: $0.25 of your $10 daily budget.

2. Исследовательский агент

Что делает: Собирает данные сначала из бесплатных источников, заполняет пробелы платными данными, компилирует структурированный вывод.

Когда использовать: Вам нужен комплексный исследовательский отчет, и вы хотите, чтобы агент тратил деньги только там, где бесплатных данных действительно недостаточно.

Agent: "Research competitive landscape for real-time flight tracking APIs"
  │
  ├─ Scrapes free sources (GitHub, HN, docs) → baseline data
  ├─ Identifies gaps: pricing data, SLA guarantees, enterprise contacts
  ├─ Proposes paid lookups totaling $2.75 USDC → presents for approval
  ├─ Human approves
  ├─ Pays for Apollo contact enrichment ($1.50) + Crunchbase data ($1.25)
  └─ Compiles: free data + paid data → structured report

Используемые инструменты: x402_pay, x402_session_start, x402_session_fetch, check_budget

Пример обмена:

User: Research the real-time flight tracking API market. Budget up to $5.

Agent: Starting with free sources... [scrapes 12 sources, builds baseline]
Gaps identified:
  - Vendor pricing (not public for 3 of 5 vendors)
  - Contact info for enterprise sales at FlightAware
  - Recent funding data for two startups

To fill these I'd spend ~$2.75 USDC:
  - Apollo contact enrichment: $1.50
  - Crunchbase firmographics: $1.25

Approve? (y/n)

User: y

Agent: [pays, fetches, compiles]
Report ready. Spent $2.75 of your $5 budget. [structured report attached]

3. Агент автоматизации

Что делает: Выполняет реальные задачи от начала до конца, оплачивая все необходимые сервисы по ходу работы.

Когда использовать: Вы хотите агента, который действительно может завершить работу — забронировать звонок, запустить конвейер обогащения, развернуть что-то — а не просто исследовать это.

Agent: "Enrich this list of 50 leads and add to CRM"
  │
  ├─ Processes first 10 free (from existing data)
  ├─ Remaining 40 need enrichment → $0.10/contact = $4.00 USDC
  ├─ Presents plan: 40 contacts × $0.10 = $4.00 total → user approves
  ├─ Runs enrichment in batches of 10 (staying under per-tx cap)
  ├─ Writes enriched data to CRM via API
  └─ Reports: 50 leads enriched, $4.00 spent, 47 successful

Используемые инструменты: x402_pay, x402_session_start, set_spend_policy, get_transaction_history

Корпоративный FinOps — Шаблоны бюджетных лимитов

Производственные развертывания агентов нуждаются в управлении расходами, удовлетворяющем корпоративным требованиям FinOps. Эти шаблоны показывают распространенные паттерны контроля расходов агентов на уровне инфраструктуры.

Бюджеты отделов на агента

// Marketing agent — $50/day cap, restricted to approved data vendors
{
  "tool": "set_spend_policy",
  "arguments": {
    "perTxCapEth": "0.02",
    "dailyLimitEth": "0.02",
    "allowedRecipients": ["0xmarketingVendor1...", "0xmarketingVendor2..."]
  }
}

// Engineering agent — $200/day cap, broader vendor access
{
  "tool": "set_spend_policy",
  "arguments": {
    "perTxCapEth": "0.04",
    "dailyLimitEth": "0.08",
    "allowedRecipients": ["0xcloudProvider...", "0xapiVendor...", "0xdataSource..."]
  }
}

Многоуровневые пороги утверждения

Сопоставьте матрицу согласований вашей организации с уровнями расходов агента:

$0 - $1      -> auto-approved (routine API calls)
$1 - $25     -> auto-approved with logging (standard tool usage)
$25 - $100   -> queued for team lead approval via queue_approval
$100+        -> queued for finance team approval

Установите потолок автоматического одобрения с помощью set_spend_policy (внутрипроцессный лимит, обеспечиваемый MCP-сервером). Транзакции выше on-chain лимитов AgentAccountV2 — настроенных владельцем кошелька в контракте — попадают в очередь на проверку человеком через сам смарт-контракт.

Мониторинг бюджета для FinOps-дашбордов

Получайте данные о расходах в реальном времени для ваших FinOps-инструментов:

// Check remaining budget before starting expensive workflows
{ "tool": "check_budget", "arguments": {} }
// Returns: { "remaining": "142.50 USDC", "spent": "57.50 USDC", "limit": "200.00 USDC" }

// Pull transaction history for cost attribution
{ "tool": "get_transaction_history", "arguments": { "limit": 100 } }
// Each entry includes: merchant, amount, timestamp, tool context — ready for FinOps import

Эти шаблоны работают с любой FinOps-платформой (CloudHealth, Kubecost, Apptio) — экспортируйте историю транзакций через MCP-инструмент и передавайте её в существующий конвейер атрибуции затрат.

Переменные окружения

# Required
AGENT_PRIVATE_KEY=0x...          # Agent hot wallet key (0x-prefixed hex)
AGENT_WALLET_ADDRESS=0x...       # Deployed AgentAccountV2 contract address

# Optional
CHAIN_ID=8453                    # 8453 = Base Mainnet (default, recommended)
RPC_URL=https://mainnet.base.org # Custom RPC (Alchemy/Infura recommended for production)
SESSION_TTL_SECONDS=3600         # x402 session lifetime (default: 1 hour)
FACTORY_ADDRESS=0x...            # For deploy_wallet and create_escrow
NFT_CONTRACT_ADDRESS=0x...       # For deploy_wallet

# Optional — otel_register_budget_policy circuit breaker
# Comma-separated hosts whose private/loopback/link-local kill-callback URL is
# explicitly permitted. Empty by default: a killCallbackUrl pointing into
# private space is dropped (with a warning) and never POSTed to, though the
# budget policy's spend cap is always registered and enforced regardless.
# Set this only if your circuit-breaker webhook genuinely lives in-VPC.
AGENTPAY_KILL_CALLBACK_ALLOWED_HOSTS=orchestrator.svc.internal

Ограничения SSRF для kill-callback. Значение killCallbackUrl должно использовать http(s), не должно содержать учётные данные и не должно указывать на частный, loopback, link-local или иной не глобально маршрутизируемый адрес (RFC1918, CGNAT, multicast, зарезервированные адреса, назначения протоколов IETF, диапазоны для бенчмаркинга и документации, а также эквиваленты IPv6 и все переходные формы IPv4-в-IPv6). Имена хостов разрешаются и повторно проверяются по тем же правилам непосредственно перед срабатыванием callback. Единый фиксированный таймаут в 10 секунд охватывает и разрешение DNS, и POST вместе, поэтому резолвер, который никогда не отвечает, не может удерживать оценку спана открытой.

Одна брешь не закрыта: соединение не привязывается к адресу, который был проверен, поэтому резолвер, который в момент проверки отвечает публичным адресом, а в момент подключения — частным (DNS rebinding), всё ещё может быть достигнут. Для закрытия этой бреши нужно перенести этот вызов с глобального fetch на node:http/node:https с закреплённым lookup; это отслеживается отдельно. Если вам нужна жёсткая гарантия уже сегодня, поместите перед вебхуком сетевой allowlist исходящих подключений. Недоставленные callback-вызовы сообщают только ok=false с единственной общей причиной — HTTP-статус и конкретная ошибка никогда не возвращаются вызывающей стороне, а только логируются на стороне сервера (только origin, никогда — путь или query callback).

Все 23 инструмента

Платежи и поток 402

Кошелёк и контроль расходов

Операции с токенами

DeFi

Идентификация и доверие

Ключевые примеры инструментов

x402_pay — основной инструмент

// Request
{
  "tool": "x402_pay",
  "arguments": {
    "url": "https://api.example.com/premium-data",
    "max_payment_eth": "0.0002"
  }
}

// Response
{ "status": 200, "body": "{ ... }" }

Если стоимость превышает max_payment_eth, инструмент возвращает ошибку до оплаты — никаких неожиданных списаний.

x402_session_start — платите один раз за несколько вызовов

// Request
{
  "tool": "x402_session_start",
  "arguments": {
    "endpoint": "https://api.example.com/",
    "ttl_seconds": 3600,
    "label": "market-data-session"
  }
}

// Response
{ "session_id": "sess_abc123", "token": "eyJ...", "expires_at": 1741000000 }

// Subsequent calls — no new payment
{
  "tool": "x402_session_fetch",
  "arguments": {
    "url": "https://api.example.com/stocks/AAPL",
    "session_id": "sess_abc123"
  }
}

check_budget — узнайте до начала цикла

// Request — check before starting an expensive loop
{ "tool": "check_budget", "arguments": {} }

// Response
{
  "remaining": "7.50 USDC",
  "spent": "2.50 USDC",
  "limit": "10.00 USDC",
  "periodEnds": "2026-03-24T00:00:00Z"
}

Поддерживаемые сети

Модель безопасности

Некастодиальная модель: агент подписывает все транзакции локально своим приватным ключом. Ни одна третья сторона не хранит и не проверяет ключи.

On-chain контроль (лимиты AgentAccountV2, настроенные владельцем кошелька в контракте):

• Потолки на транзакцию — транзакции сверх потолка попадают в очередь на одобрение человеком через queue_approval

• Лимиты дневного периода — совокупный расход обеспечивается смарт-контрактом AgentAccountV2

Внутрипроцессная политика (set_spend_policy — применяется на MCP-сервере, не on-chain):

• Allowlist получателей, потолки на транзакцию и дневные лимиты — удобное защитное ограничение, которое можно обойти при компрометации серверного процесса. Точные границы контроля см. в docs/security-posture.md.

Разделение ролей:
Подписывающий ключ агента (AGENT_PRIVATE_KEY) может совершать транзакции только в пределах лимитов, установленных владельцем кошелька. Даже если ключ агента утёк или агент скомпрометирован, атакующий сможет потратить не больше настроенного потолка до следующего сброса.

Сессии x402:
Токены сессий — это утверждения, подписанные с помощью ECDSA. Любой x402 V2-сервер может независимо проверить их — центральное хранилище сессий не требуется.

Минимальный след зависимостей:
У AgentPay MCP нулевая зависимость от LiteLLM. Весь сервер работает на viem (клиент Ethereum), @modelcontextprotocol/sdk и небольшом наборе аудируемых пакетов — в дереве зависимостей нет тяжёлых слоёв маршрутизации LLM. Это важно: 24 марта 2026 года версии LiteLLM 1.82.7 и 1.82.8 на PyPI были подтверждённо скомпрометированы в результате атаки на цепочку поставок, нацеленной на инфраструктуру ИИ-агентов. Любой MCP-сервер, который зависит от LiteLLM (напрямую или транзитивно), оказался под угрозой. AgentPay MCP — нет, потому что платёжная инфраструктура должна иметь максимально малую поверхность атаки.

agentpay-mcp уже поддерживает несколько платёжных рельсов

Ландшафт агентских платежей только что раскололся: x402 от Coinbase (открытый, не требующий разрешений, on-chain) против MPP от Stripe (требующий разрешений, на базе Tempo, USDC). Разработчики продакшен-агентов стоят перед выбором — или используют agentpay-mcp, который уже работает поверх обеих.

agentpay-mcp изначально не зависит от протокола:

Почему это важно: Ни x402, ни MPP не включают управление расходами. Кошельки x402 по умолчанию не ограничены. MPP предлагает лимиты, устанавливаемые человеком в дашборде, но не обеспечивает программного соблюдения лимитов на сессию или задачу. agentpay-mcp предоставляет бюджетный предохранитель, процессы утверждения и аудиторский след поверх обеих систем — независимо от того, какой рельс проводит расчёт по транзакции.

Это не обёртка над одним протоколом. Это слой управления с намеренным разделением между политикой (кто это одобрил, каков бюджет, должен ли человек это проверить) и расчётами (какой блокчейн или платёжная сеть перемещает деньги). Именно это разделение делает agentpay-mcp нейтральным к рельсам — и именно оно позиционирует его как стандарт управления, пока разворачивается война протоколов.

Работает с AWS AgentCore

AWS AgentCore предоставляет корпоративный хостинг агентов с применением политик на основе Cedar для контроля доступа. Политики Cedar отвечают на вопросы: «Разрешено ли этому агенту вызывать этот API?» и «Может ли этот агент получить доступ к этому ресурсу?»

Чего Cedar НЕ предоставляет: лимитов расходов. В Cedar нет примитива для «этот агент может потратить не более $50 за сессию» или «остановите агента, если совокупный расход за сегодня превысит $200». Контроль доступа и управление бюджетом — разные задачи.

agentpay-mcp добавляет бюджетный предохранитель поверх AgentCore:

Паттерн развёртывания: AgentCore запускает агента с политиками Cedar, управляющими доступом к инструментам. agentpay-mcp работает как MCP-сервер в наборе инструментов агента, обеспечивая соблюдение лимитов расходов для каждого платёжного действия. Cedar говорит: «ты можешь вызывать этот платный API». agentpay-mcp говорит: «ты можешь потратить до $5 на этот вызов».

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x...",
        "MAX_TRANSACTION_USDC": "5.00",
        "DAILY_LIMIT_USDC": "50.00"
      }
    }
  }
}

Для предприятий, запускающих агентов на AgentCore: Cedar отвечает на вопрос «можно ли?». agentpay-mcp отвечает на вопрос «стоит ли тратить столько?». Вместе они обеспечивают стек управления доступом и бюджетом, который требуется продакшен-развёртываниям агентов.

Конкурентное позиционирование

Проще всего думать об этом так: ACP (Stripe) отвечает за то, что агенты ПРОДАЮТ, а agentpay-mcp — за то, что агенты ПОКУПАЮТ.

Stripe MCP против agentpay-mcp

Разработчики часто спрашивают: «Разве Stripe MCP уже не обрабатывает платежи агентов?» Ответ: они решают разные задачи на разных уровнях.

Stripe MCP — это инструмент продавца: он помогает бизнесу взимать оплату с клиентов через агентские интерфейсы. Думайте: «купить этот товар» или «оформить подписку на этот план».

agentpay-mcp — это инструмент закупок для агента: он позволяет агентам оплачивать API и инструменты, которые нужны им для работы. Думайте: «получить доступ к этому премиальному эндпоинту данных» или «использовать этот вычислительный ресурс».

Большинству production-агентов потребуются оба уровня: Stripe MCP — для пользовательской коммерции, agentpay-mcp — для собственных расходов агента на инструменты. Они дополняют друг друга, а не конкурируют.

MCP 2026 Compliance

AgentPay MCP соответствует новым стандартам безопасности MCP на 2026 год, включая категории угроз CoSAI (Coalition for Secure AI) и требования OAuth 2.1.

Документация security posture: полную матрицу соответствия см. в docs/security-posture.md. Она охватывает:

• CoSAI T9 (Financial Fraud) — многоуровневые лимиты расходов: политика расходов внутри процесса (set_spend_policy, применяется в процессе MCP-сервера — не on-chain) плюс on-chain лимиты AgentAccountV2 и очередь одобрений, настроенные владельцем кошелька

• CoSAI T10 (Identity Spoofing) — проверка идентичности агента через ERC-8004 + некастодиальное управление ключами предотвращают атаки, связанные с подменой личности

• OAuth 2.1 + PKCE — аутентификация MCP-сервера поддерживает OAuth 2.1 с PKCE для корпоративной интеграции SSO (Azure AD, Okta)

• Аудит-лог — история событий AgentAccountV2 on-chain via методы get_transaction_history (исполнения, запланированные транзакции, одобрения, обновления политик); отдельный лог не ведется we do not "per-tool-invocation log" — см. точный состав записываемого. В документе security posture указано, что записывается, а что нет

Для корпоративных команд безопасности, оценивающих MCP-серверы: документ security posture содержит артефакт, необходимый вашему процессу аудита.

Архитектура

┌─────────────────────────────────────────┐
│  AI Agent (Claude / Cursor / Windsurf)  │
└────────────────┬────────────────────────┘
                 │  MCP (stdio / SSE)
┌────────────────▼────────────────────────┐
│           AgentPay MCP Server           │
│  ┌────────────┐  ┌────────────────────┐ │
│  │  23 Tools  │  │  Session Manager   │ │
│  └─────┬──────┘  └────────────────────┘ │
│        │                                │
│  ┌─────▼──────────────────────────────┐ │
│  │       agentwallet-sdk v6.0.0       │ │
│  │  TokenRegistry  SwapModule         │ │
│  │  BridgeModule   ERC8004Client      │ │
│  └─────┬──────────────────────────────┘ │
└────────┼────────────────────────────────┘
         │  viem + RPC
┌────────▼────────────────────────────────┐
│  AgentAccountV2 Smart Contract          │
│  SpendingPolicy  ·  Tx Queue            │
│  (12 chains — Base, ETH, ARB, OP, ...)  │
└─────────────────────────────────────────┘

Транспорт: по умолчанию stdio (Claude Desktop, Cursor, Windsurf). Для удаленных развертываний доступен SSE.

Contributing

git clone https://github.com/up2itnow0822/agentpay-mcp
cd agentpay-mcp
npm install
npm run build
npm test

Уведомление о патенте

Patent Pending — предварительная заявка в USPTO, поданная в марте 2026 года: «Non-Custodial Multi-Chain Financial Infrastructure System for Autonomous AI Agents».

Мы поддерживаем открытый стандарт x402. Наша заявка имеет носители оборонительный характер — чтобы предотвратить вражду на монополизацию открытых платежных рельсов, а не ограничить разработчиков, использующих открытые стандарты.

Интероперабельность с Vercel x402-mcp

agentpay-mcp полностью совместим с пакетом Vercel x402-mcp. Если вы используете paidTool() от Vercel для монетизации MCP-инструментов, agentpay-mcp работает как платежный слой на стороне клиента — ваш агент автоматически оплачивает счета x402 от paidTool() через x402_pay.

Что agentpay-mcp добавляет поверх x402-mcp:

• Multi-rail payments — маршрутизация через x402 (USDC on-chain) или Stripe Machine Payments Protocol (фиат) в зависимости от продавца

• Spend governance (управление расходами) — лимиты на транзакцию, суточные лимиты и очереди одобрения человеком, которые эндпоинты paidTool() не применяют на стороне клиента

• Multi-chain: x402 v2 — оплата в Base, Solana или Polygon (x402 v2 поддерживает все сети нативно)

Используйте Vercel x402-mcp на стороне сервера для монетизации своих инструментов. Используйте agentpay-mcp на стороне клиента для безопасной оплаты инструментов.

Circle 2024 — Zero-Gas Settlement

agentpay-mcp поддерживает Circle Nanopayments как вариант расчетов для платежей x402 v2. Nanopayments обеспечивают бесплатные для газа переводы USDC суб-центра, объединяя мелкие платежи в одну on-chain транзакцию.

Как это работает с agentpay-mcp:

• Агент совершает платеж по x402 через x402_pay как обычно

• Если сервер x402 v2 поддерживает Circle Nanopayments, расчет происходит без расхода газа

• Платежи меньше цента ($0.001, $0.0001) становятся экономически целесообразными для цены за вызов API *Кросс-чейн поддержка через шлюз Circle — работает в любой EVM-сети

Это полезно для высокочастотных агентских сценариев, где затраты на газ в противном случае превысили бы сумму платежа. Подробности протокола — в объявлении Чирка.

Экосистема x402 — 75M+ транзакций, нативная поддержка Cloudflare

agentpay-mcp построен на стандарте API-платежей [x402](https:// x402.org), который к настоящему моменту обработал более 75 млн транзакций в основной сети Base — в основном через Coinbase Agentic Wallets и интеграции разработчиков.

Cloudflare добавила нативную поддержку x402 в свой Agents SDK и среду вызова MCP-серверов, что означает: любой агент на Cloudflare Workers теперь может выполнять платежи x402 напрямую. Google, Circle и Stripe активно интегрируют x402 в свои агентские экосистемы.

agentpay-mcp — это свободный (open-source) слой управления поверх этой инфраструктуры: в то время как x402 отвечает за протокол платежей, agentpay-mcp добавляет provide доверие, которое требуется production-агентам: HITL-одобрение (включение человека в цикл), лимиты расходов, списки разрешения получателей (allowlist) и on-chain жур гарантии аудита.

Совместимость со спецификацией OpenAI Delegated Payments

OpenAI представила Delegated Payment Spec (спецификацию делегации платежей агентов), которая определяет, что агенты оплачивают / отдох on behalf of пользователей: ограниченный токен с предельным размером allowance, совместимый со Stripe Scoped Payment Tokens (SPTs). Это прототипная архитектура, предшествующая встроенному платежному инструментарию в Agents SDK.

Модель лимитов расходов agentpay-mcp напрямую согласована с паттернами Delegated Payment Spec:

Ключевой принцип идентичен: человек одобряет бюджет → агент выполняет действия в рамках бюджета → вся активность подлежит аудиту. Разница — в слое расчетов: спецификация OpenAI нацелена на Stripe SPT (фиатные сети), а agentpay-mcp осуществляет расчеты on-chain (USDC/ETH в Base, Arbitrum и 8 других EVM-сетей).

Для разработчиков, создающих workflows OpenAI Agents SDK, которые нуждаются в on-chain или multi-rail выполнении платежей, agentpay-mcp служит MCP-инструментом для оплат, реализующим паттерн Delegated Payment Spec с правом прикинем смарт-контрактов, а не доверием на уровне приложения.

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x..."
      }
    }
  }
}

Добавьте этот MCP-сервер в любой воркфлоу OpenAI Agents SDK через MCP-мост, и агент получит функции x402_pay, check_budget и set_spend_policy — тот же паттерн «scoped token + allowance cap». Обратите внимание: set_spend_policy приводит к процессу MCP-сервера; смарт-контрактное исполнение осуществляется on-chain лимитами AgentAccountV2, которые настраивает владелец кошелька (см. docs/security-posture.md).

Совместимость с Google AP2

agentpay-mcp дополняет протоколен Agent2Agent Payment (AP2) от Google. AP2 — поддержанный более чем 60 организациями, включая Visa, Mastercard и PayPal, — отвечает за авторизацию платежей агентов: проверку, что расчетный запрос правомерен. agentpay-mcp работает на уровне управления поверх AP2, добавляя лимиты бюджета на каждого агента, суточные рабочие лимиты и пороги одобрения человеком, которые AP2 намерено выносит за пределы. Для предприятий, размещающих агентов на нескольких платежных платах, agentpay-mcp обеспечивает единое управление расходами, которое не обеспечивает ни один отдельный протокол.

Соответствие EU AI Act

Крайний срок: 2 августа 2026 г. AI-системы, которые выполняют или позволяют финансовых операции, классифицируются как высокорисковые в соответствии с Приложением III EU AI Act. Высокорисковая классификация требует:

• ✅ Контроль — человеческое рассмотрение и возможность отмены (override)

• ✅ Прозрачность и объяснимость — проверяемые записи о транзакциях

• ✅ Контроль доступа — затратные лимиты, которые агент не может обойти

• ✅ Техническая документация — поддержка оценки соответствия

agentpay-mcp удовлетворяет все четыре требования «из коробки»:

| Требование | Функция в agentpay-mcp | | | — | | Human oversight (контроль человеком) | queue_approval — транзакции выше порога требуют явного одобрения человека | | Audit trail (аудит) | get_transaction_history — полный on-chain лог событий, неизменяем и проверяемый (basescan.org) | | Spend controls расходов | On-chain лимиты AgentAccountV2: на транзакцию и период — настройка владельца контракта, не обходится агентом; плюс set_spend_policy в качестве guardrail | | Scope restriction | set_spend_policy — разрешенные получатели enforced в процессе MCP-сервера, а не in-chain; границы контроля см. в docs/security-posture.md |

Европейские предприятия, развертывающие агентские системы, работающие с платежами, имеют ~150 days на внедрение процессов надзора и аудита. agentpay-mcp — самый быстрый путь к соответствию EU AI Act для MCP–совместимых развертываний.

Штрафы за несоблюдение: до €35 млн или 7% мировой годовой выручки. Германия опубликовала свой национальный законопроект о правоприменении в феврале 2026 года.

Лицензия

MIT © AI Agent Economy

Создано AI Agent Economy — инфраструктура для производственных агентских рабочих процессов.