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

GitHub: blocksecteam/web3-companion

Docker: blocksecteam/web3-companion

Предоставление ИИ возможности выполнять on-chain транзакции от имени пользователей — самый горячий тренд в криптоиндустрии прямо сейчас. Coinbase запустил Agentic Wallets в феврале 2026 года, а по оценкам McKinsey объём коммерции под управлением ИИ-агентов к 2030 году может достичь 3–5 триллионов долларов в мировом масштабе. Как выразился генеральный директор 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: подготовка — это не авторизация. Формирование транзакции и её подтверждение — два разных действия. Агент может помогать пользователям понимать состояние сети и составлять намерения, но решение о подписании принадлежит независимому серверному модулю, к которому агент не имеет доступа.

Принцип 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: оценка контрагента. Набор статических проверок нацелен на контрагента: соответствие получателя и суммы, обнаружение безлимитного одобрения, обнаружение адреса сжигания, неожиданные делегированные вызовы. Оценка риска адреса выполняется через сервис соответствия 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 (в настоящее время помечен как исследовательский превью). Индустрии прямо сейчас нужна конкретная точка отсчёта для проектирования безопасности. Как выстраивать модели угроз, как изолировать ключи, насколько далеко заходить в защите транзакций — ни одна команда не должна изобретать всё это с нуля. Мы публикуем полный проект, чтобы сообщество могло строить на его основе.