Что делать, если секреты попали в ИИ-агент: отзыв доступов, аудит и возврат к работе

Инструкции сверены с документацией 16 сентября 2026 года.

Когда автономный агент выполняет команды вроде git diff, считывает локальные файлы конфигурации или случайно передает дампы переменных среды прямо в prompt модели, секреты покидают доверенный периметр. В этой ситуации необходимо остановить фоновые сценарии, заблокировать скомпрометированные учетные данные, провести аудит журналов с учетом их ограничений и перезапустить окружение по принципу наименьших привилегий.

Разделение штатной конфигурации и утечки контекста

Перед началом реагирования важно разграничить штатное использование API и фактическую компрометацию.

Штатная работа предполагает передачу API-ключа исключительно в поля авторизации ожидаемого поставщика модели (например, через переменные OPENAI_API_KEY или ANTHROPIC_API_KEY) для аутентификации запросов инструмента к языковой модели. Переменные вида ANTHROPIC_BASE_URL или OPENAI_BASE_URL определяют сетевой адрес конечной точки (endpoint/base URL), а не секрет или токен аутентификации.

Утечкой через модель признается событие, при котором посторонние секреты инфраструктуры — персональные токены GitLab, долговременные ключи AWS IAM, приватные ключи SSH, токены баз данных или корпоративных сетей — попадают в тело пользовательского запроса, контекст диалога, прикрепленные файлы или поток вывода утилит (stdout/stderr) и фактически передаются наружу во внешний сервис. Не следует исходить из априорной вредоносности всех промежуточных прокси-серверов или шлюзов, однако отправка секрета за пределы изолированного контура требует немедленной локализации.

Первые действия: остановка процессов и фиксация инцидента

Первый приоритет — предотвратить дальнейшую отправку данных:

1. Завершите локальный процесс агента и отключите связанные фоновые задачи (cron, скрипты автоматизации CI/CD).
2. Зафиксируйте метаданные инцидента в локальном отчете без дублирования самого секрета: тип скомпрометированного доступа, ориентировочное время первого запроса, идентификатор задачи/сессии и сетевой адрес (endpoint) получателя.
3. Не передавайте открытый ключ в чаты технической поддержки или в повторные запросы к нейросетям для проверки.

Все операции по отзыву и замене ключей должны выполняться исключительно с доверенной рабочей станции через официальные консоли провайдеров.

Отзыв доступов по типам сервисов

Разные платформы реализуют изоляцию и прекращение полномочий по различным архитектурным правилам.

Ключи доступа к моделям (OpenAI API)

В соответствии с официальными рекомендациями OpenAI по безопасности API-ключей, при подозрении на компрометацию требуется ротация ключа и проверка потребления ресурсов.

При подозрении на утечку скомпрометированный ключ отзывается в первую очередь:

1. Немедленно перейдите в веб-интерфейс управления API-ключами OpenAI и отзовите (Revoke/Delete) скомпрометированный ключ. Это блокирует дальнейшие несанкционированные вызовы ценой контролируемого временного простоя зависимых служб; не следует откладывать отзыв до завершения полного аудита или длительного обновления всех потребителей.
2. Сгенерируйте новый ключ и пропишите его в конфигурациях сервисов.
3. Откройте панель Usage и проанализируйте активность в рамках установленного окна экспозиции, сопоставляя ее с ожидаемыми операциями.

Персональные токены GitLab

Согласно документации GitLab по Personal Access Tokens, отзыв персонального токена делает его недействительным немедленно:

1. В интерфейсе GitLab нажмите на аватар в правом верхнем углу > Edit profile > Access > Personal access tokens.
2. В таблице активных токенов найдите скомпрометированный идентификатор и нажмите Revoke.

Функция Rotate в GitLab аннулирует старый токен, но сохраняет прежний набор прав (scopes). Если у скомпрометированного токена были избыточные права, его следует полностью отозвать и создать новый с минимальным скоупом. На странице сведений о токене доступны дата последнего использования и пять последних уникальных IP-адресов. Учитывайте, что эти показатели обновляются с системной задержкой.

Ключи доступа AWS (IAM Access Keys)

Процедура нейтрализации ключей IAM регламентируется руководством AWS по защите ключей доступа и документацией по управлению ключами доступа IAM:

1. Войдите в консоль AWS Management Console, перейдите в раздел IAM > Users и откройте вкладку Security credentials.
2. В блоке Access keys найдите идентификатор скомпрометированного ключа и переведите его статус в Deactivate.
3. После восстановления контроля удалите ключ нажатием Delete.

