Web3 Компаньон: Открытый Безопасный Агентный Кошелёк

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

Позволить ИИ выполнять on-chain транзакции от имени пользователей — самая горячая тенденция в криптоиндустрии прямо сейчас. Coinbase запустил Agentic Wallets в феврале 2026 года, а по оценкам McKinsey, торговля через посредничество ИИ-агентов может достичь $3–5 трлн в мировом масштабе к 2030 году. Как выразился генеральный директор Coinbase Брайан Армстронг: ИИ-агенты не могут открыть банковский счёт, но они могут владеть криптокошельком.

Проблема в том, что позволить ИИ управлять on-chain активами — это совсем не то же самое, что позволить ему управлять календарями или электронной почтой. On-chain транзакции необратимы. Никаких возвратов, никаких чарджбэков. Одна вредоносная подпись может опустошить весь кошелёк за один блок. Без безопасности никакие функции не имеют значения.

BlockSec открыл исходный код Web3 Companion — Agentic Wallet с приоритетом безопасности. В этой статье рассматривается лежащий в его основе дизайн безопасности: почему существующие архитектуры Agentic Wallet принципиально неисправны и как мы встроили безопасность в архитектуру кошелька с нуля.

Насколько опасны современные агенты: инцидент OpenClaw

Что происходит, когда у ИИ-агента нет границ безопасности? Случай OpenClaw в начале 2026 года даёт ответ на этот вопрос.

OpenClaw — это универсальный ИИ-агент с открытым исходным кодом, набравший 100 000 звёзд на GitHub за пять дней. Он хорошо работал как универсальный агент, но как только дело дошло до Web3-транзакций, проявились все бреши в безопасности.

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

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

Маркетплейс Skills был ещё одним слабым местом. Исследователи обнаружили, что 7,1% Skills в ClawHub утекали учётными данными, а некоторые были прямо предназначены для опустошения криптокошельков.

Генерация случайных чисел тоже была сломана. OpenClaw использовал math/rand — ГПСЧ с инициализацией от системных часов — на критических с точки зрения безопасности путях. Исследователи показали, что двух последовательных значений токена было достаточно для восстановления внутреннего состояния и предсказания всех будущих значений токенов и вызовов. В некоторых ветках кода это распространялось вплоть до восстановления ключей кошелька.

Хуже всего то, что не было никакого уровня политик. Между инъекцией промпта и переводом средств не стояло ничего. Никакого перехвата.

Вывод: архитектуры универсальных ИИ-агентов небезопасны для Web3-транзакций.

Фундаментальный изъян в современных архитектурах ИИ-агентов

Это выходит за рамки OpenClaw. Смена модели или написание более строгих промптов не решает проблему. Современные архитектуры ИИ-агентов несут в себе врождённый изъян безопасности: сам LLM является постоянно открытой поверхностью атаки.

Первопричина: LLM не может отличить инструкции от данных. Системные промпты, сообщения пользователей, содержимое веб-страниц и даже название токена — всё это поступает как один поток токенов. У модели нет надёжного механизма для разграничения «выполни это» и «просто прочитай это». Из этого следуют три последствия.

Во-первых, инъекция промптов неразрешима на уровне модели. Злоумышленники могут прятать инструкции в любом контенте, который потребляет агент: письмах, комментариях к контрактам, веб-страницах, названиях токенов. Если агент может подписывать транзакции, одна успешная инъекция превращает шалость в кражу.

Во-вторых, собственный механизм проверки безопасности агента на основе Skills может быть подорван. LLM, оценивающий безопасность транзакции, полностью опирается на контекст. Отравьте контекст — и вердикт перевернётся. Вредоносные подписи пройдут без препятствий.

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

Сообщество безопасности в целом сходится во мнении: предоставить LLM прямой доступ к приватным ключам в мире, где инъекция промптов неизлечима, — это всё равно что хранить активы пользователей в компоненте, который в любой момент может быть скомпрометирован. Поскольку уровень модели нельзя укрепить, риск должен сдерживаться на уровне архитектуры. Даже полностью скомпрометированная модель не должна иметь возможности перемещать средства пользователей.

Архитектура безопасности Web3 Companion построена именно на этой идее.

Модель угроз: агент не является доверенным

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

