Разделите три идентичности
В журнале должны различаться человек, программный агент и выполняющая среда. Человек формулирует намерение и несёт бизнес-ответственность, агент выбирает шаги, а среда предоставляет вычисления и доступ к инструментам. Если все три представлены одним техническим пользователем, невозможно понять, было ли действие запрошено, самостоятельно выбрано или выполнено после компрометации узла.
У агента должна быть стабильная идентичность, версия и владелец. Сессия дополнительно связывается с инициатором, целью задачи и сроком действия полномочий.
Делегируйте минимальную возможность
Передавайте не копию пользовательского токена, а ограниченное право: прочитать определённую папку, подготовить черновик заявки или выполнить операцию в заданном диапазоне. Политика учитывает ресурс, действие, время, контекст и допустимую цепочку передачи прав.
Если агент вызывает подагента, новое полномочие не может быть шире исходного. Запреты и срок действия наследуются, а каждое звено цепочки остаётся видимым для аудита.
Требуйте подтверждение по риску
Низкорисковые чтения могут выполняться автоматически. Изменение записи допускает последующую проверку, а платёж, удаление, публикация или выдача доступа требуют явного подтверждения. В интерфейсе подтверждения показывают не общий вопрос «продолжить?», а объект, действие, последствия и источник запроса.
Полезны лимиты количества операций, суммы, получателей и времени. Даже корректно авторизованный агент не должен бесконечно повторять ошибочное действие.
Сохраняйте доказуемую цепочку
Аудит связывает инициатора, агента, модель и конфигурацию, входные данные, полученное полномочие, вызовы инструментов и результат. Секреты и лишние персональные данные исключаются, но решение политики и подтверждение человека сохраняются неизменяемо.
Процедура отзыва должна останавливать активные задания, аннулировать производные токены и переводить интеграции в безопасный режим. Такой подход превращает агентную систему из «умной сервисной учётки» в управляемого участника процесса.