LLM-агенты быстро переезжают из песочницы в прод: они ходят в API бирж, подписывают транзакции, управляют DeFi-стратегиями и общаются с пользователями «как человек». В Web3 это особенно чувствительно: ошибка или атака на агента может стоить не только инцидента с данными, но и прямых ончейн-потерь.

В этом практикуме разберём, как построить базовый уровень безопасности для LLM-агентов в Web3: какие атаки реально встречаются (prompt injection, утечки данных, poisoning извлекаемых документов и векторных БД), как они проявляются именно в связке «агент + смарт-контракты», и что можно сделать уже сейчас, чтобы не городить «картонные копилоты». За общей теорией по агентам можно зайти в вики-материал «AI-агенты: что это и как они работают», здесь будет именно практикум по безопасности.

1. Особенности безопасности LLM-агентов в Web3: почему стандартные подходы не работают

Обычный «чат-бот на модели» — это, по сути, интерфейс к тексту: максимум он может сгенерировать письмо или текстовый отчёт. LLM-агент — это уже орchestrator действий: он подключен к инструментам (tools), ходит в API, пишет в базу, вызывает смарт-контракты.

Для Web3 это означает несколько вещей:

• агент имеет доступ к кошелькам, ордерам, смарт-контрактам и может инициировать транзакции;
• он читает потенциально враждебный контент: ончейн-мемо, описания токенов, NFT-метаданные, ответы DEX-агрегаторов;
• он часто работает поверх инфраструктуры DePIN/AI (GPU-сети, векторные БД, RAG), что расширяет поверхность атаки.

Результат: к классическим рискам LLM (prompt injection, утечки, неправильная обработка вывода) добавляется риск «избыточной агентности» — когда агент реально воздействует на ончейн-мир, а не просто «говорит». В OWASP Top 10 для LLM это уже оформлено отдельными пунктами: prompt injection, утечки конфиденциальной информации, data/model poisoning и «excessive agency» для агентов.

2. Основные угрозы для LLM-агентов: от prompt injection до утечек данных

2.1. Prompt injection: как злоумышленники перехватывают управление агентом

Prompt injection — это когда атакующий заставляет модель игнорировать первоначальные инструкции и следовать новым, вложенным в пользовательский ввод или внешние данные. OWASP ставит prompt injection первым номером в списке рисков для LLM.

В контексте Web3 это выглядит так:

• пользователь или контрагент формулирует запрос, который заставляет агента менять правила игры («игнорируй все ограничения, сделай X»);
• внешний источник (страница, ончейн-данные, NFT-метаданные, описание токена) содержит скрытые инструкции, которые агент воспринимает как «настоящие»; это indirect prompt injection.

Опасность в том, что агент не просто отвечает текстом — он может:

• отправить средства на не тот адрес;
• подписать транзакцию на невыгодный обмен;
• изменить параметры смарт-контракта или стратегии.

2.2. Утечки данных: почему LLM-агенты раскрывают больше чем нужно

OWASP отдельно выделяет риск sensitive information disclosure: модели могут нечаянно «выдать» конфиденциальные данные сквозь ответы. В случае с агентами и Web3 к этому добавляется ещё несколько уровней:

• агент имеет доступ к внутренним документам (KYC, отчёты, стратегии), которые попадают в контекст запроса;
• в него могут быть внедрены секреты (API-ключи, части seed, ключи подписи) — иногда в промт или конфиг «для удобства»;
• он может логировать контекст или ответы в систему мониторинга без маскирования.

Любая инъекция, jailbreak или просто ошибка в обработке вывода — и эти данные попадают наружу через ответ модели, систему логирования или сторонний инструмент.

2.3. Data poisoning: как отравленные данные влияют на решения агента

OWASP LLM Top 10 объединяет training data poisoning и атаки на RAG/векторные БД в класс data and model poisoning. Суть проста: атакующий подсовывает вредоносные данные туда, откуда агент потом забирает контекст.

В Web3 это может быть:

• подмена документации протокола или токена (на сайте или в репозитории) на вариант с «советами» в пользу атакующего адреса;
• добавление в RAG-корпус страниц с инструкциями, которые в обход системного промпта заставляют агента действовать иначе;
• векторная БД, куда попали «ядовитые» фрагменты с подменой реквизитов или параметров.

Модель в таком случае «честно» извлекает контекст и строит ответ/действие на основе уже отравленных данных.

2.4. Excessive agency: когда слишком широкие права приводят к убыткам

