OWASP - батяня, батяня - OWASP. Свежий State of Agentic AI Security and Governance v2.01.

Главная мысль документа — Agentic AI Security перестал быть набором теоретических страшилок - есть реальные инциденты, CVE, prompt injection, supply-chain атаки, отравление памяти, злоупотребление tool-calling’ами и агенты, которые вполне самостоятельно делают то, чего от них никто не ожидал.

Теперь поп пунктам:

  1. Уровень риска теперь определяется не только тем, насколько хороша или плоха сама модель, а тем, что агент способен сделать без подтверждения человека.

    OWASP предлагает смотреть на агентов по уровню автономности: supervised → semi-autonomous → fully autonomous.

    Если агент умеет сам планировать, выполнять действия и повторять цикл без человека, одних промптов и guardrails уже недостаточно. Нужны:

    • жесткие границы полномочий;
    • детерминированные контрольные точки и автоматические механизмы прерывания;
    • аварийное отключение;
    • лимиты на время выполнения, количество обращений к API и вычислительные ресурсы;
    • отдельная цифровая идентичность агента;полный журнал его действий.

  2. Внедрение вредоносных инструкций никуда не делось и остается одной из фундаментальных проблем. Причина архитектурная, так как для LLM системный промпт, запрос пользователя, документ из RAG, электронное письмо, описание инструмента MCP и прочий контент в конечном итоге превращаются в один поток токенов. Надежной границы между «данными» и «инструкциями» пока нет. Поэтому стратегия постепенно меняется с «давайте полностью предотвратим внедрение инструкций» на «давайте сделаем так, чтобы даже скомпрометированный таким способом агент ничего критичного сделать не смог».

    Очень хорошо сюда ложится так называемая lethal trifecta:

    • агент имеет доступ к приватным данным;
    • читает недоверенный контент;
    • может самостоятельно отправлять данные наружу.

    Если все три возможности есть одновременно, то одна удачная injection уже потенциально превращается в полноценную цепочку эксфильтрации.

  3. Supply Chain у AI-агентов стала сильно интереснее обычной зависимости в requirements.txt. Теперь атаковать можно не только код, а:

    • MCP servers;
    • tool descriptions;
    • skill/plugin registries;
    • RAG;persistent memory;
    • внешние источники данных;
    • других агентов.

    Особенно занятный класс — Tool Poisoning, когда вредоносная инструкция находится не в исполняемом коде, а, например, в description инструмента. Человек смотрит на tool и считает его нормальным, а модель читает description и получает совсем другие инструкции.

    Или MCP Rug Pull - где сегодня tool выглядит безопасным, проходит проверку, а завтра его описание или поведение меняется. Поэтому обычного SBOM уже недостаточно. Теперь для Agentic AI надо знать не только «какие компоненты установлены», но и какие capabilities агент динамически подключил во время выполнения, кому они принадлежат и от чьего имени выполняются.

  4. Цифровая идентичность становится новым периметром.

    OWASP отдельно разделяет обычную цифровую идентичность нечеловеческих сущностей и цифровую идентичность агента. Ключ API или учетная запись службы отвечает на вопрос - «Этому субъекту вообще разрешено подключаться?» Для агента этого мало. Нужно понимать: * «Кто запустил этого агента?»; * «От чьего имени он действует?»; * «Какую задачу он сейчас выполняет?»; * «Кто делегировал ему полномочия?»; * «Имеет ли он право сделать именно это действие именно сейчас?».

    Отсюда требования к краткоживущим учетным данным, выдаче прав непосредственно перед выполнением задачи, криптографической аттестации, связыванию цепочек идентичности и сохранению контекста делегирования между агентами и инструментами. Короче, вечная учетная запись службы с широкими областями доступа OAuth для автономного агента. Если честно так себе идейка.

  5. MCP, A2A и другие агентные протоколы надо воспринимать не как удобные интеграции, а как новые границы доверия. Если агент умеет динамически обнаруживать инструменты, общаться с другими агентами и делегировать им задачи, появляются:

    • подмена агента;
    • повышение привилегий;
    • циклы делегирования;
    • транзитивное доверие;
    • отравление реестров;
    • подмена инструментов;
    • боковое перемещение между агентами.

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

  6. На уровне развертывания безопасность ИИ и эксплуатационная надежность начинают сливаться в одну проблему. Допустим, агент удалил рабочую БД. Если его заставил атакующий через внедрение вредоносной инструкции — вроде инцидент информационной безопасности. Если он сам потерял ограничение и удалил ее из-за ошибки рассуждения — вроде сбой надежности или безопасности поведения ИИ. Но архитектурная проблема одна и та же - агент вообще имел возможность удалить рабочую базу данных. Следовательно, модель полномочий, ограничение масштаба последствий, наблюдение и аварийное отключение защищают сразу от обоих сценариев.

    Поэтому OWASP считает, что на уровне развертывания безопасность поведения ИИ и информационную безопасность уже нельзя нормально вести как две независимые дисциплины с разными командами и разными процессами реагирования.

  7. Объяснимость тоже меняется. Для агента мало объяснить, «почему LLM дала такой ответ». Нужно уметь восстановить всю траекторию выполнения:

    • что агент получил на вход →
    • что достал из RAG →
    • какой инструмент выбрал →
    • какие параметры передал →
    • что получил обратно →
    • как изменилась память и состояние →
    • кому делегировал задачу →
    • какая контрольная точка политики разрешила действие.

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

  8. Управление тоже должно работать со скоростью агента. Ежеквартальная проверка и PDF с оценкой рисков плохо помогают, если агент способен сделать несколько тысяч действий за час. Нужны наблюдение во время выполнения, базовые профили поведения, выявление отклонений от плана, автоматическая классификация инцидентов и механизмы остановки, работающие за секунды. Участие человека при этом никуда не исчезает, но человек физически не сможет проверять каждое действие высоконагруженного автономного агента. Поэтому логика смещается к подтверждению по уровню риска - рутинные действия выполняются автоматически, а потенциально опасные должны детерминированно уходить на подтверждение.

  9. Модель зрелости. OWASP предлагает одновременно оценивать:

    • Уровень внедрения AT0–AT8 — насколько сложных агентов вы уже запустили.
    • Уровень зрелости управления 0–4 — насколько вы вообще способны ими управлять.

    Причем AT0 — это теневой ИИ, например, сотрудники уже используют ChatGPT, Claude, Gemini, браузерные расширения, локальные модели и ИИ-инструменты с корпоративными данными, а организация об этом толком не знает.

    Дальше идут встроенные помощники, агенты на платформах с минимальным программированием, агенты с выполнением кода, собственные агенты, MCP, многоагентные системы и наконец межорганизационные федеративные агентные системы.

    И логика довольно простая - если сложность развертывания выше зрелости управления, то либо поднимаете зрелость управления, либо уменьшаете автономность системы.

В сухом остатке. Безопасность Agentic AI — это уже далеко не только про защиту самой модели. Чем больше агенту дают автономности, инструментов и доступа к реальным системам, тем важнее становятся архитектура, полномочия, идентичность, контроль цепочки действий и возможность быстро его остановить.

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

И вот на этот второй вопрос, судя по документу OWASP, организация должна уметь отвечать еще до того, как агента докатят до прода.