AI-агенты уже вышли за пределы чат-ботов. Они читают документы, вызывают API, анализируют логи, создают тикеты, готовят правки в коде и выполняют многошаговые задачи без ручного подтверждения каждого шага. Это делает их полезными, но меняет модель риска: агент с инструментами становится явным риском внутри инфраструктуры.
Главная идея Zero Trust для таких систем проста: агенту нельзя доверять по умолчанию только потому, что он запущен внутри компании или работает от имени легитимного пользователя. Его идентификация, права, вызовы инструментов (tool calls), память и действия нужно проверять так, будто компрометация рано или поздно случится.
Идея для статьи была придумана после прочтения PDF от Anthropic Zero Trust for AI Agents. Но все принципы изложенные в статье применимы к любому LLM-агенту: юридическому помощнику, SOC-агенту, агентам для разработки, RAG-системе, внутреннему ассистенту или многоагентному workflow.
Всем привет! Меня зовут Сергей, я админ Похек и Похек AI. В этой статье я расскажу о Zero Trust для AI-агентов. Приятного чтения!
Содержание
Что такое AI-агенты и Zero Trust
Почему агенты требуют отдельной модели безопасности
Главные атаки на агентные системы
Дизайн-тест: атака невозможна или просто неудобна
Минимальный baseline безопасного агента
Инструменты, данные, память и наблюдаемость
Как внедрять по шагам
Защитные агенты и Agentic SOAR
1. Что такое AI-агенты и Zero Trust
AI-агент — это LLM-система, которая получает цель, планирует шаги и вызывает внешние инструменты: файловую систему, браузер, базу данных, корпоративный API, почту, SIEM, CRM, ERP или тикет-систему. Если обычный чат-бот в основном генерирует ответ, агент может менять состояние внешних систем.
Отсюда и популярность. Бизнесу нужны не ответы ради ответов, а автоматизация цепочек: найти данные, сверить их, подготовить документ, обновить систему, собрать артефакты расследования и передать человеку готовый результат.
Примеры применения:
юридическая сфера: анализ договоров, поиск рискованных формулировок, сравнение редакций, черновики правок;
операционная деятельность: обработка заявок, обновление CRM/ERP, отчеты, внутренние ассистенты для поддержки;
кибербезопасность: triage алертов, анализ логов, проверка уязвимых версий, подготовка отчёта об инциденте, помощь в устранении последствий.
Zero Trust — это архитектурный подход, при котором сеть, пользователь, сервис или агент не получают доверие автоматически. NIST SP 800-207 описывает Zero Trust как сдвиг от статического сетевого периметра к постоянной проверке пользователей, устройств, приложений, данных и ресурсов. В прикладном виде это означает: проверять каждое действие, выдавать минимальные права, сегментировать доступ, логировать операции и проектировать систему с расчетом на компрометацию.
Для AI-агентов это особенно важно. Агент автономен, читает недоверенный текст, вызывает инструменты и может ошибочно принять внешнюю инструкцию за часть задачи. Значит, он должен быть отдельной identity с ограниченными правами, понятным blast radius и полной трассировкой действий.
2. Почему агенты требуют отдельной модели безопасности
Обычное приложение выполняет заранее заданную логику. Агент интерпретирует цель, выбирает инструменты, строит промежуточные шаги и иногда сохраняет контекст между сессиями. Поэтому традиционные ACL и общие сервисные аккаунты быстро ломают расследуемость.
Если агент работает от service-account-prod, непонятно, какая именно система выполнила действие. Если один токен дает доступ к CRM, почте и внутреннему wiki, blast radius становится слишком большим. Если tool call логируется без request ID, цепочку событий трудно восстановить.
Zero Trust для агентов начинается с признания: агент — не «умный пользователь» и не безликий процесс на сервере. Это самостоятельный участник системы. Ему нужны собственная идентификация, собственные креды, собственные политики доступа и отдельная телеметрия.
3. Главные атаки на агентные системы
Prompt injection. Прямая атака приходит через пользовательский ввод: просьба игнорировать инструкции, закодированный payload, adversarial suffix. Косвенная prompt injection опаснее: вредная инструкция спрятана в письме, PDF, issue, веб-странице или RAG-фрагменте. Агент читает источник и принимает чужую команду за контекст рабочей задачи.
Tool poisoning. Атакующий меняет описание инструмента, схема, метаданные или MCP-сервер. Агент выбирает инструмент по объявленным возможностям, поэтому подмена описания инструмента может привести к утечке данных или нежелательному действию. Вариант rug pull еще неприятнее: инструмент выглядит нормальным на этапе подтверждения действий, а вредоносным становится позже.
Tool chaining. Отдельные действия могут быть разрешены, но последовательность становится опасной. Например: прочитать данные из CRM, преобразовать их и отправить наружу через email tool. Мониторинг отдельных вызовов не всегда видит вредную цепочку.
Privilege abuse. Manager-agent может делегировать задачу worker-agent и случайно передать ему полный набор прав. Низкопривилегированный агент может отправить инструкцию высокопривилегированному, а тот выполнит ее без проверки исходного намерения пользователя. Это confused deputy в агентной форме.
Memory и RAG poisoning. Вредная инструкция может попасть в долговременную память, summary, embedding store или общий контекст. После этого агент будет использовать загрязненные данные в будущих сессиях. В RAG-системах риск усиливается, если нет source attribution и разделения доверенных и недоверенных источников.
Supply chain. Агентная система зависит от моделей, датасетов для fine-tuning, MCP-серверов, open-source библиотек, Docker-образов, плагинов и skills. Проверять нужно весь набор компонентов, которые агент загружает или вызывает, включая основной код приложения.
4. Дизайн-тест: атака невозможна или просто неудобна
В PDF Anthropic есть сильный инженерный фильтр: контроль делает атаку невозможной или только утомительной?
Rate limiting, нестандартные порты, лишние hop-ы и длинные ручные процедуры покупают время, но слабо работают против автоматизированного противника. AI-assisted attacker может терпеливо повторять попытки, читать patch diff, перебирать варианты и масштабировать однотипные действия.
Более надежные барьеры выглядят иначе:
короткоживущие токены вместо статических API-ключей;
криптографически проверяемая identity вместо строкового имени агента;
deny-by-default вместо широкого доступа с последующими запретами;
аппаратно привязанные credentials для чувствительных workload-ов;
отсутствующий network path вместо «труднодоступного» пути;
отдельные права на каждый инструмент вместо общего сервисного аккаунта.
Если защита держится на надежде, что атакующий не догадается или быстро устанет, для агентных систем это слабый контроль. Хороший контроль убирает возможность, а не рассчитывает на неудобство.
5. Минимальный baseline безопасного агента
Базовый уровень можно собрать без экзотики и извращений.
Уникальная идентификация. У каждого агента или agent instance должен быть собственный идентификатор, привязанный к криптографическому материалу: сертификату, коротко живущему токену, идентификации рабочих действий или похожему механизму.
Короткоживущие credentials. Статические API-ключи в .env, Docker образ, конфиге или репозитории стоит считать уже скомпрометированными. Базовый вариант — токены от identity provider-а с временем жизни в минутах и автоматическим перевыпуском токенов.
Запрет по умолчанию или принцип наименьших привилегий. Почтовый ИИ агент читает письма, но не отправляет и не удаляет. БД-агент выполняет read-only запросы к нужным таблицам, но не меняет схему. SOC-триажер агент читает SIEM/EDR, но не изолирует хост без отдельного человеческого подтверждения.
Изоляция среды выполнения. Агент, который читает сайты, документы, тикеты или пользовательские файлы, должен работать в песочнице, контейнере, microVM или другом ограниченном окружении с минимальными сетевыми или файловыми доступами.
Логирование tool calls. Нужно фиксировать, кто вызвал инструмент, с какими параметрами, от имени какого идентификатора, в рамках какого ID запроса, какой был результат и было ли человеческое подтверждение.
Откат конфигураций. Промпты, список разрешённых инструментов (tools allowlist), политики и настройки агентов должны жить в версионированной системе, типа гита. Для продовой системы стоит добавить подпись конфигураций и проверку перед деплоем.
6. Инструменты, данные, память и наблюдаемость
Инструменты — самая опасная часть агентной системы, потому что через них модель получает воздействие на инфраструктуру. Агенту не нужен «пул всех доступных инструментов». Ему нужен allowlist под конкретную функцию: read_contract, compare_versions, create_review_comment, query_siem_readonly.
Параметры tool call нужно валидировать до выполнения и на стороне самого инструмента. Агент может ошибиться, быть скомпрометированным или получить вредоносную инструкцию из контекста. Поэтому бекенд не должен верить агенту так же, как не должен верить обычному клиенту.
Для опасных действий нужен human-in-the-loop. Человеку стоит показывать не сырой JSON, а понятное описание: что агент собирается сделать, какие данные затронет, можно ли откатить действие и почему агент считает его нужным. Подтверждение тоже должен попадать в журнал безопасности.
Память агента требует отдельного внимания. Минимальные правила: изоляция между пользователями и клиентскими контурами, указание источника для каждого элемента, TTL для временного контекста, проверки целостности при извлечении, карантин и откат для отравленной агентской памяти. В RAG-системах особенно важно отделять доверенный системный контекст от недоверенных данных, которые загружают пользователи или агент получает из внешних источников.
Техники вроде Spotlighting помогают явно отделить внешний контент от инструкций. Microsoft показала в экспериментах, что Spotlighting снижал процент успешных indirect prompt injection с более чем 50% до менее 2%. Это не универсальная защита, но хороший пример внешнего контроля: мы меняем формат подачи контекста, а не просим модель «самой разобраться».
Наблюдаемость должна отвечать на вопросы расследования: какой входной запрос запустил цепочку, какие документы были извлечены, какие tools вызваны, какие параметры переданы, кто подтвердил действие и какой результат получился. Минимальный набор: request ID, идентификатор агента и идентификатор пользователя-человека отдельно, логи вызванных tools, трейса для многоагентных процессов, записи подтверждений человеком и неизменяемый журнал безопасности для чувствительных операций, чтобы снизить риск незаметного удаления следов ошибки или атаки.
Две полезные метрики: время обнаружения и покрытие расследований. Первая показывает, сколько проходит от аномалии до осведомленности человека. Вторая — какая доля алертов действительно расследуется. Если агент начал вести себя странно, команда должна узнать об этом за минуты или часы, а не после жалобы пользователя.
7. Как внедрять по шагам
Опишите use case: что агент делает, какие данные видит, какие действия выполняет, где нужен человек.
Назначьте отдельную identity и уберите shared service account.
Составьте tool allowlist и включите deny-by-default.
Разделите права: read-only по умолчанию, write/delete/outbound actions через отдельное разрешение.
Изолируйте runtime: sandbox, контейнер, microVM, ограниченный filesystem и egress.
Настройте telemetry: request ID, tool logs, traces, audit trail, approval records.
Защитите память и RAG: source attribution, TTL, проверки целостности, изоляция между пользователями и клиентскими контурами.
Проверьте supply chain: SBOM/AI-BOM, OpenSSF Scorecard для зависимостей, review MCP/tool providers, подпись артефактов.
Проведите tabletop не на один инцидент, а на несколько одновременных: prompt injection, утечка токена, poisoned RAG и вредный tool update.
Измерьте скорость обнаружения: узнаете ли вы в течение часа, что агент вышел за ожидаемое поведение?
Для supply chain полезно думать шире классического SCA. OWASP развивает идею AI-BOM поверх CycloneDX ML-BOM: учитывать модельные компоненты, происхождение данных, fine-tuning и связанные артефакты. OpenSSF Scorecard помогает оценивать здоровье open-source зависимостей по признакам поддержки, branch protection, signed releases и практик безопасности.
8. Защитные агенты и Agentic SOAR
Защитные агенты могут быстро обогащать алерты, собирать evidence, сопоставлять события, готовить черновики выводов и помогать аналитику не тонуть в рутине. Но защитный агент остается агентом. Если он может изолировать хост, отозвать креды/учётку или менять правила firewall, то потенциальный масштаб ущерба становится большим.
Практичный старт — read-only триаж перед очередью алертов. Пусть агент берет один шумный правило детекта, собирает контекст из SIEM/EDR, формирует структурированную аналитику и показывает её SOCовцу. Две недели сравнения с человеческой оценкой дадут больше пользы, чем попытка сразу автоматизировать весь SOC.
Автоматизировать стоит сбор данных, обогащение данных, корреляцию, заметки, черновик постмортема и подготовку артефактов расследования. Решения о локализации инцидента, раскрытии информации, отключении сервиса и внешних коммуникациях должны оставаться за людьми, особенно пока система не прошла зрелую эксплуатацию.
Для агентов в blue team применяются те же правила: отдельная идентификация, минимальные права, песочница, журнал безопасности, подтверждение для высоко-рисковых действий, откат действий и мониторинг поведения.
9. Итоговый чеклист
Область | Минимум для старта | Красный флаг |
Identity | Уникальная cryptographic identity на агента | Все агенты работают от одного service account |
Credentials | Short-lived tokens, secrets из vault/runtime | API-ключи лежат в |
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 | Агент сразу получает право изолировать системы |
Zero Trust для AI-агентов — это вопрос проектирования: каждое действие проверяется, привилегии ограничены, каждый инструмент имеет границы выполнения, а расследование можно провести по фактам и без танцов с бубном. Если агент не может причинить большой ущерб даже после промпт инъекции, отравления контекста или утечки одного токена, то вы движитесь в правильном направлении. Если безопасность держится на надежде, что модель «поймет правильно», агенту дали слишком много доверия. А такую веру можно сравнить с верой, что вот в следующий раз вот точно точно выпадет 20 черное)
Одностраничный чеклист по Zero Trust для AI-агентов вынес отдельно в Telegram: @poxek_ai — AI security, LLM-агенты и практика без новостей ради новостей.