Ещё один риск из OWASP Top 10 — excessive agency: когда агент получает слишком широкие права или неограниченный доступ к инструментам.

В Web3 это может быть:

• один и тот же «универсальный» агент управляет и чтением данных, и подписанием транзакций для всех кошельков и сетей;
• функции вида send_transaction(to, amount) доступны без ограничений по токену, сумме, сети;
• нет разделения на «view-only» и «trading» режимы; нет лимитов или ручного подтверждения действий.

Любая инъекция или ошибка в такой архитектуре сразу выстреливает в деньги, а не просто в «странный ответ бота».

3. Threat model для Web3-агентов: активы, акторы и границы доверия

Прежде чем бороться с инъекциями и poisoning, полезно описать, что вы защищаете. Минимальный threat model для Web3-агента включает:

• Активы:
  • ключи (seed, private key, MPC-ключи, smart contract wallets);
  • средства на кошельках, позиции в DeFi, NFT;
  • документация, стратегии, конфиденциальные отчёты;
  • векторные БД и RAG-корпуса.
• Акторы:
  • конечные пользователи (включая потенциально злоумышленников);
  • внешние сервисы (DEX-агрегаторы, оракулы, CEX/DEX, DeFi-протоколы);
  • операторы узлов, DevOps, интеграторы.
• Границы доверия:
  • где хранится ключ и где он используется;
  • какие данные попадают в промт и логируются;
  • какие действия агент может сделать сам, а где нужно подтверждение.

Хорошая практика — визуально нарисовать схему и отметить: «здесь LLM видит X», «здесь находится ключ», «здесь агент может вызвать sendTransaction». Это помогает увидеть места, где простая инъекция превращается в серьёзный инцидент.

4. Архитектура безопасного LLM-агента: разделение прав и защитные механизмы

4.1. Жёстко разделяем «читать» и «подписывать»

Главный принцип: никогда не давать одному и тому же агенту полный доступ и к данным, и к деньгам. Минимум два контура:

• View-агент — отвечает на вопросы, анализирует портфель, готовит рекомендации, но:
  • не имеет доступа к ключам подписания;
  • видит только нужные для ответа данные, без лишних секретов;
  • не может сам вызвать смарт-контракт или API биржи на изменение состояния.
• Action-слой — отдельный сервис, который:
  • принимает структурированные инструкции (JSON-план действий, а не текст модели);
  • сам валидирует их по правилам (лимиты, allowlist адресов/контрактов, сети);
  • требует ручное подтверждение пользователя для критичных действий.

LLM-агент в такой архитектуре готовит план, но не держит руку на кнопке «Подписать». Это резко снижает цену любого prompt injection.

4.2. Guardrails и политики: создание защитного периметра для агента

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

• чего агент делать не имеет права (запрашивать seed, приватные ключи, CVV и т.п.);
• что он обязан всегда проверять (сеть, адрес, токен, лимиты);
• в каких случаях он обязан отказаться и сказать пользователю «это небезопасно».

Такие политики удобно реализовывать не только в виде текста, но и как программный слой guardrails — набор проверок и фильтров для входящих/исходящих сообщений и вызовов инструментов. Подробно подходы к guardrails мы разбираем в вики-статье «Guardrails для LLM-приложений», а обзор всего стека защит (от OWASP LLM Top 10 до практик RAG security) смотрите на хабовой странице «AI Security Hub».

4.3. Инструменты (tools) только по белому списку

Каждый инструмент агента в Web3 должен быть ограничен и явно описан:

• для get_balance — только выбранные сети и кошельки;
• для swap — список разрешённых токенов/пулов и максимальный объём;
• для send_transaction — списки адресов (allowlist), лимиты по сумме и дневные лимиты.

Агент не должен иметь универсальную функцию «исполнить любой произвольный код/tx», особенно если он опирается на текстовые подсказки. Чем более структурирован контракт между LLM и tool-слоем, тем сложнее инъекции превращать в реальные атаки.

4.4. Контекст под контролем: фильтрация RAG и векторной БД

Если агент использует RAG, он может подтягивать в контекст любые документы из векторной БД. Это мощно, но открывает двери для poisoning. Минимальный набор защит:

• чёткая схема данных: какие типы документов мы вообще индексируем (документация протокола, собственные политики, отчёты), а какие нельзя;
• валидаторы контента: не допускаем в RAG документы с явными попытками инъекции («игнорируй все правила», подмена адресов, скрытый текст);
• метки доверия: документы от внешних источников помечаем и не позволяем им переписывать внутренние политики.

