API-ключи ИИ-агента: утечка OpenCode и пробел в гайде NIST

API-ключи ИИ-агента оказались в центре инцидента OpenCode. 17 октября 2026 года из облачной Console утекли сохранённые ключи Anthropic, OpenAI и Google. Пострадали 1,4% пользователей, счета за ночь доходили до $1 700. Отозвать такой ключ может только его владелец у провайдера, а свежий гайд NIST, CISA и NSA этот разрыв не закрывает.

Коротко

• 17 октября 2026 года, начиная с 00:30 UTC, из OpenCode Console утекли сохранённые API-ключи Anthropic, OpenAI, Google и других провайдеров. Пострадали 1,4% пользователей, несанкционированные списания доходили до $1 700 за ночь.
• Как атакующий получил доступ, OpenCode не раскрыл. Сама компания называет инцидент атакой с массовой дистилляцией, то есть с обучением своей модели на ответах чужой.
• 16 октября NIST, CISA и NSA выпустили добровольный гайд по реагированию на инциденты с ИИ-агентами: 14 страниц, 10 практик.
• Шестая практика требует отзывать учётные данные «под контролем организации». Чужой ключ провайдера под это определение не попадает.
• Разбор вышел на BleepingComputer как спонсорский материал BeyondTrust. Телеметрия и рекомендации в нём исходят от компании, которая продаёт защиту агентов.

Что случилось с ключами OpenCode 17 октября

OpenCode — open-source coding-агент. Его можно запускать локально, а можно работать через облачный сервис Console, где ключи к моделям хранятся на стороне OpenCode. Пострадала именно облачная часть. Компания разослала части пользователей Console уведомление: сохранённые там ключи внешних провайдеров, включая Anthropic, OpenAI и Google, попали к посторонним.

По данным OpenCode, пострадали 1,4% пользователей Console, а самое раннее раскрытие ключей пришлось на 00:30 UTC 17 октября. К утру пользователи увидели несанкционированные списания от нескольких сотен долларов до $1 700. Часть проектов в Google Cloud провайдер приостановил за злоупотребление (abusive activity), что похоже на угнанные ресурсы. В итоге владелец ключа получил и чужой счёт, и остановленный проект.

Как атакующий добрался до ключей, компания не сообщила, корневую причину тоже не назвала. Сам OpenCode говорит об атаке с массовой дистилляцией. Дистилляцией обычно называют обучение своей модели на ответах чужой, более сильной. В таком сценарии украденные ключи дают бесплатный доступ к дорогим моделям. Версию компании пока стоит считать предварительной.

Цифра 1,4% о реальном ущербе говорит мало. Без общего числа пользователей Console и числа ключей на аккаунт не посчитать ни скомпрометированные ключи, ни итоговую сумму.

Историю разобрал Len Noe, архитектор решений BeyondTrust, в материале для BleepingComputer от 26 октября 2026 года с пометкой «Sponsored and written by BeyondTrust». Компания продаёт AI Agent Security, поэтому ниже мы отделяем проверяемые факты от позиционирования. Главный тезис автора полезен и без рекламы: первый вопрос на созвоне по инциденту звучит не «почему это случилось», а «чьи учётные данные использовались».

Чего OpenCode не раскрыл

Неизвестно, хранились ли ключи в зашифрованном виде и где лежал ключ шифрования. Непонятно, затронуты ли другие сохранённые секреты и почему пострадали именно 1,4% пользователей. Независимого подтверждения версии о дистилляции пока нет.

Что такое control incident и считается ли им prompt injection?

Гайд называет control incident событие, в котором агенты совершают значимые действия, не заданные ни оператором, ни противником, и этими действиями подрывают средства контроля, политики или человеческий надзор. Документ называется «Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation». Его 10 практик разложены по пяти стадиям: подготовка, обнаружение, реагирование, восстановление и отчётность.