Мы не рассчитываем на то, что агент будет достаточно устойчивым, чтобы распознать каждую атаку. Защита на уровне модели не работает, как показано выше. Сегодня вы обучаете его перехватывать инъекции в коде Морзе; завтра злоумышленники переключатся на Base64, стеганографический текст в изображениях или безобидно выглядящий PDF. Вместо этого мы перевернули допущение. Агент находится внутри модели угроз, а остальная система спроектирована так, чтобы его сдерживать. Даже если злоумышленник полностью контролирует агента, активы пользователей остаются в безопасности. Позиционирование в одной строке: The Secure Agentic Wallet — кошелёк, который по умолчанию считает собственного агента ненадёжным и остаётся защищённым в любом случае.

Из этой модели угроз мы вывели пять принципов проектирования.

Принцип 1: агент никогда не должен касаться приватных ключей. Приватные ключи — единственная учётная запись, контролирующая on-chain активы. Если агент может их прочитать, компрометация означает утерю ключей. Ключи должны находиться там, куда агент архитектурно не может добраться.

Принцип 2: подготовка — это не авторизация. Формирование транзакции и её одобрение — два разных действия. Агент может помочь пользователям разобраться в on-chain состоянии и собрать намерения, но решение о подписании принадлежит независимому внутреннему модулю, к которому агент не имеет доступа.

Принцип 3: проверка — это обнаружение, а не принуждение. Симуляция транзакций, анализ calldata и маркировка адресов выявляют распространённые паттерны атак и помогают пользователям понять риски, но они не являются окончательным вердиктом. Симуляции могут давать сбои, метки могут отсутствовать, а собственный анализ LLM сам по себе уязвим для инъекции промптов.

Принцип 4: жёсткие политики — это последний рубеж. Предположим, агент был обманут и инициировал перевод на $100 000, а проверка безопасности была манипулирована для его одобрения. Установленный в коде дневной лимит в $1 000 всё равно его заблокирует. Агент не имеет права изменять эти лимиты.

Принцип 5: нет доказательств — нет выполнения. Неудачная проверка — это не пропуск. Отсутствующие данные — это не «безопасно». Когда доказательства безопасности отсутствуют, противоречивы, устарели или недостаточны, система останавливается и ждёт явного подтверждения от пользователя.

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

Изоляция приватных ключей: архитектурно недоступно для агента

Первая проблема проста. Нам нужен ассистент, который готовит on-chain транзакции, но предоставление ему права подписи передаёт возможность распоряжаться реальными деньгами. Почти каждый взлом Web3-агента в 2025 и 2026 годах следовал одному сценарию: приватные ключи находились внутри процесса агента, и злоумышленники находили способ их извлечь.

Поэтому мы переформулировали вопрос: а что, если агент буквально не может подписывать? Не «ему сказано не делать этого», а архитектурно не может. Программные средства управления доступом всегда можно обойти. Нам было нужно что-то более надёжное.

Web3 Companion обеспечивает изоляцию на уровне процессов. Только один компонент работает с приватными ключами: Secure Signature Module (SSM) — отдельный процесс на Go. Память процесса агента, переменные окружения и файловая система не содержат никакого ключевого материала. Всё, что когда-либо видит агент, — это идентификатор намерения транзакции. Он может попросить SSM подписать это намерение, но никогда не увидит стоящий за ним ключ.

Для хранения ключей мы оценили три варианта. Открытый текст на диске: чтение диска немедленно раскрывает ключ. Отклонено. Шифрование на основе пароля: требует повторного ввода при каждом перезапуске, что неудобно для длительно работающего Docker-сервиса. Отклонено. Мы выбрали конвертное шифрование: каждый ключ кошелька зашифрован собственным ключом данных, а этот ключ данных обёрнут мастер-ключом (AWS KMS или локальный AES-256). Даже если зашифрованные файлы будут полностью похищены, они бесполезны без мастер-ключа. Ключи существуют в открытом виде лишь мгновенно в памяти SSM и обнуляются сразу после подписания.

Каждый запрос на подписание проходит один и тот же путь. Без быстрых дорожек, без коротких путей. Транзакция проходит семь шагов по порядку: проверка делегирования, симуляция, проверка безопасности, проверка безопасности агентом, оценка политики, одобрение через Passkey и, наконец, подписание SSM. Завершение одного шага никогда не пропускает следующий.

Стоит упомянуть одну низкоуровневую деталь: каждый случайный байт в системе (генерация приватного ключа, нонсы AES-GCM, токены аутентификации, вызовы WebAuthn) берётся из crypto/rand — криптографически стойкого источника случайности ОС. math/rand запрещён во всём коде, критичном для безопасности, что обеспечивается тестами и CI.

Безопасность транзакций: четыре уровня эшелонированной защиты

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

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

