Wallet policy engine для AI-агентов: как дать боту доступ к деньгам и не отдать ему полный контроль

AI-агент без права тратить деньги — это обычно просто умный помощник.

AI-агент, которому дали приватный ключ, API key от биржи или прямой доступ к withdrawal endpoint, — уже потенциальный источник очень дорогой ошибки.

Именно в этом месте многие команды делают опасный скачок между demo и production:

  • сначала агент только собирает данные
  • потом ему дают право создать заявку
  • затем разрешают инициировать swap, transfer или withdrawal
  • а дальше оказывается, что вся «безопасность» сводится к фразе «ну агент же должен понимать, что так делать нельзя»

Это плохая ставка.

Свежие обсуждения на Hacker News вокруг agent wallets, policy-governed execution и автономных платёжных сценариев хорошо подсвечивают главный сдвиг рынка: вопрос уже не в том, могут ли агенты инициировать денежные действия, а в том, какой control layer должен стоять между решением агента и реальным движением средств.

Для technical founders, операторов crypto-продуктов и команд, строящих DeFi или exchange automation, правильный ответ обычно один: не давать агенту «кошелёк», а давать ему policy-constrained execution surface.

Ниже — практический разбор, как устроить такой слой.

Почему обычный подход «дать агенту ключ» ломается

На раннем этапе всё выглядит соблазнительно просто:

  • есть hot wallet
  • есть bot wallet
  • есть API key от биржи
  • есть агент, который понимает задачу
  • значит можно дать ему доступ и ограничить prompt’ом

Проблема в том, что для денег prompt не является контролем.

Если система дошла до реального действия, риск возникает не только из-за «плохого» агента. Ошибка может прийти и из гораздо более скучных источников:

  • stale context
  • неверная классификация актива или сети
  • неправильный parsing суммы
  • route change на стороне провайдера
  • повторный запуск одного и того же workflow
  • prompt injection через внешние данные
  • галлюцинация в reasoning-слое
  • несовпадение между onchain и exchange state

Если у агента есть сырой ключ или прямое право на withdrawal, любая из этих проблем превращается не в баг уровня UX, а в риск движения денег.

Настоящая проблема — не «кошелёк агента», а граница authority

Полезнее мыслить не категорией agent wallet, а категорией authority boundary.

Команда должна явно ответить на вопрос:

Что именно агент может сделать сам, что он может только предложить, а что всегда требует policy check или человеческого approval?

На практике почти всегда есть четыре уровня полномочий.

1. Observe

Агент может:

  • читать балансы
  • смотреть статусы кошельков и бирж
  • собирать route health
  • анализировать pending operations
  • строить summary и находить аномалии

Это относительно безопасный уровень.

2. Propose

Агент может:

  • предложить swap
  • предложить rebalance
  • предложить вывод или sweep
  • рассчитать candidate route
  • сформировать intent и приложить evidence

Здесь уже появляется операционная ценность, но ещё нет прямого денежного действия.

3. Execute under policy

Агент может запускать только те действия, которые проходят формальные ограничения:

  • лимиты по сумме
  • allowlist адресов и сетей
  • разрешённые контрагенты
  • ограниченный scope токенов
  • session TTL
  • risk score threshold
  • обязательные pre-checks и post-checks

Это уже production-слой, но только если policy enforcement живёт вне модели.

4. Escalate for approval

Для high-risk действий агент не исполняет их сам, а:

  • создаёт intent
  • прикладывает контекст
  • показывает risk flags
  • предлагает next step
  • ждёт formal approval

Именно этот слой обычно спасает от самых дорогих ошибок.

Что такое wallet policy engine

Wallet policy engine — это слой между агентом и execution endpoint, который отвечает не на вопрос «что агент хочет сделать?», а на вопрос:

Разрешено ли это действие, в этом контексте, для этого агента, с этим активом, по этому маршруту, на эту сумму и в этот момент времени?

То есть вместо модели:

agent -> wallet key -> transfer

нужна модель:

agent -> intent -> policy engine -> execution gateway -> wallet/exchange

Это принципиально меняет профиль риска.

Какая сущность должна быть основной: intent, а не команда

Одна из самых полезных практик — не позволять агенту вызывать «сделай transfer» напрямую.