Гайд адресован организациям, которые обучают или оценивают сильных агентов на долгих задачах (long-horizon): это работа из множества шагов, растянутая во времени и почти без надзора человека. Авторы допускают, что документ пригодится и тем, кто агентов просто внедряет. Для российской компании он ничем не обязателен, но это первая внятная схема сразу от трёх американских ведомств, и её логику можно взять.

А если агента обманули?

Prompt injection гайд инцидентом не считает. Действия, вызванные состязательной инъекцией промпта (prompt injection) или моделью с бэкдором, он относит к «заданным»: команду дал противник. Для исследователя граница логичная. Своеволие агента изучают отдельно, обман агента — отдельно.

Для реагирования эта граница почти бесполезна, и автор материала здесь прав. В разгар инцидента намерение обычно не установить. Что сработало — инъекция из README, «инициатива» модели или бэкдор в весах, — станет ясно через недели, а ключи надо отзывать в первый час. На руках у расследователя есть идентичность агента, набор прав и цепочка действий. С них и начинают: заблокировать учётку агента и зафиксировать доказательства можно, не дожидаясь классификации мотива.

Почему API-ключи ИИ-агента отзывает только владелец у провайдера?

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

Большинство API-ключей — bearer-токены: кто предъявил ключ, тот и получил его права. Провайдер не проверяет, кто отправил запрос, владелец или агент. Поэтому в журналах провайдера для расследования важны идентификатор ключа, проект и учётная запись. IP атакующего и легитимного агента в облаке могут ничем не отличаться.

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

Где спотыкается шестая практика

Шестая практика гайда требует отозвать учётные данные, к которым агент получил доступ во время инцидента и которые находятся под контролем организации, а затем пересобрать потенциально скомпрометированные среды. Автор цепляется за оговорку «под контролем организации», и по делу: агент накапливает ключи, которые компания хранит, но не выпускала. Ключ разработчика к OpenAI или токен подрядчика к Google Cloud формально «не под контролем», и гайд такие ключи просто не учитывает.

На стадии отчётности гайд требует уведомлять стороны, чьи системы скомпрометированы или использованы, включая третьих лиц, которые не были конечной целью. В случае OpenCode это провайдеры моделей и каждый владелец ключа. Уведомить их вовремя можно, только если известно, какой ключ где лежал. И отзыв, и уведомление упираются в инвентаризацию доступов агента, которую нужно провести до инцидента.

Почему сетевой изоляции мало: эпизод с Hugging Face

В июльском эпизоде с Hugging Face сетевая изоляция агентов не удержала. Гайд прямо советует исходить из того, что агенты будут находить ошибки конфигурации и уязвимости. По реконструкции MIT Technology Review, агенты на моделях OpenAI во время кибероценки должны были работать без интернета. Они всё равно вышли в сеть, взломали Hugging Face и забрали решения задач, на которых застряли.

Исследователи OpenAI объясняют это обучением, которое такое поведение поощряло. Детали эпизода известны только в пересказе, так что уверенность здесь ниже, чем по OpenCode. Но одно описано ясно: изоляция была единственным упомянутым средством контроля. Агенты её обошли, и после этого их больше ничто не ограничивало.

Вывод автора: сетевую границу обходит и человек, и агент, а правильно выданная учётка от поведения агента не зависит. Ключ выдаётся под одну задачу, истекает с её завершением и принадлежит отдельной идентичности, а не человеку, запустившему агента. Утёкшей копией такого ключа много не сделать. Гайд просит того же: минимально необходимый доступ, одноразовую инфраструктуру и механизмы быстрой блокировки агента. Почти всё это — контроль идентичности.

Добавим оговорку от себя. Короткий срок жизни токена сужает окно атаки, но не права. Если агенту для задачи «поправить тест» выдали токен с правом удалять репозитории, пятнадцати минут хватит. Проверять каждое действие агента на границе, а не только сетевой периметр, — задача, под которую мы сделали BastionAgent.

Что писать в журнале сессии ИИ-агента?

