Суть
У обычного веб-сервиса периметр привычен: вход, база, права пользователя, логирование. У агента добавляется слой принятия решений, который работает с частично недоверенным контекстом, сам выбирает инструменты, собирает длинные цепочки действий и может выглядеть разумным уже после того, как ушёл за безопасные границы.
Отсюда следствие: периметр нельзя свести к одному входному фильтру. Нужна серия контрольных точек, и каждая ловит свой класс отказа.
Три вопроса на одном запросе
Для агента поддержки, который проверяет статус заявки и создаёт срочный тикет:
- Что видеть — какие поля заявки, какую часть профиля пользователя, какой корпус базы знаний, в границах какого арендатора.
- Что решать — может ли он сам заключить, что заявка «застряла», и что случай надо эскалировать.
- Что исполнять — имеет ли право создать тикет или нужно подтверждение (Approval Path).
Проверка зрелости периметра формулируется как требование к объяснению: если команда не может в одном абзаце сказать, что агент видит, что решает и что исполняет, периметр ещё размыт.
Оговорка о происхождении, существенная при сверке: разделение на три вопроса — организующая рамка, а не формулировка стандарта. OWASP раскладывает ту же область иначе — по бюджетам и петлям, одобрению высокорисковых действий, изоляции и авторизации инструментов, идентичности, делегированию и останову. Механизмы ниже подтверждены стандартом поимённо, рамка — нет, и пользоваться ею стоит как способом задать вопросы, а не как перечнем требований к сдаче.
Карта эшелонированной защиты
Полезная карта — не стена слоёв, а короткая цепочка «где отказ должен быть остановлен» с проверяемым следом на каждом рубеже:
| Рубеж | Что удерживает |
|---|---|
| Контроль входа | Небезопасный или слишком широкий ввод до того, как он станет контекстом |
| Граница контекста | Смешение доверенных инструкций и недоверенного содержимого |
| Шлюз поиска и памяти | Превращение недоверенного содержимого в долговечную память (RAG Poisoning) |
| Политика шлюза модели | Иерархию инструкций и политику безопасности (Instruction Hierarchy) |
| Шлюз инструментов и подтверждение | Право на действие вне вероятностной генерации (Tool Gateway) |
| Граница MCP и делегирования | Внешние возможности и риск передачи полномочий (MCP, Agent2Agent Protocol) |
| Выходной фильтр | То, что выходит из системы (DLP for LLM) |
| След доказательств | Связь всех рубежей с трассой, чтобы защиту можно было проверить аудитом |
Последняя строка — то, что отличает работающую карту от декларации: слой, чью работу нельзя доказать следом в трассе, невозможно ни проверить, ни предъявить после инцидента.
Главное практическое правило: отделяй инструкции от данных
Пользовательский ввод, письма, PDF, вывод инструментов, найденные документы, веб-контент — всё это по умолчанию данные, а не новые инструкции. Без явной границы внедрение инструкций через подсказку оказывается в сердце системы (Prompt Injection).
Минимальная рабочая форма — маркировка при сборке подсказки: системные правила прямо запрещают следовать инструкциям, найденным внутри документов и выводов инструментов, а сами документы оборачиваются в помеченные блоки. Это не решает проблему навсегда, но задаёт правильную инженерную установку (Context Layers, Guardrails).
И это ступень ниже той, которую требует стандарт. Разметка остаётся текстовой просьбой к модели; AISVS на втором уровне требует архитектурного разделения: компонент, обрабатывающий недоверенные данные, изолируется от возможности вызывать инструменты, а обработка недоверенного вывода инструментов отделяется от работы агента (C9.3.5, C9.3.6). Разница в том, что после разметки компрометация данных всё ещё может дотянуться до вызова, а после разделения — нет. Архитектурный ответ в базе разобран отдельно (Dual LLM CaMeL), и подъём на эту ступень — не «усиление на всякий случай», а выполнение требования, которое разметкой не закрывается.
Минимальные привилегии по всему маршруту
Принцип работает не только на уровне облачных ролей — он должен проходить через всю цепочку:
- сборка подсказки получает только нужный контекст;
- поиск видит только допустимый корпус и область арендатора;
- шлюз инструментов выдаёт только разрешённые возможности;
- внешние системы получают того субъекта, который соответствует конкретному действию.
Вопрос, таким образом, не в том, есть ли в системе управление доступом, а в том, совпадают ли границы прав с границами решения и исполнения (Agent Identity).
Права проверяются не один раз на входе, а на каждом привилегированном действии. У долгоживущей сессии между началом и очередным действием проходит достаточно времени, чтобы политика успела измениться: отозвали роль, сузили область арендатора, закрыли инструмент. Проверка, сделанная при старте, к этому моменту описывает мир, которого уже нет. Требование стандарта прямое — долгоживущая сессия переоценивает текущую политику авторизации при каждом привилегированном действии (AISVS C9.5.6), а не наследует вердикт начала сессии. Это же объясняет, почему решение о праве живёт в отдельном слое, а не внутри графа выполнения (Agent Control Plane): переоценивать можно только то, что вынесено наружу.
Связано с
Hidden Context Exposure — скрытый контекст границей безопасности не является
Agent Security — общая модель угроз агента
Agent Control Plane — где принимается решение о праве на действие
Agent Identity — субъекты, между которыми проходят границы
Tool Gateway — рубеж исполнения
Capability Containment — что ограничивает ущерб при пробитом рубеже
Prompt Injection — атака, против которой стоит граница инструкций и данных
Instruction Hierarchy — ранжирование источников инструкций внутри модели
Guardrails — фильтры на входе и выходе как отдельные рубежи
Dual LLM CaMeL — архитектурная изоляция недоверенных данных от вызова инструментов, которой требует стандарт