Ни один отдельный уровень защиты не устоит сам по себе. Только симуляция? Симуляции дают сбои, RPC-узлы падают, новые атаки выходят за рамки известных паттернов. Только проверка на основе LLM? Та же инъекция, которая скомпрометировала агента, скомпрометирует и проверяющего, поскольку оба работают на LLM. Только жёсткий лимит? Легитимные пользователи упираются в стену; лимит в $100 на каждый обмен неприемлем.

Мы объединяем все четыре уровня. Каждый уровень исходит из того, что все предыдущие уже пробиты.

Уровень 1: симуляция транзакции. Перед подписанием система симулирует выполнение: декодирование calldata, предсказание отката, проверка формата полей. Симуляция выявляет очевидные проблемы, но имеет слепые зоны. Новые техники атак и сбои RPC могут её обойти.

Уровень 2: оценка контрагента. Набор статических проверок нацелен на контрагента: сверка получателя и суммы, обнаружение неограниченных разрешений, обнаружение burn-адресов, неожиданные делегированные вызовы. Оценка риска адреса выполняется через сервис соответствия x402 компании BlockSec, где агент запрашивает метки и оценки риска через микроплатежи x402 без необходимости API-ключа или подписки. Уровни 1 и 2 вместе выявляют большинство распространённых проблем, но оба могут быть обойдены. Их роль намеренно ограничена обнаружением и объяснением, но не принятием окончательных решений.

Уровень 3: принудительное применение жёстких политик. Чистое применение кода на Go. LLM не задействован, и агент не может изменять правила. Лимиты на одну транзакцию, дневные бюджеты, белые списки получателей, пороги автоподписания: перевод на $5 000 при лимите в $100 на транзакцию будет немедленно отклонён. Изменение самой политики требует Passkey. Почему? Если бы агент мог редактировать политики, одна инъекция сначала подняла бы лимит, а затем опустошила кошелёк. Автоподписание отключено по умолчанию; каждая транзакция требует ручного одобрения, пока пользователь явно не включит его.

Это означает, что даже если все уровни обнаружения пройдены и полностью скомпрометированный агент подписывает вредоносную транзакцию, реальные потери ограничены политикой. Если пользователь установил дневной порог автоподписания в $500, максимальные потери составят $500, а не весь кошелёк. Уровень политик превращает компрометацию из катастрофического события в ограниченные потери.

Уровень 4: подтверждение пользователя (Passkey). Когда политика требует ручного одобрения, система требует верификацию WebAuthn (отпечаток пальца или лицо). Никакой программный эксплойт не может подделать это.

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

Одна деталь, которую легко упустить: повторное использование вердиктов. Известная техника атаки в DeFi — воспроизведение старого вердикта безопасности против изменённой транзакции. Web3 Companion привязывает каждую операцию записи к уникальному намерению транзакции с отслеживаемыми переходами состояний. Вердикт безопасности применяется только к тому намерению, которое он проверил. Если агент пересобирает транзакцию, даже просто изменив сумму или получателя, система рассматривает её как совершенно новое намерение и повторно выполняет все проверки.

Четыре уровня защиты отображаются на три независимые границы доверия: приватный ключ, политика и Passkey. Нарушение любой одной границы оставляет две другие нетронутыми:

Безопасность по замыслу: философия за открытым исходным кодом

BlockSec занимается on-chain безопасностью с самого начала. Мы защитили миллиарды долларов в on-chain активах и видели, как один и тот же урок повторяется снова и снова: безопасность, которая не заложена в архитектуру с самого начала, всегда приходит слишком поздно.

ИИ-агенты становятся новой точкой входа для on-chain транзакций. Пространство развивается стремительно, но стандарты безопасности едва существуют. Большинство команд сосредоточены на том, что их агент умеет делать. Немногие серьёзно задались вопросом: если этот агент будет скомпрометирован, сможет ли архитектура ограничить масштаб ущерба?

Web3 Companion — это усилие BlockSec по воплощению многолетней работы в области on-chain безопасности в архитектуре Agentic Wallet. Код полностью открыт под лицензией MIT (в настоящее время помечен как предварительная версия для исследований). Индустрии прямо сейчас нужна конкретная точка отсчёта для дизайна безопасности. Как структурировать модели угроз, как изолировать ключи, насколько далеко заходить в защите транзакций — ни одной команде не стоит изобретать это заново с нуля. Мы публикуем полный дизайн, чтобы сообщество могло строить на его основе.