Sandboxing, permission scoping, and least-privilege tools

Раз модель считается скомпрометируемой, задача — заранее ограничить радиус поражения удавшейся атаки. Sandboxing изолирует исполнение агента от остальной системы. Если агент выполняет код или команды, они должны идти в одноразовом контейнере или микро-VM с минимальной файловой системой, без доступа к секретам хоста, с квотами на CPU/память/время и, критично, с контролем сети.

Сетевая изоляция (egress control) здесь — половина дела. Даже идеально песочный код бесполезно изолирован, если из песочницы открыт весь интернет: это готовый канал эксфильтрации из прошлого урока. Практика — default-deny на исходящие соединения и allowlist только нужных адресов; всё остальное блокируется на сетевом уровне, а не «просьбой к модели».

Второй принцип — эфемерность: агент работает в свежем окружении, которое уничтожается после задачи, чтобы компрометация не переносилась между сеансами и пользователями. Anthropic и другие поставщики предоставляют исполнение инструментов/кода в изолированных песочницах именно по этим причинам. Для защитника sandbox — не «замена» контролю инъекций, а слой, который превращает успешную инъекцию из катастрофы в контролируемый инцидент: атакующий получил не хост и не сеть, а пустую одноразовую коробку.

Самый мощный рычаг безопасности агента — не в модели, а в наборе инструментов, которые вы ей дали. Принцип наименьших привилегий: агент получает ровно те возможности, что нужны его задаче, и ни одной сверх. Инструмент execute_sql(query) с произвольным запросом — это фактически полный доступ к базе; вместо него дайте узкие операции: get_order_status(order_id), list_user_invoices(user_id). Узкий инструмент валидирует аргументы детерминированным кодом и физически не способен сделать то, чего в нём не предусмотрено.

Разделяйте чтение и запись: read-only инструменты гораздо безопаснее и их можно давать щедрее. Опасные действия (удаление, отправка наружу, платёж, изменение прав) выносите в отдельные, редкие, обвешанные проверками инструменты. Полезная практика — allowlist инструментов на сценарий: агент поддержки не должен иметь в своём наборе инструмент деплоя, даже если технически мог бы.

Ключевая мысль: инструмент — это и есть граница безопасности, которую атакующий не перепишет инъекцией. Что бы модель ни «решила», она может вызвать только предоставленные функции с аргументами, которые пройдут вашу валидацию. Поэтому проектирование инструментов — это проектирование прав. Аудит начинается с вопроса к каждому инструменту: «что худшее сделает атакующий, полностью управляющий его аргументами?» — и если ответ пугает, инструмент надо сузить или закрыть гейтом.

Инструменты ходят во внешние системы под какими-то учётными данными — и здесь чаще всего прячется избыточная привилегия. Антипаттерн: единый сервисный токен с широкими правами, зашитый в агента; любая удавшаяся инъекция наследует всю его мощь. Правильный подход — минимальный скоуп и короткое время жизни. OAuth-скоупы выдаются под конкретную операцию (repo:read, а не repo), токены живут минуты, а не месяцы, и по возможности привязаны к ресурсу.

По возможности агент должен действовать от имени пользователя и в границах его прав (delegated access), а не под всемогущим сервис-аккаунтом. Тогда даже полностью захваченный агент не выйдет за пределы того, что дозволено этому пользователю, — цена инцидента резко падает. Секреты не кладут в промпт или в код инструмента: их держит окружение/секрет-менеджер, а инструмент получает уже готовый узкий токен.

Отдельно — идентичность и аудит: каждое действие агента должно быть атрибутируемо (какой агент, от чьего имени, каким токеном), чтобы при инциденте можно было мгновенно отозвать конкретные права. OWASP в редакции 2025 выделяет «Excessive Agency» (LLM06) как отдельный риск именно про избыток разрешений, автономности и функциональности. Скоупинг токенов — прямой ответ на этот риск: сузить полномочия так, чтобы даже полный контроль над моделью давал атакующему минимум.

Некоторые действия слишком опасны, чтобы доверять их автономному решению модели: перевод денег, удаление данных, рассылка внешним адресатам, изменение прав доступа, деплой в прод. Для них ставят human-in-the-loop — approval gate: агент готовит действие, но выполнение требует явного подтверждения человека, которому показывают, что именно и с какими аргументами будет сделано. Важно, чтобы решение принимал детерминированный код (это действие → нужен аппрув), а не сама модель решала, спрашивать ли разрешение.

Гейты стоит ставить по риску, а не на всё подряд: слишком частые подтверждения приучают людей нажимать «ок» не глядя (alert fatigue), и защита деградирует. Дизайн — редкие, но содержательные подтверждения на действительно необратимых операциях.

Архитектурный паттерн, снижающий число гейтов, — dual-LLM (Simon Willison). Привилегированная модель управляет инструментами, но не видит сырой недоверенный контент; карантинная модель обрабатывает недоверенные данные, но не имеет доступа к привилегированным инструментам. Между ними — строго типизированный, ограниченный интерфейс. Так недоверенный текст не может напрямую спровоцировать привилегированное действие. Вместе least privilege, скоуп токенов, sandbox, approval gates и dual-LLM образуют оборону, которая держится, даже когда модель обманута, — а мы уже приняли, что рано или поздно так и будет.