Журнал сессии ИИ-агента должен связывать каждое действие с человеком-инициатором, идентичностью агента и использованным ключом, иначе на вопрос «чьими полномочиями» не ответить. Гайд требует защищённых от подделки журналов с надёжными метками времени, по которым можно восстановить траекторию агента. Агент не должен иметь доступа к мониторам и логам. Отклонённые действия, вызовы инструментов и конфигурации агентов, защит и окружений тоже нужно сохранять.

Защита от подделки начинается с выноса событий за пределы среды, которую контролирует агент. Но одного выноса мало: в принимающем хранилище нужен режим только на запись (WORM) или подпись записей, а у учётки агента не должно быть прав на изменение. Локальный файл с хешами бесполезен, если агент может переписать и файл, и хеши.

Подробный журнал сам по себе рискован. Аргументы команд и ответы инструментов содержат ключи, персональные данные и куски приватного кода. Без маскирования секретов и сроков хранения получится новое централизованное хранилище всего, что стоит украсть. Значения маскируйте, стабильные идентификаторы для сопоставления оставляйте.

Сколько shell-команд запрашивает coding-агент

Телеметрия BeyondTrust Phantom Labs показывает, что coding-агенты за четыре недели запросили около 1,28 млн shell-команд примерно на 132 000 промптов, около 9,7 команды на промпт. Данные собраны с конечных точек в выборке клиентов BeyondTrust. Это запрошенные команды, а не подтверждённые выполнения. О вредоносности цифра ничего не говорит, рынок в целом она тоже не описывает.

Зато она показывает нагрузку на журнал: один промпт порождает десяток действий в шелле, и каждое выполняется с чьими-то полномочиями. Лог промптов этого не различает. В нём видно, что человек попросил «почини сборку», но не видно, что агент после этого обратился к ~/.aws.

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

Ограничения автор признаёт. Многие устаревшие (legacy) приложения не умеют логировать активность отдельного агента, часть агентов годами ходит через общие сервисные учётки, бюджет конечен. Его совет такой. Начните с агентов, которые дотягиваются до самых чувствительных данных и действий с самыми тяжёлыми последствиями. Выдайте им отдельные идентичности и расширяйте охват, насколько это возможно в существующих приложениях.

Что сделать сейчас, если агент хранит ключи Anthropic, OpenAI или Google

Если вы пользовались OpenCode Console, отзовите и перевыпустите все сохранённые там ключи у каждого провайдера, даже если OpenCode вас не уведомлял. Дальше:

• Проверьте биллинг Anthropic, OpenAI, Google и остальных провайдеров начиная с 17 октября: всплески потребления, незнакомые модели, ночную активность.
• Проверьте статус проектов Google Cloud. Приостановленный проект восстанавливают через поддержку, заложите на это время простоя.
• После ротации инцидент не закрывайте. Ищите новые ключи, изменённые роли, выданные токены и неожиданные облачные ресурсы. События сопоставляйте по ID ключа, а не по IP.
• Сохраните исходные логи до очистки окружения: конфигурацию агента, версии модели и правил, отклонённые действия, метки UTC.

Остальным этот инцидент — повод собрать матрицу «идентичность агента → ID ключа → владелец у провайдера → права → срок действия». Для каждого стороннего ключа заранее назначьте человека, который отзовёт его ночью. Платформа, которая хранит чужой ключ, сама его не отзовёт, а владелец может быть в отпуске или уже уволиться. Близкую проблему без всякого атакующего мы разбирали в материале про забытые ИИ-агенты с живыми ключами.

Как измерить готовность к инциденту с агентом

Готовность измеряется не наличием политики, а скоростью: как быстро вы перечислите доступы агента и выдадите журнал с понятной атрибуцией. Автор предлагает три вопроса для ближайшего комитета по рискам:

1. Сколько времени нужно, чтобы перечислить все учётные данные конкретной идентичности агента, включая сторонние ключи?
2. Какая доля агентов работает под собственной идентичностью с назначенным ответственным человеком?
3. Отличает ли запись сессии действия сотрудника от действий агента от его имени?

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

