Границы ИИ-агента задаются не в промпте. Они задаются в модели разрешений. Практическое правило, опубликованное Meta в ноябре 2025 года — Agents Rule of Two — гласит, что агент должен обладать не более чем двумя свойствами из трёх: обрабатывать недоверенный ввод, иметь доступ к чувствительным данным и изменять состояние или общаться вовне. Агент, у которого есть все три, превращается в инструмент утечки данных одним внедрённым текстом. Работающая модель разрешений действует на четырёх уровнях — личность, инструмент, аргумент и бюджет — и заранее помечает необратимые действия для человеческого утверждения.
Почему промпт не является средством защиты
Самая частая инструкция, которую мы находим в унаследованных проектах, звучит примерно так: не удалять клиентов, не отправлять письма без утверждения, не раскрывать внутреннюю информацию. Эта фраза лежит в системном промпте и создаёт ощущение защиты. Защитой она не является.
Промпт — это статистическая подсказка, а не разрешение. Он конкурирует за внимание модели со всем остальным текстом в контексте, включая тот, что пришёл извне. Как только агент прочитал письмо, веб-страницу, загруженный клиентом файл или результат работы инструмента, этот текст оказывается в том же пространстве, что и ваши инструкции. В этом вся суть prompt injection, и поэтому переформулировками из проблемы не выйти.
Правильное разделение простое: промпт задаёт намерение, модель разрешений задаёт возможность. То, чего агент технически не может сделать, он не сделает — как бы убедительно его ни уговаривали.
Быстрая проверка: если ваша единственная защита от разрушительного действия — фраза в промпте, у вас нет защиты. У вас есть вежливая просьба.
Rule of Two: самый практичный из опубликованных подходов
1 ноября 2025 года Meta опубликовала необычно простой подход к проектированию более безопасных агентов. Он выделяет три свойства и утверждает, что агент в рамках одной сессии должен обладать не более чем двумя из них.
| Свойство | Что это значит | Типичный пример |
|---|---|---|
| A. Недоверенный ввод | Агент читает содержимое, которым управляет кто-то другой | Входящая почта, формы, веб-страницы, загруженные документы |
| B. Доступ к чувствительным данным | Агент может читать приватные данные или внутренние системы | CRM, зарплатные данные, внутренняя база знаний, почтовый ящик |
| C. Изменение состояния или внешняя коммуникация | Агент может записывать, отправлять или публиковать | Отправка письма, вызов внешнего API, обновление записи, списание средств |
Опасность живёт в сочетании всех трёх. Агент, который читает входящее письмо (A), достаёт данные клиента из CRM (B) и может отправлять письма (C), превращается в машину для утечки в тот момент, когда кто-то присылает ему сообщение со скрытой инструкцией. Атакующему не нужно ничего ломать — ему достаточно написать текст.
Meta сама подчёркивает, что это правило не финишная черта. Оно не защищает ни от ошибок агента, ни от инъекций, которые лишь порождают дезинформацию в ответе, ни от слишком широких разрешений внутри двух оставленных осей. Это инструмент снижения худшего сценария, а не замена эшелонированной защиты.
Как разорвать сочетание на практике
В большинстве случаев отказываться от возможности не нужно — её нужно разнести на двух агентов или на два этапа. Вот три работающих шаблона.
| Шаблон | Что разделяется | Когда применять |
|---|---|---|
| Читатель и исполнитель | Один агент читает недоверенный ввод и возвращает только структурированную сводку; второй агент действует по этой сводке в реальных системах | Обработка почты, форм, клиентских документов |
| Человеческая подпись | У агента есть все три свойства, но действие C проходит через человеческое утверждение | Когда процесс действительно нельзя разделить |
| Закрытый канал вывода | Агент может писать только по адресам из фиксированного белого списка | Внутренняя отчётность, обновление записей, подготовка черновиков |
Второй шаблон самый распространённый, и он же деградирует быстрее всех: утверждение, ставшее рефлексом, перестаёт быть контролем. Где именно ставить точку утверждения и как сохранить её осмысленной, разобрано в нашем руководстве о человеке в цикле.
Модель разрешений из четырёх уровней
Разрешение агента — не бинарный вопрос доступа к системам. Оно строится на четырёх уровнях, и каждый пропущенный уровень открывает целый класс отказов.
| Уровень | На какой вопрос отвечает | Что происходит, когда его нет |
|---|---|---|
| Личность | От чьего имени действует агент | Действия приписаны анонимной сервисной учётной записи; ни аудиторского следа, ни возможности восстановить картину |
| Инструмент | Какие действия у него вообще есть | Агент обнаруживает возможность, которой не должен был иметь, например удаление через универсальный инструмент обновления |
| Аргумент | К чему он может применить это действие | Верный инструмент, неверная область — обновление применено ко всем записям вместо одной |
| Бюджет | Сколько, как быстро и до каких пор | Цикл, проходящий сотни шагов или тысячи вызовов до того, как кто-то это заметит |
Уровень аргументов забывают чаще всего, и именно он приносит большую часть реального ущерба. Агент, которому разрешено обновлять статус заказа без ограничения области, может обновить все заказы. Простое правило: каждый пишущий инструмент проверяет свои аргументы на стороне сервера, а не в инструкциях модели.
Prompt injection и злоупотребление инструментами: что уже происходило
В декабре 2025 года OWASP опубликовал Top 10 рисков для агентных приложений. Риск под кодом ASI02, Tool Misuse and Exploitation, описывает ровно тот случай, когда агент разрушительно использует разрешённый инструмент, — и рекомендуемая мера защиты это гранулярные разрешения и строгая проверка аргументов перед выполнением. Это не теоретическая рекомендация.
Конкретный пример: CVE-2025-59528 во Flowise, low-code платформе для сборки агентных приложений, возникла из-за небезопасной обработки конфигурационных данных CustomMCP и позволяла внедрять и выполнять произвольный JavaScript. Уязвимость была не в модели. Она была в слое между моделью и инструментами — ровно там, где большинство команд видит обычную сантехнику.
Сама спецификация движется в ту же сторону: стабильная редакция Model Context Protocol от 28 июля 2026 года называет усиление авторизации одним из ключевых изменений наряду с переходом к протоколу без состояния. Тот, кто строит слой инструментов сегодня, стартует с лучшей базы, чем год назад, но база не заменяет ваших собственных решений.
Чего агент никогда не делает в одиночку
Список ниже не зависит от отрасли. Это действия, где цена ошибки выше цены трения.
- Движение денег. Списания, зачисления, возвраты, изменение условий оплаты.
- Внешняя коммуникация от имени компании. Письма клиентам, сообщения, публикации — готовить да, отправлять нет.
- Удаление и любое необратимое действие. Всё, у чего нет кнопки отмены.
- Изменение разрешений. Агент, способный расширить собственные разрешения, — это не агент, а дыра.
- Действия в широкой области. Массовые обновления, выгрузки базы данных, изменения конфигурации систем.
- Решения с юридическими или регуляторными последствиями. Отказ по страховому случаю, классификация сотрудника, объявление обязывающей цены.
Что агенту разрешено читать — отдельный и не менее важный вопрос: классификация информации, которую можно отдавать модели, разобрана в нашем руководстве по классификации корпоративных данных.
Как это выглядит, когда сделано правильно
Хорошая модель разрешений скучна. Она выглядит как таблица: у каждого инструмента есть владелец, уровень риска, допустимый диапазон аргументов, суточный потолок вызовов и признак того, требуется ли утверждение. Эта таблица пишется до первого промпта и пересматривается при каждом изменении.
Три проверки, которые стоит провести на любом агенте перед продакшеном: попытаться внедрить инструкцию через каждый канал недоверенного ввода и убедиться, что она никогда не доходит до пишущего инструмента; вызвать каждый пишущий инструмент с аргументом вне допустимого диапазона и убедиться, что он отклонён на стороне сервера; и запустить агента на заведомо невыполнимой цели и убедиться, что он останавливается на потолке бюджета, а не продолжает. Полная методика этих проверок — в нашем руководстве по оценке, а структура, на которой всё держится, разобрана в материале Анатомия корпоративного ИИ-агента.
Частые вопросы
Что такое Rule of Two от Meta?
Подход к безопасности, опубликованный Meta в ноябре 2025 года: агент в рамках одной сессии должен обладать не более чем двумя свойствами из трёх — обработка недоверенного ввода, доступ к чувствительным данным и возможность менять состояние или общаться вовне. Сочетание всех трёх превращает одну prompt injection в утечку данных.
Можно ли полностью предотвратить prompt injection?
Доступными сегодня методами — нет. Любой текст, попавший в контекст, конкурирует за внимание модели, включая текст из внешних источников. Поэтому защита состоит не в предотвращении, а в ограничении ущерба: минимальные разрешения, разделение чтения ввода и выполнения действий, человеческое утверждение необратимых шагов.
Чем разрешения пользователя отличаются от разрешений агента?
Разрешения пользователя проверяются один раз при входе и предполагают человеческое суждение на протяжении всей сессии. Разрешения агента приходится проверять при каждом вызове — на уровне инструмента и на уровне аргумента, потому что между шагами человеческого суждения нет. На практике это означает проверку на стороне сервера, а не доверие к инструкциям модели.
Как ограничить агента, не сделав его бесполезным?
Разделять, а не блокировать. Агент-читатель, возвращающий структурированную сводку, плюс агент-исполнитель, действующий только по этой сводке, сохраняет всю бизнес-возможность и убирает опасное сочетание. Там, где разделение невозможно, добавьте точку утверждения только на исходящее действие.
Кто должен владеть моделью разрешений?
Тот, кто несёт последствия, если наружу уйдёт неверное действие, — обычно владелец бизнес-процесса, а не команда разработки. Техническая команда её реализует, но решение о том, какие действия необратимы и какие требуют утверждения, — бизнес-решение.
Продолжить чтение
Запуск ИИ-агентов на собственной инфраструктуре – Где границы разрешений действительно применяются, когда агент начинает работать с реальными инструментами.
Как оценить агента до того, как его увидит клиент – Методика проверки того, что границы держатся от прогона к прогону.