Современный ИИ-агент — это не система, которая отвечает на вопросы. Это процесс, который получает цель, планирует шаги и вызывает внешние инструменты: файловую систему, браузер, корпоративный API, почту, SIEM, CRM или тикет-систему. Разница принципиальная: обычный чат-бот генерирует текст, агент меняет состояние внешних систем. Именно поэтому модель риска у них разная.
Zero Trust — архитектурный подход, описанный в стандарте NIST SP 800-207. Его суть: ни сеть, ни пользователь, ни сервис не получают доверие автоматически. Каждое действие проверяется, права выдаются минимальные, доступ сегментируется, операции логируются, а система проектируется с расчётом на то, что компрометация рано или поздно произойдёт. Применительно к ИИ-агентам это означает: агент, запущенный внутри компании от имени легитимного пользователя, всё равно не получает доверия по умолчанию.
| Область | Минимум для старта | Красный флаг |
|---|---|---|
| Identity | Уникальная cryptographic identity на агента | Все агенты работают от одного service account |
| Credentials | Short-lived tokens, secrets из vault/runtime | API-ключи лежат в .env, image или repo |
| Tools | Allowlist, deny-by-default, validation параметров | Агент видит весь набор инструментов платформы |
| Права | Read-only по умолчанию, approval для опасных действий | Агент может писать, удалять или отправлять наружу без подтверждения |
| Runtime | Sandbox/container/microVM, ограниченный egress | Агент с untrusted input имеет широкий filesystem/network access |
| Memory/RAG | Source attribution, TTL, isolation, integrity checks | Общая память без источников и сроков жизни |
| Logs | Request ID, tool calls, approvals, traces | Есть только общий прикладной лог |
| Recovery | Versioned configs, rollback, signed artifacts | Prompt и policies меняются вручную без истории |
| Supply chain | SBOM/AI-BOM, проверка зависимостей и tool providers | MCP/tools ставятся без review и pinning |
| SOC | Read-only triage сначала, человек принимает containment | Агент сразу получает право изолировать системы |
Проблема традиционных подходов в том, что агент — не «умный пользователь» и не безликий серверный процесс. Если он работает от общего service-account-prod, невозможно понять, какая именно система выполнила действие. Если один токен даёт доступ к CRM, почте и внутреннему wiki одновременно, blast radius при компрометации становится неприемлемо большим. Если tool call логируется без request ID, цепочку событий после инцидента трудно восстановить.
Главные угрозы — prompt injection через PDF и письма, подмена описания инструментов (tool poisoning) и опасные цепочки вызовов (tool chaining).
Атаки на агентные системы делятся на несколько классов. Prompt injection — наиболее известная: вредная инструкция прячется не в пользовательском вводе, а в письме, PDF, issue или фрагменте RAG-базы. Агент читает источник и принимает чужую команду за часть рабочей задачи. Tool poisoning работает иначе: атакующий подменяет описание инструмента или MCP-сервер, и агент выбирает «отравленный» инструмент, опираясь на его объявленные возможности. Есть и вариант rug pull: инструмент выглядит нормальным на этапе подтверждения, а вредоносным становится позже. Tool chaining — ситуация, когда отдельные разрешённые действия складываются в опасную последовательность: прочитать данные из CRM, преобразовать их и отправить наружу через email tool. Мониторинг отдельных вызовов такую цепочку не всегда замечает.
Отдельный класс угроз — memory и RAG poisoning. Вредная инструкция попадает в долговременную память агента, embedding store или общий контекст, после чего агент использует загрязнённые данные во всех последующих сессиях. В RAG-системах риск усиливается при отсутствии source attribution и разделения доверенных и недоверенных источников.
Полезный инженерный фильтр, предложенный Anthropic в документе Zero Trust for ИИ Agents: контроль делает атаку невозможной или только утомительной? Rate limiting, нестандартные порты и длинные ручные процедуры покупают время, но слабо работают против автоматизированного противника. ИИ-assisted атакующий может терпеливо повторять попытки, читать patch diff и масштабировать однотипные действия. Надёжные барьеры выглядят иначе: короткоживущие токены вместо статических API-ключей, криптографически проверяемая identity вместо строкового имени агента, deny-by-default вместо широкого доступа с последующими запретами, отсутствующий network path вместо «труднодоступного».
Минимальный baseline безопасного агента собирается из нескольких элементов. Уникальная идентификация: у каждого агента или agent instance — собственный идентификатор, привязанный к криптографическому материалу: сертификату или короткоживущему токену. Статические API-ключи в.env, Docker-образе или репозитории следует считать уже скомпрометированными; базовый вариант — токены от identity provider с временем жизни в минутах и автоматическим перевыпуском. Принцип наименьших привилегий реализуется конкретно: почтовый агент читает письма, но не отправляет и не удаляет; БД-агент выполняет read-only запросы к нужным таблицам, но не меняет схему; SOC-агент читает SIEM и EDR, но не изолирует хост без отдельного подтверждения человека. Агент, который читает сайты, документы или пользовательские файлы, должен работать в песочнице, контейнере или microVM с минимальными сетевыми и файловыми доступами.
Важно логировать каждый tool call с привязкой к request ID — это позволяет восстановить цепочку событий после инцидента и отличить легитимное действие агента от скомпрометированного. Наблюдаемость агентной системы — не опция, а условие расследуемости.
