Почему агент увеличивает поверхность утечки
Обычное приложение вызывает заранее известные API. Агент динамически выбирает инструменты, обрабатывает недоверенный контент и генерирует параметры. Если постоянный токен попал в контекст, модель может случайно вывести его пользователю или подчиниться внедрённой инструкции. Секрет нельзя сделать безопасным одной фразой в system prompt.
Инвентаризация и классификация
Соберите реестр: владелец, провайдер, environments, scope, срок жизни, где используется и как отзывается. Отдельно отметьте ключи, позволяющие финансовые операции, публикацию, доступ к персональным данным и создание новых credentials. Неизвестный секрет невозможно ротировать уверенно.
Workload identity вместо общего ключа
Worker аутентифицируется своей машинной identity. Она не равна пользователю и не должна быть общей для всего кластера. Policy связывает workload, tenant, workflow и разрешённое действие. Если облако поддерживает federation, избегайте статических ключей в конфигурации.
Secret broker и capability
Модель формирует структурированный запрос на действие. Broker валидирует schema, права, resource scope, approval и лимиты. Предпочтительный вариант — broker сам вызывает внешний API, поэтому credential никогда не покидает доверенный процесс. Если token нужен sandbox, он короткоживущий, audience-bound и минимального scope.
Доставка секрета
Не запекайте ключ в image и не кладите в репозиторий. Монтирование файла обычно лучше переменной окружения для процессов с широким доступом к environment, но само по себе не решает права. Volume должен быть доступен только конкретному workload, а обновление — происходить без публикации значения в rollout logs.
Логи, traces и ошибки
Redaction выполняйте на входе наблюдаемости. Маскируйте Authorization, cookies, query parameters, tool arguments и stdout subprocess. Не включайте секрет в exception. Для поиска утечек применяйте известные префиксы и entropy detection, но не отправляйте найденное значение в alert.
Rotation и отзыв
Rotation — проверяемая операция: создать новый credential, распространить, подтвердить использование, отключить старый и проверить ошибки. Для критичных провайдеров подготовьте emergency revoke без релиза приложения. Short-lived token уменьшает окно риска, но не отменяет немедленное прекращение текущих sessions.
Контрольный сценарий
Сымитируйте публикацию ключа в trace: обнаружение должно создать инцидент, отозвать credential, найти все обращения по его идентификатору, выпустить замену и подтвердить отсутствие значения в кэшах и backup-процессах. Если команда не может выполнить это по runbook, система ещё не готова к автономным действиям.
Матрица полномочий инструментов
Опишите не «доступ к GitHub», а конкретные capabilities: прочитать issue одного репозитория, создать ветку, открыть pull request, но не менять protected branch. Scope включает ресурсы, методы, объём, tenant и время. Модель выбирает capability, а сервер добавляет identity и проверяет policy.
Bootstrap: первый секрет
Даже vault требует начальной аутентификации. Предпочитайте identity платформы: service account, managed identity или workload federation. Если bootstrap credential неизбежен, доставляйте его отдельным защищённым каналом, ограничивайте одной средой и делайте короткоживущим. Не копируйте production credential в CI variables всех проектов.
План утечки по минутам
Первые действия: отключить credential, остановить затронутый workflow и сохранить evidence без распространения значения. Затем определить права ключа, время экспозиции и обращения по audit ID; выпустить замену и проверить зависимые сервисы. После восстановления удалите секрет из истории репозитория, артефактов и логов там, где это допустимо, и добавьте детектор причины утечки.