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