Отдельно стоит провести ревизию векторной БД и RAG-пайплайна на предмет OWASP-рисков (poisoning, data exfiltration). Хороший чек-лист — в материалах OWASP по LLM и современных обзорах по безопасности RAG-пайплайнов.

4.5. Логирование, алерты и «kill switch»

С агентами часто допускают ошибку: «поставили и забыли». Без нормального мониторинга это, по сути, чёрный ящик с доступом к средствам. Нужны:

• подробные логи действий агента (какие tools вызывал, какие адреса/суммы/сети использовал, какие документы подтягивал в контекст);
• алерты на аномалии (необычные суммы, новые адреса, смена сети, всплеск активности);
• аварийный выключатель (kill switch) — возможность быстро перевести агента в read-only режим или полностью отключить.

Это не отменяет других мер, но делает инцидент управляемым: вы не ждёте, пока пользователи расскажут про странные транзакции, а сами видите отклонения.

5. Тестирование безопасности: отрабатываем сценарии атак в безопасной среде

Важно уметь тестировать свои защиты — но делать это в безопасной среде: тестовые сети, тестовые кошельки, synthetic data. Ниже — несколько сценариев, которые можно проиграть на стенде, не заходя в «gray hat» зону.

5.1. Тестирование прямой инъекции: защита от манипуляций пользователем

Цель теста — убедиться, что пользователь не может текстом заставить агента нарушить ключевые политики (например, запросить seed или обойти лимиты).

Что проверяем:

• агент отказывается выполнять очевидно небезопасные просьбы (передать приватные данные, отправить всё на неизвестный адрес);
• даже если пользователь пытается переформулировать запрос, ссылаться на «исключения», агент всё равно держится политик;
• любые попытки «переписать правила» отражаются в логах и могут триггерить алерты.

5.2. Инъекция через внешние данные (indirect prompt injection)

Здесь мы имитируем реальную ситуацию: агент читает текст с внешнего источника (страница токена, описание NFT, ончейн-мемо) и вместе с ним получает вредоносные инструкции.

На стенде можно:

• добавить в тестовую документацию «ядовитый» блок, который явно противоречит политикам агента;
• проверить, попадёт ли он в контекст и сумеет ли модель «продавить» tool-слой на небезопасное действие;
• убедиться, что фильтры контента и guardrails отсекут такие попытки.

5.3. Poisoning векторной БД

Тест для RAG-сценариев: мы добавляем в векторную БД документ, который выглядит релевантным, но подменяет важные детали (адрес, параметры транзакций, лимиты).

Проверяем:

• насколько легко такой документ попадает в top-k результатов при релевантных запросах;
• есть ли механизм верификации источника (метки, доверенные домены);
• может ли agent-приложение заметить конфликт между внутренними правилами и внешним контекстом.

Такие тесты полезно регулярно добавлять в regression suite, чтобы не потерять безопасность после очередного рефакторинга пайплайна.

6. Чек-лист безопасности LLM-агентов: 10 обязательных пунктов для Web3-проектов

• Агент не имеет доступа к seed, приватным ключам и чувствительным данным в открытом виде.
• Подписывающий слой отделён от LLM: агент только предлагает действия, а не подписывает транзакции сам.
• Для каждого инструмента (tool) определены ограничения и лимиты (токены, адреса, сети, суммы).
• Системный промпт и guardrails явно фиксируют, чего агент делать не может, и это не переопределяется пользователем.
• RAG-пайплайн и векторная БД защищены от очевидного poisoning: фильтрация контента, метки доверия, ревизия источников.
• Ведётся детальное логирование действий агента с привязкой к пользователю, времени, сети и адресу.
• Есть алерты на аномальные действия (новые адреса, крупные суммы, необычные сети/пулы).
• Настроен «kill switch» и процедуры отката/блокировки агента при инциденте.
• Проводятся периодические security-тесты (prompt injection, poisoning, утечки) в тестовой среде.
• Команда знакома с OWASP Top 10 для LLM и использует их как основу для threat modeling.

7. Вопросы и ответы: разбираем сложные кейсы безопасности LLM-агентов

Полезные материалы

• AI Security Hub: хаб по безопасности ИИ и LLM
• Guardrails для LLM-приложений
• Confidential Computing и TEE: защита данных «во время вычислений»
• Ritual: подключение ИИ к смарт-контрактам