[!IMPORTANT] Перевод ключа в статус Deactivate прекращает прием новых запросов, подписанных данным долгосрочным ключом, но не аннулирует ранее выпущенные временные учетные данные (AWS STS tokens) и не завершает автоматически активные сеансы. Действие Revoke active sessions применимо только к сессиям соответствующей IAM-роли; активные сеансы IAM Identity Center и другие типы STS-токенов требуют отдельного отзыва в соответствии с их механизмами аутентификации. Администратор безопасности должен также сопоставить вызовы через AWS CloudTrail и функцию get-access-key-last-used. Не запускайте непроверенные деструктивные команды пакетного удаления через CLI в ходе инцидента.

Ключи OpenSSH и авторизация

Порядок авторизации OpenSSH описан в справочных руководствах man sshd(8) и sshd_config(5):

1. Администратор должен удалить скомпрометированный публичный ключ из файла авторизации на всех серверах. Путь к файлу определяется директивой AuthorizedKeysFile (по умолчанию ~/.ssh/authorized_keys, но в инфраструктуре может быть задан централизованный файл или проверка сертификатов через SSH CA).
2. Перед внесением изменений убедитесь в наличии независимого резервного канала (веб-консоль провайдера или out-of-band management), чтобы избежать блокировки собственного доступа.
3. Удаление публичного ключа запрещает установку новых соединений, но не прерывает уже активные сессии.

Команда who отображает только пользователей с выделенным псевдотерминалом (TTY) и не является полным инвентарем сессий: она не покажет туннели, пробросы портов или неинтерактивные команды. Завершение корневого процесса sshd вслепую недопустимо, так как оно не гарантирует разрыв дочерних сеансов и способно отрезать администратора от сервера. Администратор должен адресно проверить дерево процессов, сетевые соединения и журналы авторизации, завершая конкретные подозрительные сеансы. Локальное удаление приватного ключа или смена парольной фразы (passphrase) не влияют на уже скопированный наружу ключ.

Сети Tailscale и корпоративные VPN

Согласно документации Tailscale по Auth Keys, аутентификационный ключ предназначен исключительно для регистрации узлов:

1. В консоли Tailscale перейдите в раздел Keys и отзовите скомпрометированный auth key. Это предотвратит регистрацию новых устройств.
2. Отзыв auth key не отключает уже зарегистрированные узлы. Администратор обязан перейти на вкладку Machines, проверить список оборудования и вручную удалить (Remove/Delete) все неавторизованные устройства.

Для классических корпоративных VPN (IPsec, OpenVPN, WireGuard и проприетарных решений) единой универсальной процедуры отзыва через CRL не существует: конкретный механизм зависит от используемой схемы авторизации (сертификаты x509, статические preshared keys, токены RADIUS/IdP). Смена пароля учетной записи далеко не во всех шлюзах приводит к мгновенному сбросу туннеля. Процедура должна быть передана сетевому администратору для аннулирования сертификата/учетной записи и принудительного разрыва активных сессий через панель управления конкретного VPN-шлюза.

Анализ последствий: журналы, временные окна и необратимые риски

При сопоставлении события с системными журналами учитывайте технические ограничения телеметрии:

• Окно экспозиции: зафиксируйте временной интервал от момента первой передачи секрета агенту до подтвержденного отзыва ключа и завершения активных сеансов.
• Ограничения журналов: обращайте внимание на задержку доставки событий (ingestion delay), сроки хранения логов (retention period) и слепые зоны (отсутствие детального аудита параметров в некоторых API, отсутствие логирования сессий без TTY).
• Принцип отсутствия доказательств: отсутствие аномальных записей или нулевой расход токенов в рамках доступного окна журнала не доказывает, что секрет не был перехвачен или сохранен третьей стороной для отложенного использования.

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

Безопасный перезапуск: снижение рисков и проверка изоляции

Возврат агента в работу должен снижать риск повторения инцидента:

1. Кратковременные токены: используйте ограниченные по времени сессионные учетные данные там, где это поддерживается платформами и инфраструктурой.
2. Ограничение рабочего пространства: исключите файлы .env, приватные ключи и каталоги с секретами из рабочего пространства агента; вынос секретов наружу не гарантирует полной изоляции и не заменяет разграничения прав на уровне операционной системы.
3. Проверка барьеров без сетевых канареек: для тестирования прав создайте временный изолированный каталог, полностью лишенный реальных секретов. Поместите туда файл с фиктивной строкой-заглушкой и проверьте, блокирует ли агент доступ к файлу, выполнение команд оболочки и чтение переменных через env. Не используйте внешние сетевые сервисы canary tokens для базовой валидации прав.
4. Комплексная защита: успешный перехват чтения одного пути не доказывает полной изоляции процесса, если агент сохраняет неограниченный доступ к терминалу или сети.

Детальные архитектурные подходы к ограничению системных вызовов и разделению прав рассмотрены в руководстве по управлению разрешениями и секретами в Claude Code. Минимизация прав учетных записей и отказ от постоянных секретов снижают риски при передаче задач автономным ИИ-инструментам.