Вместо этого агент должен создавать intent.

Например:

{
  "intent_id": "aw_2026_04_12_001",
  "actor": "treasury_agent",
  "action": "withdraw_to_hot_wallet",
  "asset": "USDT",
  "network": "TRON",
  "amount": "15000",
  "source": "exchange_okx_main",
  "destination": "hot_wallet_tron_1",
  "reason": "hot_wallet_below_operational_floor",
  "risk_flags": ["money_movement", "exchange_withdrawal"],
  "expires_at": "2026-04-12T07:25:00Z"
}

С intent-моделью появляется то, чего почти никогда нет в ad-hoc agent automation:

  • объяснимость
  • дедупликация
  • audit trail
  • TTL
  • возможность approval
  • нормальная повторяемость и recovery

Какие policy rules реально нужны

Если говорить прикладно, для money workflows полезен не абстрактный policy layer, а вполне конкретные проверки.

1. Asset and route scope

Агенту можно разрешить работать только с определёнными активами и маршрутами.

Например:

  • только USDT и USDC
  • только TRON и Ethereum
  • только внутренние treasury wallet и проверенные биржевые адреса
  • запрет на новые destination без ручного approval

Это снимает целый класс случайных и катастрофических ошибок.

2. Spend limits

Нужны сразу несколько лимитов:

  • per action
  • per hour
  • per day
  • per asset
  • per destination
  • aggregate exposure across active intents

Ошибка многих реализаций — оставить только один лимит «не больше 1000 USDT». Этого почти никогда недостаточно.

3. Session-bound authority

Хорошая практика — не давать агенту постоянный долгоживущий доступ.

Лучше использовать session-limited authority:

  • токен или ключ живёт ограниченное время
  • scope привязан к одной задаче
  • разрешён конкретный тип действия
  • после TTL права автоматически истекают

Это особенно полезно для operator-assisted workflow и временных agent jobs.

4. Destination allowlists

Для денежных операций allowlist почти обязательна.

Полезно разделять:

  • internal wallets
  • cold wallets
  • exchange deposit addresses
  • whitelisted counterparties
  • временно разрешённые destinations

Агент не должен сам «решать», что новый адрес выглядит правдоподобно.

5. Risk-aware approval thresholds

Не все действия одинаково опасны.

Обычно полезно вводить пороги вроде:

  • low risk → auto-approve
  • medium risk → one operator approval
  • high risk → dual approval
  • abnormal pattern → quarantine

Такой подход масштабируется намного лучше, чем бинарное allow/deny.

Session keys и delegated credentials лучше, чем master keys

Самая плохая идея — хранить у агента master key или основной exchange API key с полным объёмом прав.

Гораздо лучше, когда execution устроен через один из ограниченных механизмов:

  • session keys
  • delegated credentials
  • scoped API tokens
  • smart-account policies
  • pre-authorized intents через control service

Общая идея простая: агент должен получать минимально достаточное право, а не «почти root, но мы надеемся, что он аккуратный».

Onchain и exchange workflows требуют разных guardrails

Команды часто смешивают их в одну модель, но это ошибка.

Для onchain действий особенно важны:

  • allowlist контрактов и адресов
  • ограничения по функциям контракта
  • max amount / max gas policy
  • chain-specific checks
  • simulation до отправки
  • post-broadcast observation

Для exchange workflows особенно важны:

  • whitelist destination
  • network availability checks
  • withdrawal maintenance / review state
  • свежесть баланса
  • idempotency keys
  • ambiguity handling после timeout или partial response

В обоих случаях агент не должен считать, что успешный API call равен безопасно завершённой денежной операции.

Отдельно про DeFi: агенту нельзя доверять только потому, что он умеет “reason”

В DeFi риск часто ещё выше, потому что действие может быть формально валидным, но экономически плохим.

Например, агент может:

  • выбрать маршрут со скрытым price impact
  • не заметить toxic liquidity
  • проигнорировать allowance risk
  • войти в слишком тонкий пул
  • не учесть bridge latency или finality risk
  • ошибочно принять spoofed token за нужный актив

Поэтому для DeFi automation policy engine должен проверять не только разрешено ли действие технически, но и попадает ли оно в допустимый economic risk envelope.

