Docker считает, что обычных политик безопасности для ИИ-агентов уже мало: когда агент сам запускает команды, ходит в Jira и использует доступы к облаку, контроль нужен не в регламенте, а прямо в среде исполнения. Для команд, которые уже делегируют агентам куски разработки и поддержки, это практичный список того, что стоит ограничить заранее, а не после первого инцидента.
Проблема не в правилах, а в их исполнении
В свежем материале Docker разбирает сдвиг, который многие команды уже почувствовали на практике: часть работы уходит за пределы привычных точек контроля вроде репозитория, CI/CD и среды деплоя. Агент может читать файлы, менять код, ставить зависимости, дергать внешние API и выполнять команды еще до того, как человек увидит итоговый результат.
Отсюда и главная мысль статьи: написать политику недостаточно. Как формулирует Docker, подсказка может повлиять на поведение агента, но только среда исполнения может это поведение ограничить. Разница не академическая: именно она отделяет «умного помощника» от автоматизации, которая однажды полезет туда, куда ее никто не звал.
Три границы контроля
Граница выполнения. Речь о том, что агенту вообще разрешено делать: читать и менять файлы, запускать команды, устанавливать пакеты, открывать сетевые соединения. Если таких рамок нет, агент получает слишком много свободы в рабочем окружении разработчика.
Граница инструментов. Современные агенты работают не только с локальным кодом. Они общаются с Git-платформами, таск-трекерами, внутренними API, облачными сервисами и базами данных. Поэтому контроль нужен не только над командами в терминале, но и над тем, к каким внешним инструментам агент вообще подключен.
Граница учетных данных. Самый чувствительный слой — доступы. Вопрос не только в том, может ли агент использовать токен или ключ, но и в том, как этот доступ ограничен, наблюдаем и проверяем по журналам. Чем больше автономности у агента, тем дороже ошибка в правах доступа.
Практический смысл для команд
Для русскоязычных команд разработки и ИБ здесь довольно приземленный вывод: внедрение ИИ-агентов быстро упирается не в качество модели, а в архитектуру ограничений. Если агенту дают доступ к рабочему ноутбуку, внутренним сервисам и корпоративным учетным данным без внятных границ, проблема уже не в «галлюцинациях», а в обычной операционной безопасности.
На этом фоне позиция Docker выглядит как попытка превратить безопасность агентов в инфраструктурную задачу, а не в набор предупреждений для разработчиков. Это особенно актуально для компаний, которые тестируют агентные сценарии в DevOps, поддержке и внутренней автоматизации: чем раньше команда разделит права на выполнение, доступ к инструментам и работу с учетными данными, тем меньше шанс, что эксперимент внезапно станет разбором инцидента.
Оригинал: Docker — Runtime Enforcement, Not Runtime Advice.
Следующий шаг в этой серии Docker обещает посвятить тому, как встроить такие ограничения в повседневную работу команд, а не оставить их красивой схемой на слайде.