Ограничьте полномочия агента

Опишите задачу до предоставления доступа

Агенту, который читает код, нужны другие полномочия, чем агенту, который развёртывает сервис. Не выдавайте оба набора прав только потому, что один продукт поддерживает оба действия.

Определяйте полномочия через три элемента: действие, ресурс и условие. В вымышленном примере исправления отчёта агент может записывать изменения в одну рабочую ветку, пока задача активна. Он может читать разрешённые файлы репозитория. Он не может изменять данные production или правила защиты репозитория.

Конкретный способ применения ограничений зависит от инструмента. Если токен не позволяет ограничить доступ одной веткой, используйте дополнительные настройки репозитория или сервис выполнения. Точно укажите, какие полномочия остаются у агента.

Обеспечьте ограничения вне модели

Промпт не является системой управления доступом. Компонент выполнения должен сверять запрошенное действие и целевой ресурс с текущими разрешениями. Он не должен принимать утверждение модели о том, что согласование уже получено.

AWS рекомендует ограничивать права и использовать временные учётные данные для соответствующих рабочих нагрузок. OWASP применяет тот же принцип минимальных привилегий к агентам и их инструментам. Эти принципы нужно реализовать в реальных системах управления доступом и выполнения. Рекомендации AWS IAM, рекомендации OWASP для агентов.

Используйте краткосрочные учётные данные, если система их поддерживает. Не помещайте в среду секреты, которые не относятся к задаче. Задача чтения репозитория не должна наследовать пароль базы данных production из командной оболочки разработчика.

Свяжите согласование с фактическим действием

Разрешение подготовить изменение не означает разрешения развернуть его. Решение о развёртывании должно указывать артефакт, целевую среду и применимые условия. Если они изменятся, прежнее решение может потерять силу.

Предположим, агент предлагает безопасное чтение базы данных, но после согласования выполняет другой запрос. Рабочий механизм согласования проверяет именно ту операцию, которая будет выполнена. Общее сообщение «продолжайте» без конкретной цели может скрыть это различие.

Также различайте инициатора и доступные действия. Записывайте, какой человек или какая рабочая нагрузка запустили выполнение. В момент действия проверяйте, сохраняются ли у инициатора нужные права. Отзыв доступа человека должен иметь явно определённое влияние на задачи в очереди.

Проверьте отказ и прерывание

Проверяйте не только успешный сценарий. В изолированной тестовой среде попытайтесь выполнить действие за пределами разрешённого ресурса. Убедитесь, что система выполнения отклоняет его. Изучите событие аудита, не записывая учётные данные.

Затем проверьте отмену или истечение срока действия учётных данных. Определите, какая работа прекращается сразу, а какая операция может завершиться. Кнопка остановки не обязательно отменяет действие, которое уже поступило в другую систему.

Храните краткую запись о разрешениях вместе с задачей. Укажите владельца, согласованный объём, фактические средства ограничения, проверку отказа и срок действия. Тогда последующий review даст достаточно конкретной информации для улучшения процесса.