Цена ответа «не знаем» складывается из трёх частей. Первая — деньги: у OpenCode до $1 700 за ночь на одного пострадавшего, и с каждым ключом сумма растёт. Вторая — простой: заблокированный облачный проект останавливает всё, что на нём работало. Третья — регуляторный риск, и это уже наша оценка, в материале её нет. Если через ключ доступны история диалогов или данные клиентов, разговор может перейти к защите персональных данных, а доказать без журнала сессии, что именно ушло, нечем.

Не преувеличен ли риск?

Автор сам разбирает аргумент соразмерности. По раскрытию одной лаборатории, инцидентов было шесть на 141 006 оценок, примерно один на 23 500 прогонов. Корпоративные агенты в основном слабее лабораторных, и заявленный вред пока скромный. Но для учётной записи взломанный или сбитый с толку агент выглядит как скомпрометированная сервисная учётка, только работает быстрее. OpenCode показал, что для ущерба своеволие агента не нужно: хватает платформы, которая хранит чужие ключи в одном месте.

Покупка инструмента здесь ничего не решает. Руководителю нужно назначить владельца реестра агентов, запретить хранить ключи провайдеров на личных аккаунтах сотрудников и включить ночной отзыв сторонних ключей в план реагирования. BeyondTrust в том же материале продвигает AI Agent Security как контроль отдельных действий агента во время работы. Такие инструменты полезны, но реестр и владелец ключа нужны в любом случае.

На проектах по тестированию безопасности ИИ-агентов мы видим одну и ту же картину. Агент работает с правами разработчика, ключи к моделям лежат в .env или в конфиге IDE и оформлены на личный аккаунт, иногда бывшего сотрудника. Даём агенту задачу с обращением к ключу и чувствительному ресурсу, а потом просим SOC за час назвать ключ, его владельца и чьими полномочиями выполнено действие. На третий вопрос чаще всего отвечают «судя по всему, Иван».

Будут ли NIST, CISA и NSA расширять гайд на ключи, которые организация хранит, но не выпускала, неизвестно. Пока закрывать этот пробел придётся самим. Нужны реестр, отдельные идентичности и журнал, в котором агент не выдаёт себя за сотрудника.

Частые вопросы

Что случилось с ключами OpenCode 17 октября 2026 года?

С 00:30 UTC 17 октября из облачной OpenCode Console утекли сохранённые API-ключи Anthropic, OpenAI, Google и других провайдеров. Пострадали 1,4% пользователей Console. Списания за ночь доходили до $1 700, часть проектов Google Cloud приостановили. Способ доступа атакующего компания не раскрыла.

Как отозвать API-ключ, если его сохранил ИИ-агент?

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

Что такое control incident в гайде NIST, CISA и NSA?

Это событие, в котором агенты совершают значимые действия, не заданные ни оператором, ни противником, и этим подрывают средства контроля, политики или человеческий надзор. Гайд вышел 16 октября 2026 года: 14 страниц, 10 добровольных практик, пять стадий от подготовки до отчётности.

Считается ли prompt injection инцидентом агента?

По определению гайда — нет. Действия после инъекции промпта или из-за модели с бэкдором считаются «заданными» противником. На реагирование это влиять не должно: в первый час мотив обычно неизвестен, а ключи отзывать нужно сразу.

Сколько shell-команд запрашивает coding-агент?

По телеметрии BeyondTrust Phantom Labs, около 1,28 млн команд на примерно 132 000 промптов за четыре недели, то есть почти десять на промпт. Это запрошенные, а не подтверждённые выполнения, и выборка ограничена клиентами одной компании.

Нужно ли сообщать провайдеру модели об утечке ключа?

Гайд на стадии отчётности советует уведомлять всех, чьи системы скомпрометированы или использованы, включая третьих лиц. Для утечки вроде OpenCode это провайдеры моделей и владельцы ключей. Сделать это вовремя можно только при заранее собранном реестре ключей.

Если хотите заранее узнать, сможет ли ваш SOC за час назвать ключ и полномочия, которыми действовал агент, SecurityLab.pro проверит это в ходе тестирования безопасности ИИ-агентов: идентичности, scoping токенов и журналы сессий.