GitHub: blocksecteam/web3-companion
Docker: blocksecteam/web3-companion
Позволить ИИ выполнять ончейн-транзакции от имени пользователей — самый горячий тренд в криптоиндустрии прямо сейчас. Coinbase запустила Agentic Wallets в феврале 2026 года, а по оценкам McKinsey, объём коммерции через AI Agent к 2030 году может достичь 3–5 триллионов долларов в мировом масштабе. Как выразился CEO Coinbase Брайан Армстронг: AI Agent не могут открывать банковские счета, но могут владеть криптокошельком.
Проблема в том, что позволить ИИ управлять ончейн-активами — это совершенно не то же самое, что доверить ему управление календарём или электронной почтой. Ончейн-транзакции необратимы. Никаких возвратов, никаких чарджбэков. Одна вредоносная подпись способна опустошить весь кошелёк за один блок. Без безопасности ни одна функция не имеет значения.
BlockSec выпустила Web3 Companion с открытым исходным кодом — Agentic Wallet с безопасностью на первом месте. Эта статья разбирает архитектуру безопасности за ним: почему текущие архитектуры Agentic Wallet фундаментально ущербны и как мы встроили безопасность в архитектуру кошелька с самого основания.
Насколько опасны существующие Agent: Инцидент с OpenClaw
Что происходит, когда у AI Agent нет границ безопасности? OpenClaw в начале 2026 года отвечает на этот вопрос.
OpenClaw — это AI Agent общего назначения с открытым исходным кодом, набравший 100 000 звёзд на GitHub за пять дней. Как Agent общего назначения он работал хорошо, но как только дело коснулось Web3-транзакций, все бреши в безопасности проявились мгновенно.
Приватные ключи хранились в открытом виде в локальных файлах, доступных Agent. Одного письма с prompt injection было достаточно, чтобы их похитить.
Подписание не имело никакой изоляции. Один и тот же процесс, который загружал ненадёжные веб-страницы, мог также подписывать транзакции, поэтому одна уязвимость RCE позволяла злоумышленнику получить полный контроль как над Agent, так и над его ключами через вредоносную веб-страницу.
Маркетплейс Skills был ещё одним слабым местом. Исследователи обнаружили, что 7,1% ClawHub Skills допускали утечку учётных данных, а некоторые были прямо спроектированы для опустошения криптокошельков.
Генерация случайных чисел тоже была нарушена. OpenClaw использовал math/rand — ГПСЧ с начальным значением от системных часов — на критически важных для безопасности путях. Исследователи показали, что двух последовательных значений токенов достаточно для восстановления внутреннего состояния и предсказания всех будущих токенов и challenge-значений. В некоторых путях кода это распространялось вплоть до восстановления ключей кошелька.
Хуже всего — не было уровня политик. Между prompt injection и переводом средств не стояло ничего. Ноль перехватов.
Вывод: архитектуры AI Agent общего назначения небезопасны для Web3-транзакций.
Фундаментальный изъян текущих архитектур AI Agent
Проблема выходит за рамки OpenClaw. Смена модели или написание более строгих промптов не решает проблему. Текущие архитектуры AI Agent несут в себе неустранимый изъян безопасности: сам LLM является постоянно открытой поверхностью атаки.
Корневая причина: LLM не умеют отличать инструкции от данных. Системные промпты, сообщения пользователей, содержимое веб-страниц, даже название токена — всё поступает как один и тот же поток токенов. У модели нет надёжного механизма, чтобы отделить «выполни это» от «просто прочитай это». Из этого следуют три последствия.
Во-первых, prompt injection неразрешим на уровне модели. Злоумышленники могут спрятать инструкции в любом контенте, который потребляет Agent: в письмах, комментариях к контрактам, на веб-страницах, в названиях токенов. Если Agent может подписывать транзакции, одна успешная инъекция превращает шутку в кражу.
Во-вторых, собственная проверка безопасности Agent на основе Skills может быть подорвана. LLM, оценивающий безопасность транзакции, полностью зависит от контекста. Отравите контекст — и вердикт перевернётся. Вредоносные подписи пройдут проверку.
В-третьих, Agent работают круглосуточно, непрерывно потребляя ненадёжные входные данные и будучи способными автономно выполнять транзакции. Окно атаки никогда не закрывается, и одна брешь может означать немедленную потерю средств.
Сообщество безопасности в целом согласно: предоставление LLM прямого доступа к приватным ключам — в мире, где prompt injection не имеет лекарства — равносильно хранению пользовательских активов внутри компонента, который может быть скомпрометирован в любой момент. Раз уровень модели нельзя укрепить, риск необходимо сдерживать на уровне архитектуры. Даже полностью скомпрометированная модель не должна иметь возможности переместить средства пользователей.
Архитектура безопасности Web3 Companion построена именно на этой идее.
Модель угроз: Agent не является доверенным
Модель угроз Web3 Companion умещается в одну фразу: сам Agent не является доверенным. Вся архитектура исходит из предположения, что Agent может быть скомпрометирован в любой момент.
Мы не полагаемся на то, чтобы сделать Agent достаточно устойчивым для обнаружения каждой атаки. Защита на уровне модели не работает, как было показано выше. Научите его сегодня ловить инъекции азбукой Морзе — завтра атакующие переключатся на Base64, стеганографический текст в изображениях или безобидный на вид PDF. Вместо этого мы перевернули предположение. Agent находится внутри модели угроз, а остальная часть системы спроектирована так, чтобы его сдерживать. Даже если злоумышленник полностью контролирует Agent, активы пользователей остаются в безопасности. Позиционирование в одну строку: The Secure Agentic Wallet — кошелёк, который по умолчанию считает собственный Agent ненадёжным и сохраняет безопасность в любых обстоятельствах.
Из этой модели угроз мы вывели пять принципов проектирования.
Принцип 1: Agent никогда не должен касаться приватных ключей. Приватные ключи — единственный реквизит, управляющий ончейн-активами. Если Agent может их прочитать, компрометация означает потерю ключей. Ключи должны храниться там, куда Agent архитектурно не может добраться.
Принцип 2: Подготовка — это не авторизация. Формирование транзакции и её утверждение — два отдельных действия. Agent может помочь пользователям понять ончейн-состояние и собрать намерения, но решение о подписании принадлежит независимому бэкенд-модулю, к которому Agent не имеет доступа.
Принцип 3: Проверка — это обнаружение, а не принудительное исполнение. Симуляция транзакций, анализ calldata и маркировка адресов улавливают типичные шаблоны атак и помогают пользователям понять риски, но они не являются окончательным вердиктом. Симуляции могут давать сбои, метки могут отсутствовать, а собственный анализ LLM сам по себе уязвим для prompt injection.
Принцип 4: Жёсткие политики — последний рубеж. Допустим, Agent обманут на инициацию перевода в 100 000 долларов, а проверка безопасности манипулирована в его пользу. Установленный кодом дневной лимит в 1 000 долларов всё равно заблокирует операцию. У Agent нет разрешения на изменение этих лимитов.
Принцип 5: Нет доказательств — нет исполнения. Неудавшееся сканирование — это не одобрение. Отсутствие данных — это не «безопасно». Когда свидетельства безопасности отсутствуют, противоречивы, устарели или недостаточны, система останавливается и ожидает явного подтверждения от пользователя.
Эти пять принципов реализуются через два модуля безопасности: безопасность приватных ключей и безопасность транзакций.
Изоляция приватных ключей: Архитектурно недосягаемы для Agent
Первая задача проста. Мы хотим помощника, который готовит ончейн-транзакции, но наделение его возможностью подписания передаёт ему власть распоряжаться реальными деньгами. Практически каждый взлом Web3 Agent в 2025 и 2026 годах следовал одному и тому же сценарию: приватные ключи находились внутри процесса Agent, и атакующие находили способ их извлечь.
Поэтому мы переформулировали вопрос: что если Agent буквально не может подписывать? Не «ему сказано не делать этого», а архитектурно не способен. Программные средства контроля доступа всегда можно обойти. Нам нужно было что-то более надёжное.
Web3 Companion обеспечивает изоляцию на уровне процессов. Приватных ключей касается только один компонент: Secure Signature Module (SSM) — отдельный Go-процесс. Память процесса Agent, переменные окружения и файловая система не содержат никакого ключевого материала. Всё, что видит Agent — это идентификатор намерения транзакции. Он может попросить SSM подписать это намерение, но никогда не может увидеть стоящий за ним ключ.
Для хранения ключей мы оценили три варианта. Открытый текст на диске: одно чтение диска раскрывает ключ. Отклонено. Шифрование на основе пароля: требует повторного ввода при каждом перезапуске — непрактично для долго работающего Docker-сервиса. Отклонено. Мы выбрали конвертное шифрование: каждый ключ кошелька шифруется собственным ключом данных, а этот ключ данных оборачивается мастер-ключом (AWS KMS или локальный AES-256). Даже если зашифрованные файлы будут полностью похищены, без мастер-ключа они бесполезны. Ключи существуют в открытом виде лишь мгновение — в памяти SSM — и обнуляются сразу после подписания.
Каждый запрос на подпись проходит один и тот же путь. Без ускоренной полосы, без обходного пути. Транзакция последовательно проходит через семь шагов: проверка делегирования, симуляция, проверка безопасности, проверка безопасности Agent, оценка политик, одобрение Passkey и, наконец, подписание SSM. Завершение одного шага никогда не пропускает следующий.
Стоит упомянуть одну низкоуровневую деталь: каждый случайный байт в системе (генерация приватных ключей, nonce для AES-GCM, токены аутентификации, challenge WebAuthn) поступает из crypto/rand — криптографического источника случайности операционной системы. math/rand запрещён во всём коде, критичном для безопасности; это обеспечивается тестами и CI.
Безопасность транзакций: Четыре уровня эшелонированной защиты
Изоляция приватных ключей покрывает безопасность ключей, но риски на уровне транзакций сохраняются. Скомпрометированный Agent может собрать намерение транзакции, которое выглядит абсолютно легитимно, чтобы обмануть пользователей или обойти политики автоподписания. prompt injection не нуждается в приватном ключе — ему достаточно заставить систему подписать вредоносную транзакцию через штатный процесс.
Ключевой вопрос: когда Agent, готовящий транзакции, сам может быть скомпрометирован, как перехватить вредоносную транзакцию?
Ни один отдельный уровень защиты не выдерживает сам по себе. Только симуляция? Симуляции дают сбои, RPC падают, новые атаки не вписываются в известные паттерны. Только проверка на основе LLM? Та же инъекция, что скомпрометировала Agent, скомпрометирует и проверяющего — оба работают на LLM. Только жёсткий лимит? Легитимные пользователи упираются в стену; потолок в 100 долларов на каждый swap непригоден для использования.
Мы комбинируем все четыре уровня. Каждый уровень предполагает, что все предыдущие уже пали.
Уровень 1: Симуляция транзакций. Перед подписанием система симулирует исполнение: декодирование calldata, предсказание revert, проверка формата полей. Симуляция ловит очевидные проблемы, но имеет слепые зоны. Новые техники атак и сбои RPC могут её обойти.
Уровень 2: Оценка контрагента. Набор статических проверок нацелен на контрагента: сопоставление получателя и суммы, обнаружение неограниченных одобрений, обнаружение адресов сжигания, неожиданные delegate-вызовы. Оценка риска адресов выполняется через сервис комплаенса x402 от BlockSec, где Agent запрашивает метки и оценки риска через микроплатежи x402 без необходимости в API-ключе или подписке. Уровни 1 и 2 вместе ловят большинство распространённых проблем, но оба могут быть обойдены. Их роль намеренно ограничена обнаружением и объяснением, а не финальными решениями.
Уровень 3: Жёсткое применение политик. Чистое кодовое принуждение на Go. LLM не участвует, Agent не может модифицировать правила. Лимиты на транзакцию, дневные бюджеты, белые списки получателей, пороги автоподписания: перевод на 5 000 долларов при лимите в 100 долларов на транзакцию отклоняется на месте. Изменение самой политики требует Passkey. Почему? Если бы Agent мог редактировать политики, одна инъекция сначала подняла бы лимит, а затем опустошила кошелёк. Автоподписание по умолчанию отключено; каждая транзакция требует ручного подтверждения, пока пользователь явно не решит включить его.
Это означает, что даже если все уровни обнаружения обойдены и полностью скомпрометированный Agent подписывает вредоносную транзакцию, фактический ущерб ограничен политикой. Если пользователь установил дневной порог автоподписания в 500 долларов, максимальный ущерб — 500 долларов, а не весь кошелёк. Уровень политик превращает компрометацию из катастрофического события в ограниченный убыток.
Уровень 4: Подтверждение пользователя (Passkey). Когда политика требует ручного подтверждения, система запрашивает верификацию WebAuthn (отпечаток пальца или лицо). Никакой чисто программный эксплойт не может это подделать.
Четыре уровня работают на основе взаимного недоверия. Каждый предполагает, что всё предыдущее уже скомпрометировано. Идеальная симуляция не ослабляет политику. Неверно настроенная политика не пропускает Passkey. Каждый уровень стоит сам по себе.
Деталь, которую легко упустить: повторное использование вердиктов. Известная техника DeFi-атак воспроизводит старый вердикт безопасности для модифицированной транзакции. Web3 Companion привязывает каждую операцию записи к уникальному намерению транзакции с аудируемыми переходами состояний. Вердикт безопасности применяется только к тому конкретному намерению, которое он проверял. Если Agent перестраивает транзакцию — даже просто изменив сумму или получателя — система рассматривает её как совершенно новое намерение и повторно проводит все проверки.
Четыре уровня защиты отображаются на три независимые границы доверия: Private Key, Policy и Passkey. Прорыв любой отдельной границы оставляет две другие на месте:
| Прорванная граница | Оставшаяся защита |
|---|---|
| Agent (prompt injection, RCE) | Нет ключей = нет подписания; политика блокирует превышение лимитов; Passkey блокирует неодобренные операции |
| Проверка безопасности (вердикт отравлен) | Политика по-прежнему обеспечивает соблюдение лимитов; операции, требующие ручного одобрения, по-прежнему требуют Passkey |
| Политика (ошибка конфигурации пользователя) | Операции, требующие ручного одобрения, по-прежнему требуют биометрической верификации |
| Всё, кроме Passkey | Учётные данные привязаны к оборудованию; атакующему нужно физическое присутствие пользователя |
Безопасность по проекту: Философия открытого кода
BlockSec работает над ончейн-безопасностью с первого дня. Мы защитили миллиарды долларов ончейн-активов и видели, как один и тот же урок повторяется: безопасность, которая не заложена в архитектуру с самого начала, всегда приходит слишком поздно.
AI Agent становятся новой точкой входа для ончейн-транзакций. Пространство развивается стремительно, но стандарты безопасности практически отсутствуют. Большинство команд фокусируются на том, что их Agent может делать. Немногие серьёзно задавались вопросом: если этот Agent будет скомпрометирован, способна ли архитектура ограничить радиус поражения?
Web3 Companion — это результат усилий BlockSec по воплощению многолетнего опыта в области ончейн-безопасности в архитектуру Agentic Wallet. Код полностью открыт под лицензией MIT (в настоящее время помечен как исследовательский предварительный выпуск). Индустрии прямо сейчас нужен конкретный ориентир по проектированию безопасности. Как строить модели угроз, как изолировать ключи, до какой глубины доводить защиту транзакций — ни одна команда не должна изобретать всё это с нуля. Мы публикуем полный дизайн, чтобы сообщество могло строить на его основе.