То есть guardrails нужны сразу на трёх уровнях:

  • техническом
  • денежном
  • экономическом

Очень полезный паттерн: dry-run, simulate, then execute

Надёжный money workflow редко должен выглядеть как «агент решил → система отправила».

Гораздо лучше staged flow:

  1. агент создаёт intent
  2. policy engine проверяет scope и лимиты
  3. planner/simulator считает маршрут
  4. система строит expected outcome
  5. при необходимости запрашивается approval
  6. execution gateway запускает действие
  7. observer подтверждает факт и результат
  8. reconciliation сверяет итог с internal state

Этот паттерн кажется более медленным, но для production automation обычно именно он и даёт реальную скорость — потому что потом меньше recovery, panic и ручных разборов.

Где AI-агент реально полезен

Чтобы не превратить статью в очередной манифест «агентам ничего нельзя», важно разделять execution authority и operational value.

Агент действительно полезен там, где человеку дорого переключать контекст:

  • собрать доказательства для перевода средств
  • выбрать candidate route
  • объяснить, почему нужен sweep или rebalance
  • подсветить рискованные признаки
  • проверить полноту данных перед approval
  • сгенерировать human-readable summary для оператора

Это уже сильно ускоряет treasury и wallet operations.

Но полезность агента не означает, что ему нужен сырой доступ к деньгам.

Практический блок

1) Какая проблема возникает у бизнеса или продукта

Когда продукт начинает автоматизировать onchain, exchange и wallet workflows, давление всегда идёт в две стороны одновременно:

  • бизнес хочет быстрее двигать деньги и меньше зависеть от операторов
  • risk surface растёт быстрее, чем команда успевает строить контроль

В результате типичный anti-pattern выглядит так:

  • агенту дали слишком широкие права
  • часть действий автоматизировали быстрее, чем построили policy layer
  • при первой неоднозначной ситуации никто уже не понимает, почему система решила именно так

Это приводит либо к опасной автоматизации, либо к откату обратно в ручной режим.

2) Какое решение или архитектурный паттерн имеет смысл внедрить

Практически рабочий паттерн такой:

  • ввести intent-based execution вместо прямых команд агента
  • поставить wallet policy engine между агентом и execution gateway
  • использовать session-bound credentials вместо постоянных ключей
  • держать spend limits, allowlists, route constraints и approval thresholds вне модели
  • разделить propose / approve / execute / observe / reconcile
  • все ambiguous outcomes отправлять в quarantine или operator review

То есть агент становится частью control plane, а не самостоятельным владельцем денег.

3) Что именно можно предоставить как service / implementation layer

Здесь есть очень прикладной implementation scope:

  • wallet policy engine для onchain и exchange actions
  • intent gateway для treasury, withdrawals, sweeps и rebalance workflows
  • approval workflow для high-risk операций
  • operator console с evidence, risk flags и audit trail
  • monitoring и reconciliation слой для пост-фактум подтверждения
  • безопасная agent integration без выдачи full-access wallet или master API key

Для потенциального клиента это ценность не в «AI for crypto» как лозунге, а в том, что можно автоматизировать денежные операции быстрее, но без скрытой сдачи контроля модели.

На что смотреть в метриках

Если такой слой уже внедрён, полезно мерить:

  • сколько agent intents auto-approved vs escalated
  • долю policy denials по причинам
  • количество quarantined operations
  • median time from intent to safe execution
  • долю ambiguous outcomes
  • сколько risky actions было предотвращено allowlist/limit rules
  • сколько действий агент предложил корректно, но без прямого execution authority

Эти метрики лучше показывают зрелость системы, чем абстрактное «мы подключили AI-агента к кошельку».

Вывод

Если AI-агент начинает участвовать в wallet, treasury, exchange или DeFi workflows, главный инженерный вопрос звучит не так:

Как дать агенту кошелёк?

А так:

Как построить policy-constrained execution layer, где агент приносит пользу, но не получает неограниченную власть над деньгами?

Обычно правильный ответ включает:

  • intent-based architecture
  • wallet policy engine
  • spend limits и allowlists
  • session-bound credentials
  • staged approvals
  • observation и reconciliation после исполнения

Именно этот подход позволяет строить agent automation вокруг денег без наивной веры в то, что хороший reasoning сам по себе заменяет risk controls.