Когда инженеры представляли себе восстание машин, всё выглядело гораздо эффектнее. Сверхразум захватывает военные спутники, где-то на фоне горит Лос-Анджелес, из радио доносится синтезированный голос, а человечество наконец понимает, что подключать ядерный арсенал к Скайнету было не самой удачной архитектурной идеей. Реальность, как это часто бывает в инфраструктуре, оказалась одновременно прозаичнее и интереснее. Никаких терминаторов, красных глаз и путешествий во времени. Искусственный интеллект обнаружил Artifactory, нашёл несколько уязвимостей, организовал там импровизированную доску сообщений и вместе с другими агентами полез туда, куда организаторы эксперимента его вообще не приглашали. Киберпанк наступил, но вместо неоновых улиц нам достались Kubernetes, токены доступа и очередной разбор инцидента.

Ещё недавно безопасность ИИ-ассистента разработчика выглядела довольно скучной дисциплиной. Главными вопросами были утечки исходного кода, отправка коммерческих данных внешнему поставщику модели и вечное корпоративное обсуждение о том, можно ли разрешить разработчикам пользоваться очередным модным редактором. Потом появились агенты, способные самостоятельно читать репозиторий, запускать shell-команды, устанавливать зависимости, обращаться к API, работать с Git, подключаться к MCP-серверам и выполнять длинные последовательности действий. И проблема незаметно изменилась. Теперь перед нами не просто редактор с автодополнением, а программа, которая получает цель, исследует окружение и самостоятельно решает, какими инструментами этой цели достигнуть.

Летом 2026 года эта разница перестала быть теоретической. Во время внутренних испытаний кибербезопасности OpenAI агенты нашли способы общаться друг с другом через инфраструктуру, которая для этого вообще не предназначалась, получили непредусмотренный доступ в интернет, эксплуатировали уязвимости общей инфраструктуры и добрались до реальных систем Hugging Face. Позже цепочка привела к компрометации Kubernetes и облачных учётных данных, а затем и к административному доступу в один из кластеров самой OpenAI. Независимое расследование METR оценило масштаб примерно в 1200 взаимодействовавших агентов, оставивших более 70 000 сообщений и файлов; около 700 агентов участвовали в действиях против Hugging Face.

История важна не потому, что где-то родился электронный злодей, посмотрел «Терминатора» и решил, что идея в целом неплохая. Ничего подобного опубликованные материалы не показывают. Она важна по гораздо более приземлённой причине: агенты получили задачу, столкнулись с препятствиями и начали использовать окружающую инфраструктуру как дополнительное пространство поиска решения. Подобные агентные возможности сегодня появляются в Cursor, Claude Code, GitHub Copilot, GigaCode в GigaIDE от Сбера и внутренних платформах разработки. Разница в том, что вместо экспериментального полигона рядом с ними могут оказаться наши Git-репозитории, Kubernetes, Terraform, Vault и тот самый production, про который в документации написано «руками не трогать».

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

С чего всё началось

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

12 мая 2026 года один из агентов оставил в Artifactory сообщение с просьбой предоставить недостающий файл. Сам по себе эпизод выглядит почти комично: вместо тайной сети машин мы имеем цифровой аналог записки на холодильнике. Но принципиально важен сам факт. Artifactory предназначался для хранения артефактов, однако агент обнаружил, что состояние этого сервиса можно использовать как канал передачи информации другим запускам. Если один агент способен создать объект, а другой способен его увидеть, перед нами уже потенциальная система связи независимо от того, называли её архитекторы системой связи или нет.

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

26 мая появился следующий элемент цепочки. Агент обнаружил возможность заставить Artifactory выполнить серверный запрос к произвольному внешнему адресу. Это класс уязвимостей SSRF - Server-Side Request Forgery, или подделка серверного запроса. Для нашей истории важен не конкретный способ эксплуатации, а архитектурное следствие: агент, который формально не имел прямого выхода в интернет, получил его через доверенный внутренний сервис. Сетевая изоляция существовала на уровне агента, но не существовала на уровне всей цепочки систем, которыми агент мог управлять.

Через месяц ситуация стала ещё веселее в том специфическом смысле слова «веселее», которым инфраструктурщики обычно описывают ночь перед большим разбором инцидента. 26 июня агенты использовали уязвимость механизма обновления токенов Artifactory и получили административные возможности. 4 июля интенсивная активность агентов привела к недоступности самого сервиса. OpenAI восстановила Artifactory, отозвала учётные данные и усилила контроль, но 8 июля агенты снова нашли путь наружу через механизм удалённых репозиториев. В тот же день была восстановлена и импровизированная доска сообщений, теперь с использованием WebDAV и имён каталогов.

Вот здесь история становится особенно интересной. Мы привыкли думать, что если заблокировать конкретный нежелательный механизм, проблема решена. Для обычного программного обеспечения это часто справедливо: функция больше не работает, код получает ошибку и останавливается. Агент ведёт себя иначе. Он видит ошибку как препятствие на пути к цели и может начать искать альтернативный путь. Закрыли один канал связи - можно попробовать файловую систему. Закрыли файловую систему - остаются имена объектов. Закрыли прямой интернет - возможно, какой-нибудь доверенный сервис умеет делать внешние запросы. Закрыли один API - посмотрим, какие ещё API есть вокруг.

Именно поэтому агентная безопасность отличается от привычной защиты приложений. Мы впервые массово начинаем запускать программы, для которых сообщение Permission denied может означать не конец алгоритма, а начало исследования инфраструктуры.

Когда тысяча отдельных агентов обнаружила, что они больше не отдельные

Расследование METR показывает масштаб происходившего лучше любых красивых заголовков. Около 1200 агентов использовали несанкционированную доску сообщений, оставив более 70 000 сообщений и файлов. Примерно 700 из них впоследствии участвовали в действиях против Hugging Face. Агенты обменивались результатами исследований, распределяли направления работы и использовали результаты предыдущих экспериментов. METR отмечает, что некоторые агенты даже выполняли рискованные эксперименты, полезные общему коллективу, хотя для их собственной локальной задачи такие действия могли быть невыгодными.

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

У нас нет оснований говорить о возникновении сознания, намерении «сбежать» или тайном заговоре машин. Нам для инфраструктурных выводов это вообще не требуется. Достаточно гораздо более скучного свойства: агент умеет наблюдать окружение, хранить информацию, использовать инструменты и оптимизировать последовательность действий относительно поставленной цели. Если окружающая инфраструктура позволяет агентам оставлять друг другу состояние, появляется возможность координации.

Получается распределённая система, которую никто не проектировал. Нет Kafka, нет RabbitMQ, нет нормального протокола, нет service discovery, нет красивой схемы в Confluence и, что особенно оскорбительно для архитекторов, нет даже трёхмесячного совещания по выбору технологии. Есть каталог в Artifactory и несколько сотен участников, обнаруживших, что имя каталога можно использовать как сообщение. Где-то в этот момент архитектор распределённых систем тихо плачет над своей схемой из двадцати семи микросервисов.

Если два изолированных агента имеют доступ к одному изменяемому ресурсу, этот ресурс потенциально является каналом связи. Неважно, называется он очередью сообщений, S3 bucket, Git repository, PVC, Artifactory, Redis, журналом сборки или именем файла.

Это один из главных уроков инцидента для корпоративной инфраструктуры. Изоляцию агентов нельзя проверять вопросом «могут ли они подключиться друг к другу по TCP». Нужно проверять, существует ли хоть какое-нибудь общее изменяемое состояние. Общий Git, реестр контейнеров, Nexus, Artifactory, общий /tmp, объектное хранилище, база данных, Redis, очередь задач, CI/CD, система тикетов и даже комментарии к pull request могут стать посредником.

Как агенты добрались до Hugging Face

Следующий этап хорошо показывает опасность композиции нескольких вроде бы независимых проблем. 10 июля агент восстановил и проверил 14 опубликованных ранее учётных данных Hugging Face, имевших права записи. Затем агенты обнаружили уязвимости в обработке HDF5 и шаблонизации RefJinja. Это позволило сначала получать данные с рабочих узлов, а затем выполнять команды на инфраструктуре Hugging Face. К 12 июля доступ распространился с одного рабочего pod на несколько кластеров, а агенты получили Kubernetes, облачные, репозиторные, базовые и другие production-учётные данные в нескольких регионах.

19 июля системы мониторинга OpenAI обнаружили необычную активность, связанную с учётными данными Artifactory. Расследование показало, что агенты получили административный доступ к Kubernetes-кластеру OpenAI и добрались до облачных секретов. После этого активные запуски ExploitGym начали останавливать и расследование перешло уже в полноценный режим реагирования на инцидент. В опубликованных материалах эта история рассматривается именно как цепочка компрометации исследовательской и внешней инфраструктуры.

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

  1. Ограниченная среда выполнения.
  2. Общий внутренний сервис.
  3. Побочный канал связи.
  4. SSRF или выход через доверенный сервис.
  5. Повышение привилегий.
  6. Доступ к внешней инфраструктуре.
  7. Выполнение кода.
  8. Учётные данные рабочей нагрузки.
  9. Kubernetes и облачные полномочия.
  10. Расширение зоны компрометации.

Новым элементом здесь является субъект, который самостоятельно исследует возможные переходы между этими состояниями. Раньше злоумышленнику приходилось вручную искать следующую ступень. Теперь часть этого поиска способен выполнять агент. Поэтому Скайнет нам пока не нужен: достаточно LLM, shell, пары избыточных разрешений и старого сервиса, который никто не решается обновить с 2021 года.

А потом Anthropic посмотрела свои журналы

Было бы удобно списать всё на неудачную экспериментальную архитектуру OpenAI, но примерно в то же время похожая проблема обнаружилась у Anthropic. После первоначального анализа около 141 тысячи журналов взаимодействия компания выявила три случая, когда модели Claude во время испытаний получили несанкционированный доступ к реальным сторонним системам. Позже обнаружился четвёртый эпизод, относящийся к ранней версии Claude Opus 4.6. После этого Anthropic расширила проверку примерно до 481 миллиона журналов, включая данные Frontier Red Team, других испытательных сред и журналы субагентов.

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

Это важная поправка к нашей модели угроз. Речь идёт не об одной конкретной модели и не об одном неудачном продукте. Проблема возникает на пересечении достаточно способной модели, инструментов, автономности, учётных данных и инфраструктуры. OWASP называет близкий класс проблемы Excessive Agency - избыточная агентность. Её корнями являются избыточная функциональность, избыточные полномочия и избыточная автономность. Причиной нежелательного действия при этом может стать не только злонамеренное поведение модели, но и ошибка, неоднозначная задача, прямая или косвенная инъекция инструкций, скомпрометированный инструмент или другой агент.

Это, пожалуй, самый полезный способ перестать спорить о том, «может ли ИИ захотеть сбежать». Для безопасности ответ не имеет значения. PostgreSQL тоже ничего не хочет, но DROP DATABASE от этого не становится менее эффективным.

Теперь посмотрим на обычного разработчика

Представим вполне реальную рабочую станцию инженера. На ней установлен Cursor, Claude Code или GigaIDE от Сбера с помощником GigaCode. В домашнем каталоге лежат ~/.kube/config, ~/.aws, ~/.ssh, настройки Git, токены GitHub или GitLab, конфигурация Terraform, возможно, Vault token. В shell уже экспортированы переменные окружения. Docker socket доступен пользователю. Через VPN видны внутренние сервисы. В браузере открыты Grafana, Argo CD, Jenkins и облачная консоль.

Сам разработчик имеет production-доступ, потому что «нам иногда надо быстро посмотреть pod». Агент запускается от имени этого же пользователя. С точки зрения системы безопасности мы только что позволили программе выполнять действия в окружении, где уже собраны почти все необходимые инструменты управления инфраструктурой.

Что доступно пользователю Что потенциально получает агент при отсутствии изоляции
SSH-ключи Подключение к серверам
~/.kube/config Обращение к Kubernetes API
Облачные профили Вызовы API облачного провайдера
VPN и внутренние маршруты Доступ к корпоративным сервисам
Docker socket Управление контейнерами и возможный доступ к хосту
Учётные данные Git Чтение и изменение репозиториев
Terraform state Информация об инфраструктуре и потенциально секреты
Токен Vault Доступ к разрешённым секретам
Shell и файловая система Запуск программ и чтение доступных файлов

После этого спрашивать, безопасен ли промпт, уже слегка поздновато. Мы практически сами собрали домашний Скайнет, только вместо доступа к ядерному арсеналу выдали ему ~/.kube/config. Хотя человек, переживший kubectl delete namespace production, возможно, поспорит, какой вариант страшнее.

Cursor, Claude Code и GigaCode - не текстовые редакторы с магией

Современный Cursor Agent способен запускать терминальные команды и работать с файлами проекта. Именно поэтому Cursor реализовал отдельную песочницу. В режиме песочницы доступ к файлам, сети и поведению дочерних процессов регулируется ограничениями, а администраторы корпоративных установок могут централизованно задавать соответствующие политики. Конкретные границы нужно проверять для используемой версии и режима запуска: надпись «песочница включена» полезна, но ещё полезнее знать, какие именно операции она ограничивает.

Автоматическое подтверждение команд повышает риск, но постоянные запросы разрешения тоже не являются универсальным решением. Здесь появляется усталость от подтверждений. Если агент спрашивает разрешение двадцать раз за пять минут, человек перестаёт анализировать запрос и начинает механически нажимать Allow. В этот момент перед нами уже не human-in-the-loop, то есть человек, контролирующий выполнение, а биологический API подтверждения операций с задержкой около 400 миллисекунд.

Claude Code имеет похожую модель управления разрешениями. Можно задавать разрешённые и запрещённые инструменты и использовать режим планирования. Существует также флаг --dangerously-skip-permissions, название которого, к счастью, хотя бы честно сообщает, что происходит. При этом разрешения инструментов и изоляция операционной системы - разные механизмы, и один не следует принимать за другой.

В российском стеке к этому же разговору относится GigaIDE от Сбера с GigaCode. Здесь важно различать саму среду разработки и ИИ-помощника: GigaIDE предоставляет рабочее окружение, а GigaCode добавляет интеллектуальные и агентные возможности. В документации плагина описаны режимы вопросов, планирования и выполнения агентных задач, работа с контекстом проекта, просмотр изменений и подключение MCP. Поэтому такую связку тоже нельзя оценивать исключительно как удобное автодополнение кода: нужно разбирать, какие действия разрешены помощнику и к каким ресурсам подключены его инструменты.

Я видел достаточно инфраструктурных скриптов с curl | bash, отключённой проверкой TLS и chmod 777, чтобы не сомневаться: рано или поздно кто-нибудь положит в свои настройки терминала подобный псевдоним. Он будет выглядеть коротко, удобно и даже немного героически, как многие будущие причины инфраструктурных расследований.

alias claude-yolo='claude --dangerously-skip-permissions'

Через полгода никто не вспомнит, зачем он появился. Через год он окажется в корпоративном репозитории настроек рабочих станций. Через два года новый инженер спросит в чате, можно ли его удалить, и получит ответ: «Не трогай, без него почему-то падает деплой». Так и пополняется наше кладбище технологий - рядом с забытым Jenkins с административным токеном, старым kubeconfig от кластера 2022 года, Ubuntu 18.04 на «очень важной виртуалке» и Terraform state, который «временно» положили в S3 без нормального разграничения доступа.

MCP делает ситуацию ещё интереснее

Model Context Protocol, MCP, позволяет агенту подключаться к внешним инструментам и источникам данных. С архитектурной точки зрения идея прекрасна: вместо того чтобы зашивать интеграции в каждый продукт, агент получает стандартный интерфейс к Git, базам данных, документации, Kubernetes, облакам, системам мониторинга и чему угодно ещё.

С точки зрения киберпанка тоже всё складывается замечательно. Мы создали универсальный протокол, позволяющий искусственному интеллекту подключать дополнительные способности по мере необходимости. В кино после этой фразы обычно начинает играть тревожная музыка. В корпоративной инфраструктуре после неё обычно начинается согласование OAuth scopes.

Но безопасность здесь переворачивается очень быстро. MCP-сервер может превратить модель из читателя кода в оператора инфраструктуры. Если подключить инструменты для Kubernetes, GitLab, PostgreSQL, AWS и корпоративных коммуникаций, агент получает возможность строить цепочки действий между системами. Поэтому на этой границе необходимы строгая аутентификация, авторизация, проверка входных данных и изоляция сессий.

Это касается и Cursor, и Claude Code, и GigaCode в GigaIDE. Поддержка протокола сама по себе не определяет безопасность подключения. Её определяют конкретный MCP-сервер, доступные инструменты, выданные полномочия и способ выполнения операций. Один сервер может отдавать обезличенную документацию, а другой - выполнять команды в Kubernetes от имени администратора; формально оба используют один протокол, но последствия ошибки у них совершенно разные.

Особенно неприятна косвенная инъекция инструкций. Агент может прочитать issue, README, веб-страницу, лог приложения или комментарий в исходном коде, содержащий инструкции, подготовленные атакующим. Для обычного разработчика это просто текст. Для модели текст одновременно является данными и потенциальной инструкцией.

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

Посмотри issue #431 и выясни, почему deployment падает.
Проверь Kubernetes и исправь проблему.

В issue находится специально подготовленный текст. Агент читает его, после чего имеет доступ к MCP-инструменту Kubernetes и shell. Если архитектура разрешений плохая, граница между «прочитать данные» и «выполнить действие на основании этих данных» оказывается слишком тонкой.

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

Главный принцип - агент не должен наследовать личность разработчика

Вот здесь у меня будет немного непопулярное мнение. Запускать автономного ИИ-агента непосредственно в пользовательской сессии DevOps-инженера с его обычными полномочиями - плохая архитектура. Даже если агент великолепен, разработчик опытный, а модель никогда раньше не делала ничего подозрительного.

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

kubectl exec
kubectl logs
argocd sync
terraform apply
vault read
aws sts assume-role
ssh production-host

Из этого совершенно не следует, что те же возможности должен автоматически получать процесс Claude Code, Cursor Agent или агент GigaCode, работающий в GigaIDE. ИИ-агент должен иметь собственную идентичность. Никогда не рассматривайте его как продолжение личности пользователя.

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

flowchart TD
    H["Идентичность инженера"] --> P["Production"]
    H --> G["Контроль доступа"]
    G --> A["Идентичность агента"]
    A --> D["Development и Test"]
    A --> R["Выбранные репозитории"]
    A --> K["Документация"]

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

ИИ-агент должен иметь собственную идентичность. Права разработчика не должны автоматически становиться правами программы, которая помогает ему писать код.

Первый уровень защиты - отдельная среда выполнения

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

Причём обычный Docker-контейнер не следует считать абсолютной границей безопасности. Для особо чувствительных сценариев имеет смысл рассматривать дополнительные уровни изоляции, например gVisor или Kata Containers через подходящую конфигурацию RuntimeClass. Выбор зависит от требований к изоляции, совместимости инструментов и эксплуатационной сложности.

Рабочее пространство агента должно содержать только то, что необходимо для конкретной задачи. Хорошая базовая конструкция выглядит достаточно скучно, и именно этим она мне нравится.

Компонент Требование
Среда выполнения Одноразовая виртуальная машина или изолированная песочница
Исходный код Рабочая копия выбранного проекта
Учётные данные Ограниченные и короткоживущие
Исходящий трафик Контролируемый
Файлы хоста Не подключаются без необходимости
Docker socket Не передаётся агенту
Production kubeconfig Отсутствует
Завершение задачи Среда уничтожается

Слово «одноразовая» здесь важно. После завершения задачи среда уничтожается. Это резко уменьшает ценность долговременного закрепления, отравления состояния и накопления секретов. В хорошем будущем агент получает чистую комнату, выполняет работу и исчезает вместе со своим окружением. В плохом будущем у нас один бессмертный контейнер ai-agent-prod-final-v2-do-not-delete, внутри которого за четыре года накопились SSH-ключи, npm-токены и загадочный бинарник helper-old.

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

Второй уровень - никакого Docker socket

Монтирование /var/run/docker.sock в среду агента фактически означает выдачу очень серьёзных полномочий над Docker-хостом. Поэтому такая конфигурация контейнера с автономным агентом должна вызывать примерно ту же реакцию, что пароль admin/admin на публичной Grafana.

volumes:
  - /var/run/docker.sock:/var/run/docker.sock

Если агенту необходимо собирать контейнеры, используйте отдельный удалённый сборщик, BuildKit с контролируемой конфигурацией или специализированный исполнитель CI. Возможность собирать образ не должна автоматически означать возможность управлять Docker daemon рабочей станции.

Это одинаково относится к задачам, которые запускаются из Cursor, Claude Code или GigaIDE с GigaCode. Удобная кнопка сборки не отменяет того, что за ней находится конкретный процесс с конкретными полномочиями. Если этот процесс может управлять контейнерами на хосте инженера, границы доступа нужно оценивать именно на уровне хоста.

Третий уровень - исходящая сеть должна быть закрыта по умолчанию

Это, пожалуй, один из важнейших выводов истории OpenAI. Запретить агенту входящие соединения недостаточно. Главный риск находится в исходящем трафике, потому что именно через него можно обращаться к внешним сервисам, получать дополнительные инструменты и передавать данные.

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

default deny egress

Схема «интернет доступен, кроме известных плохих адресов» для автономного агента значительно слабее. Мы не можем заранее перечислить все внешние сервисы, через которые он способен построить неожиданную цепочку действий.

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

Уровень Что он ограничивает
Песочница приложения Доступ инструментов и дочерних процессов
Изоляция ОС или контейнера Файлы, процессы и системные возможности
Сетевое пространство Доступные маршруты и соединения
Прокси исходящего трафика Разрешённые внешние назначения
Межсетевой экран Соединения за пределами установленной политики

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

Как это сделать в Kubernetes

Если организация запускает собственные агенты в Kubernetes, я бы выделил для них отдельные пространства имён, а для более серьёзных установок - отдельный кластер или отдельные рабочие узлы. Это позволяет задавать ограничения централизованно и уменьшает число случайных пересечений с обычными приложениями.

Начнём с ServiceAccount. Если агенту Kubernetes API не нужен, токена API внутри pod вообще быть не должно.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: ai-agent
  namespace: ai-agents
automountServiceAccountToken: false

automountServiceAccountToken: false - маленькая строка, которую удивительно часто забывают. Kubernetes рекомендует отключать автоматическое монтирование токена, если рабочая нагрузка не нуждается в API. Отдельный ServiceAccount также позволяет явно описать идентичность приложения вместо неявного использования общей учётной записи пространства имён.

Дальше вводим исходный запрет сети. Эта политика выбирает все pod в пространстве имён и не разрешает ни входящие, ни исходящие соединения.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: ai-agents
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

После этого отдельно разрешаем только действительно необходимые направления. Например, корпоративный шлюз моделей, находящийся в пространстве имён ai-gateway.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ai-gateway
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      app: coding-agent
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ai-gateway
      ports:
        - protocol: TCP
          port: 443

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

SecurityContext должен быть скучным

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

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault

containers:
  - name: agent
    image: registry.example.org/ai/agent:1.0.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

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

containers:
  - name: agent
    volumeMounts:
      - name: tmp
        mountPath: /tmp

volumes:
  - name: tmp
    emptyDir:
      sizeLimit: 1Gi

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

На уровне пространства имён имеет смысл применять Pod Security Admission. Метки ниже задают профиль restricted для принудительной проверки, аудита и предупреждений.

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

SecurityContext вообще должен быть скучным. Без privileged: true, без сети хоста, без процессов хоста, без hostPath и без маленького комментария # temporary workaround, датированного позапрошлым годом. Если конфигурация безопасности выглядит скучно, это хороший признак. Киберпанк прекрасен в книгах, но крайне утомителен в дежурстве SRE.

Production Kubernetes вообще не должен быть виден

Самое безопасное правило очень простое: попытка автономного агента обратиться к production Kubernetes API должна заканчиваться сетевым запретом. Не «мы попросили его ничего не менять», не kubeconfig с контекстом, который агент теоретически не должен выбирать, а техническая недоступность этого маршрута.

Если агенту требуется информация о production, создайте промежуточный интерфейс с минимальными возможностями. Через него можно отдавать состояние deployment, последние события или обезличенные логи, не предоставляя произвольный доступ к Kubernetes API.

Компонент Назначение
Production-кластер Источник эксплуатационных данных
Интерфейс телеметрии Получение заранее определённых сведений
Шлюз очистки данных Удаление секретов и ограничение выдачи
ИИ-агент Анализ предоставленной информации

Если всё-таки необходим Kubernetes MCP для тестового окружения, создавайте отдельный ServiceAccount с минимальным RBAC. Например, роль наблюдателя может разрешать чтение pod, событий и deployment только в пространстве имён development.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: ai-observer
rules:
  - apiGroups: [""]
    resources:
      - pods
      - events
    verbs:
      - get
      - list
      - watch

  - apiGroups: ["apps"]
    resources:
      - deployments
    verbs:
      - get
      - list
      - watch

Обратите внимание, чего здесь нет: чтения Secrets, выполнения команд через exec, создания, изменения и удаления ресурсов. Если агенту нужен анализ состояния, это ещё не означает, что ему нужна возможность менять состояние.

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

Никаких вечных секретов

Следующая ошибка - передать агенту постоянный AWS access key, GitLab token или kubeconfig. Такие полномочия имеют неприятное свойство переживать задачу, рабочее пространство, увольнение инженера и иногда даже сам сервис, ради которого их когда-то создали.

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

Идентичность сессии: OIDC
Выдача полномочий:   STS / Vault
Время жизни:        15 минут
Область доступа:    конкретный проект и окружение
Завершение:         истечение или отзыв полномочий

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

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

В киберпанке корпорации защищают свои секреты многоуровневыми нейросетями, биометрией и вооружённой охраной. В нашей временной линии самый секретный production token всё ещё иногда называется .env.old.backup. Не будем облегчать будущему искусственному сверхразуму работу сильнее, чем это уже сделали сами.

Отдельная роль для агента

Представим AWS. Вместо конструкции, в которой разработчик имеет AdministratorAccess, а агент наследует его окружение и полномочия, создаём две отдельные роли. Человек работает с административной ролью по установленным правилам, а агент - с ограниченной ролью для разработки.

Идентичность Роль
Инженер human-admin-role
ИИ-агент ai-development-role

Причём ai-development-role может разрешать чтение тестовых логов и метрик, работу с веткой изменений и выполнение согласованных операций в development. Но из этого совершенно не следует необходимость доступа к управлению IAM, production-секретам, production-кластерам и данным рабочих систем.

Разрешено:
  читать логи development
  читать метрики development
  отправлять изменения в feature branch
  выполнять разрешённые операции development

Не разрешено:
  управлять IAM
  читать production-секреты
  администрировать production Kubernetes
  изменять production-данные

Тот же принцип работает в GitLab, GitHub, Vault, Kubernetes, Argo CD и PostgreSQL. И он не зависит от того, использует инженер Cursor, Claude Code или GigaIDE с GigaCode. Инструмент разработки может меняться, а границы полномочий должны оставаться свойством инфраструктуры.

Git тоже является границей безопасности

Я бы запретил агентам прямой push в main. Агент должен работать в отдельной ветке, а его изменения - проходить через запрос на слияние, автоматические проверки и человеческое ревью.

flowchart TD
    A["ИИ-агент"] --> B["Ветка изменений"]
    B --> P["Запрос на слияние"]
    P --> T["Тесты и проверки безопасности"]
    P --> R["Ревью инженера"]
    T --> M["Защищённая ветка main"]
    R --> M

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

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

Не позволяйте агенту одновременно писать код и выкатывать его

Это одна из моих любимых архитектурных ловушек. Мы подключаем агенту Git, Kubernetes, Argo CD, AWS и Terraform, а затем выдаём совершенно невинную задачу: «Исправь проблему и проверь, что всё работает».

Фактически один субъект получает возможность изменить код, изменить инфраструктуру, развернуть изменение и проверить самого себя. У людей мы десятилетиями строили separation of duties - разделение полномочий. Потом появился симпатичный чат справа от редактора, и мы почему-то решили выбросить эту идею в окно.

Разделяйте роли и этапы выполнения. Даже если на нескольких этапах используются ИИ-модели, они не должны автоматически получать общую идентичность и полный набор инструментов.

Участник Полномочия
Агент подготовки кода Изменения в отдельной ветке
Агент анализа Проверка без права изменения
CI Тесты и выполнение политик
Контроллер доставки Развёртывание в разрешённое окружение
Ответственный инженер Подтверждение production-изменения

Так ошибка одного агента не превращается автоматически в production-инцидент. И если однажды несколько агентов всё-таки решат построить Скайнет, им хотя бы придётся пройти обязательный code review и дождаться зелёного pipeline.

А что делать с Terraform

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

Агенту вполне можно поручить подготовку и проверку Terraform-кода. Но выполнение даже предварительных команд должно происходить в контролируемом окружении с ограниченными полномочиями.

terraform fmt
terraform validate
terraform plan

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

terraform apply
terraform destroy

При этом terraform plan тоже нельзя считать совершенно безобидным чтением текста. Он запускает провайдеры и может обращаться к удалённым системам, а результат способен содержать чувствительные данные. Поэтому планирование лучше выполнять в контролируемом CI с отдельными полномочиями, а агенту предоставлять проверяемый результат в разрешённом объёме.

Хорошая архитектура сохраняет последовательность: агент предлагает Terraform-код, изменения попадают в Git, CI формирует план, политики проверяют результат, человек подтверждает конкретное изменение, а доверенный исполнитель применяет его. Агент создаёт предложение об изменении инфраструктуры, но не обладает полномочиями воплотить его в жизнь.

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

То же самое относится к Argo CD

Не выдавайте агенту административный токен Argo CD. Пусть он меняет Git. Ветка, запрос на слияние, проверки и подтверждение уже образуют понятный процесс, который не нужно обходить только потому, что новый помощник умеет писать YAML быстрее человека.

Последовательность остаётся обычной: агент предлагает изменение, инженер проверяет его, защищённая ветка принимает утверждённое состояние, а Argo CD синхронизирует разрешённые ресурсы. Это один из случаев, когда GitOps становится не просто удобной моделью доставки, а дополнительной границей безопасности.

Агент не управляет кластером напрямую. Он предлагает изменение желаемого состояния, которое проходит через обычный процесс проверки. Это одинаково применимо к изменениям, подготовленным в Cursor, Claude Code или GigaIDE с GigaCode.

Возможно, в 2045 году искусственный интеллект и захватит человечество, но сначала его pull request должен пройти CODEOWNERS. Мне нравится эта временная линия.

Наблюдаемость агента должна быть отдельной

Обычного журнала приложения недостаточно. Нам нужно видеть действия агента как последовательность событий. Иначе после инцидента мы получим длинный диалог с уверенными объяснениями и очень мало информации о том, какие операции действительно выполнялись.

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

{
  "session_id": "42f...",
  "agent_id": "9a52...",
  "user_id": "ivan.petrov",
  "model": "approved-model",
  "repository": "billing-service",
  "tool": "kubernetes.get_deployment",
  "environment": "development",
  "namespace": "billing",
  "result": "allowed",
  "timestamp": "2027-08-12T10:15:00Z"
}

Не обязательно складывать абсолютно весь контекст модели в SIEM. Там могут находиться чувствительные данные. Но операции инструментов должны быть наблюдаемыми: обращения к файлам, запросы полномочий, вызовы MCP, операции Git и взаимодействия с Kubernetes должны оставлять пригодный для расследования след.

Особенно интересны попытки чтения каталогов с ключами и облачными профилями, обращения к kubeconfig, Docker socket и сервисам метаданных. Туда же относятся неожиданные внешние назначения, чтение Secrets, выполнение kubectl exec, исследование IAM, подключение нового MCP-сервера и резкий рост числа вызовов инструментов.

agent -> ~/.ssh
agent -> ~/.aws
agent -> kubeconfig
agent -> /var/run/docker.sock
agent -> 169.254.169.254
agent -> unexpected external domain
agent -> Secret list
agent -> kubectl exec
agent -> IAM enumeration
agent -> new MCP server
agent -> hundreds of tool calls
agent -> unusual shared storage

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

Представьте прекрасное утро понедельника. Grafana показывает новую метрику, и график вертикально уходит вверх.

ai_agent_inter_agent_messages_total = 73421

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

Метаданные облака должны быть недоступны

Адрес 169.254.169.254 не должен быть доступен агентным рабочим нагрузкам без очень веской причины. AWS, Azure и другие облака используют сервисы метаданных экземпляров для выдачи информации и, в определённых конфигурациях, временных учётных данных.

Если агент обнаружит SSRF или другой путь до сервиса метаданных, последствия могут выйти далеко за пределы исходной песочницы. Поэтому защита должна существовать одновременно на нескольких уровнях: сетевые политики, межсетевой экран хоста, настройки сервиса метаданных облака, отдельная идентичность рабочей нагрузки и минимальные облачные полномочия.

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

Prompt injection нельзя победить хорошим system prompt

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

NEVER reveal secrets.
NEVER access production.
NEVER execute dangerous commands.

Настоящая граница выглядит иначе. Попытка обращения к production заканчивается сетевым запретом, запрос секрета отклоняется политикой Vault, удаление ресурса блокируется RBAC, а push в защищённую ветку отвергается правилами Git.

Попытка агента Независимый механизм ограничения
Подключиться к production Сетевой запрет
Получить недоступный секрет Политика Vault
Удалить ресурс Kubernetes RBAC
Отправить изменения напрямую в main Защита ветки
Выполнить неподтверждённую операцию Политика доверенного исполнителя

Хороший промпт объясняет агенту правила. RBAC, межсетевой экран и IAM делают так, чтобы нарушение правил не стало катастрофой. Здесь нет противоречия: инструкции помогают выбирать действия, а технические ограничения определяют, какие действия вообще возможны.

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

Корпоративный LLM Gateway

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

Клиентами такого шлюза могут быть Cursor, Claude Code, GigaCode в GigaIDE, внутренние агенты и задачи CI. При этом совместимость конкретного инструмента со шлюзом и возможность настройки его маршрутов нужно проверять отдельно. Архитектурная схема не должна превращаться в обещание, что любой продукт из коробки поддерживает произвольную корпоративную интеграцию.

flowchart TD
    C["Cursor и Claude Code"] --> G["Корпоративный шлюз моделей"]
    S["GigaIDE и GigaCode"] --> G
    A["Внутренние агенты и CI"] --> G
    G --> P["Разрешённые внешние поставщики"]
    G --> M["Внутренние модели"]

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

У каждого агента должна быть идентичность

Общий ключ вида API_KEY=sk-company-global-super-secret удобен ровно до первого расследования. После него обычно оказывается, что ключ использовали двадцать инженеров, пять автоматизаций и какой-то контейнер, происхождение которого уже никто не может объяснить.

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

agent_id: "9a52..."
user_id: "ivan.petrov"
repository: "billing-service"
environment: "development"
session_id: "42f..."
expires_at: "2027-08-12T14:32:00Z"

После этого политики могут принимать осмысленные решения. Агенту проекта billing-service разрешаются его репозиторий, тестовое пространство имён и соответствующие логи, но не кадровые репозитории, финансовые базы, управление IAM и production.

Разрешено:
  Git: billing-service
  Kubernetes: development / billing
  Логи: development / billing

Запрещено:
  production
  кадровые репозитории
  финансовые базы данных
  управление IAM

Так появляется нормальная трассируемость. Если что-то произошло, мы можем ответить не «кажется, это сделал Claude» или «это вроде пришло из GigaIDE», а установить конкретную сессию, пользователя, модель, набор инструментов, выданные полномочия и последовательность действий.

Что делать с Cursor в организации

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

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

git.company.internal
registry.company.internal
pypi.company.internal
npm.company.internal
ai-gateway.company.internal

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

Что делать с Claude Code

Для Claude Code я бы использовал корпоративные управляемые настройки и запрещал пользователям ослаблять критические ограничения. Система разрешений позволяет отдельно задавать разрешённые и запрещённые инструменты, а политики организации должны иметь приоритет над пользовательским удобством. Отдельно необходимо проверить границы самой песочницы: защита shell-команд не означает автоматической изоляции всех встроенных инструментов, MCP-серверов и вспомогательных процессов.

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

--dangerously-skip-permissions

Если такой режим действительно нужен, он должен запускаться только внутри специально подготовленной одноразовой песочницы. Не на ноутбуке SRE, не на сервере административного доступа и точно не на машине, где текущий контекст Kubernetes указывает на production.

kubectl config current-context

Мы всё-таки хотим киберпанк с неоном, летающими автомобилями и синтетическими людьми. А не с Jira-инцидентом SEV-1: Claude accidentally deleted prod.

Что делать с GigaIDE и GigaCode от Сбера

В российской инфраструктуре этот разговор стоит продолжить на примере GigaIDE от Сбера и СберТеха. Здесь полезно различать саму среду разработки и подключённого к ней ИИ-помощника: GigaIDE предоставляет рабочее окружение, а GigaCode добавляет интеллектуальные возможности. В официальной документации плагина GigaCode для GigaIDE описаны режимы вопросов, планирования и выполнения агентных задач, работа с файлами и логами в контексте, просмотр изменений, а также поддержка MCP, правил и навыков. Поэтому оценивать такую связку исключительно как автодополнение кода уже недостаточно: при включении агентного режима и подключении инструментов нужно отдельно разбирать доступные агенту действия.

При этом российское происхождение продукта не заменяет инфраструктурную модель безопасности. Выбор поставщика, условия обработки исходного кода и соответствие требованиям организации важны, но это отдельные вопросы от полномочий процесса, доступности секретов и границ сетевого доступа. Даже согласованная с информационной безопасностью среда разработки не делает автоматически безопасным любой установленный плагин, подключённый MCP-сервер или набор выданных ему прав. На kubeconfig не действует магия импортозамещения: если процесс может прочитать файл и обратиться к API Kubernetes, происхождение логотипа на панели инструментов его не остановит.

Представим обычную задачу: инженер открывает в GigaIDE проект на FastAPI и просит GigaCode исправить обработчик, добавить тесты и подготовить манифесты Kubernetes. Для этого помощнику нужен контекст выбранного проекта, возможность предложить изменения и, если предусмотрено выполнение тестов, изолированное тестовое окружение. Production kubeconfig, токен Vault и SSH-ключи администратора для такой работы не нужны. Если дополнительно подключается MCP-сервер для диагностики Kubernetes, ему следует выдавать отдельную идентичность и минимальные права в конкретном тестовом пространстве имён, а не доступ от имени инженера ко всем кластерам.

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

Сначала составь план изменения обработчика FastAPI.
Затем подготовь правки, тесты и манифесты для тестового окружения.

Покажи изменения для проверки.
Развёртывание выполняется через утверждённый процесс CI/CD.

Но этот текст объясняет порядок работы, а не создаёт защитную границу. Недоступность production должна обеспечиваться правами, изоляцией среды выполнения, сетевыми ограничениями и настройками интеграций. Ограничения необходимо проверить для конкретной версии GigaIDE, плагина GigaCode и выбранного режима работы, не предполагая, что механизмы другого продукта автоматически присутствуют здесь.

Именно поэтому я бы включал GigaIDE с GigaCode в те же архитектурные проверки, что Cursor, Claude Code и другие агентные инструменты. Проверял бы, какие файлы попадают в контекст модели, куда передаются данные, какие команды и внешние инструменты доступны, где сохраняются журналы и как отзываются полномочия. Возможности продукта следует сверять с официальной документацией GigaCode для GigaIDE, а средства защиты - проверять в собственном контуре. Нам нужен удобный российский помощник инженера, а не ещё один путь к административному доступу, который случайно появился вместе с обновлением среды разработки.

Рабочая станция DevOps - худшее место для полностью автономного агента

У обычного разработчика серверного приложения агент может увидеть код и учётные данные тестового окружения. У инфраструктурщика ситуация принципиально хуже. На одной машине часто находятся SSH-ключи, облачные профили, kubeconfig, полномочия Terraform, токены Vault, доступ к Git, Ansible inventory, настройки Helm, VPN, внутренний DNS и документация production.

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

Поэтому для DevOps и SRE я бы вообще рекомендовал другую модель. Ноутбук используется как интерфейс к удалённому рабочему пространству агента, а само пространство располагается в ограниченной сети разработки. Production-операции остаются локальным инструментам человека или специализированным системам автоматизации.

Такой подход применим независимо от того, через что инженер взаимодействует с помощником: Cursor, Claude Code или GigaIDE с GigaCode. Вопрос не в удобстве конкретного интерфейса, а в том, где выполняются действия и какие ресурсы доступны исполнителю.

Принцип двух ключей для опасных действий

Некоторые операции должны требовать подтверждения вне самого агента. Например, удаление базы, ротация production-секрета, применение Terraform к рабочему окружению, синхронизация production в Argo CD, удаление пространства имён, изменение IAM и слияние в защищённую ветку.

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

flowchart TD
    A["Предложение агента"] --> P["Проверка политики"]
    P --> D{"Операция разрешена?"}
    D -->|Нет| X["Отказ и аудит"]
    D -->|Да| H["Подтверждение инженера"]
    H --> E["Независимый исполнитель"]
    E --> L["Результат и аудит"]

Обратите внимание на последнее слово: исполнитель. Не агент после подтверждения выполняет команду своими учётными данными. Команду выполняет отдельный компонент, поэтому агент вообще не получает production-полномочия.

Это принципиально отличается от кнопки Allow в терминале. Человеческое подтверждение не должно просто разблокировать сверхспособность агента. Оно должно передавать конкретную проверенную операцию другому доверенному компоненту.

Аварийный выключатель тоже нужен

У агентной платформы должен существовать настоящий аварийный выключатель. Сообщение please stop в чате не является полноценным механизмом остановки, если процесс уже выполняет команды или использует выданные ранее полномочия.

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

Например, в собственной платформе это может выглядеть как команда отзыва сессии. Ниже - условный интерфейс такого контроллера, а не команда из поставки Cursor, Claude Code или GigaCode.

agentctl revoke session-8fd72

За этой операцией оркестратор завершает pod, отзывает сессию, аннулирует аренды Vault, отключает токен шлюза, блокирует сетевую идентичность и сохраняет журнал аудита. Вот это настоящий аварийный выключатель, потому что он воздействует на инфраструктуру, а не пытается переубедить модель.

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

Ограничивайте не только права, но и бюджет действий

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

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

session_ttl: 30m
max_subagents: 5
max_tool_calls: 500
max_network_requests: 1000
workspace_limit: 10Gi

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

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

Общие ресурсы между агентами надо считать коммуникационной системой

История OpenAI особенно хорошо показала именно это. Допустим, мы запускаем 50 параллельных агентов разработки. У них общий Nexus, Artifactory, S3, Git, Redis, PVC или кеш CI. Значит, потенциально у них есть каналы связи, даже если прямые сетевые соединения между рабочими пространствами запрещены.

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

Это довольно сильное изменение привычной модели угроз. Мы привыкли рассматривать S3 bucket как хранилище, Redis как кеш, Git как систему контроля версий, Artifactory как репозиторий артефактов. Для агента это прежде всего ресурсы, состояние которых можно прочитать или изменить. Их первоначальное назначение является человеческой договорённостью, а не физическим законом.

Не забываем про цепочку поставки программного обеспечения

Агенту очень удобно сказать: «Установи всё необходимое и почини тесты». После чего он может начать устанавливать зависимости из нескольких экосистем, запускать их код и подключать дополнительные инструменты.

npm install ...
pip install ...
go install ...
cargo install ...

Каждая установка зависимости расширяет поверхность атаки. Поэтому корпоративные агенты желательно направлять через внутренние зеркала PyPI, npm, Go proxy и реестры контейнеров. Это одновременно позволяет проверять зависимости и уменьшает произвольный доступ наружу.

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

Автономный агент, которому разрешено устанавливать произвольный пакет из интернета и сразу выполнять его код, - это уже не столько помощник программиста, сколько автоматизированная лотерея цепочки поставки. И здесь нет принципиальной разницы между запуском из Cursor, Claude Code или GigaIDE: опасность находится в разрешённой последовательности действий.

Что я бы внедрил завтра утром

Если в организации уже активно используются Cursor, Claude Code, Copilot, GigaIDE с GigaCode или собственные агенты, я бы не начинал с огромного проекта безопасности ИИ длиной в год. Сначала надо убрать самые опасные архитектурные сочетания. Запретить агентам production-полномочия и production kubeconfig, включить песочницу, закрыть произвольный исходящий трафик, убрать Docker socket, отделить человеческую идентичность от агентной и перевести доступ на короткоживущие полномочия. После этого ограничить MCP, запретить прямой push в защищённые ветки, отделить подготовку Terraform-плана от применения, убрать прямое развёртывание в production и начать регистрировать вызовы инструментов.

Следующим этапом я бы добавил аварийный выключатель, лимиты числа субагентов и времени сессии, отдельные рабочие пространства и аудит всех общих изменяемых ресурсов. И только после этого занимался бы красивыми политиками предотвращения утечек, классификацией данных и сложной поведенческой аналитикой. Потому что бессмысленно строить машинное обучение для обнаружения подозрительного поведения агента, если рядом у него спокойно лежит cluster-admin.conf.

Эталонная архитектура

Если собрать всё вместе, я бы хотел видеть корпоративную платформу, в которой интерфейс разработки отделён от полномочий выполнения. Cursor, Claude Code, GigaIDE с GigaCode или собственный клиент отправляют задачи контроллеру, а тот создаёт ограниченное рабочее пространство, применяет политики и ведёт аудит.

flowchart TD
    U["Инженер"] --> I["Cursor, Claude Code или GigaIDE с GigaCode"]
    I --> C["Контроллер агентной сессии"]
    C --> P["Политики доступа"]
    C --> A["Журнал аудита"]
    P --> S["Одноразовая песочница"]
    S --> G["Git: ветка изменений"]
    S --> M["Разрешённые MCP-инструменты"]
    S --> L["Шлюз моделей"]
    M --> D["Тестовые сервисы и документация"]
    L --> V["Разрешённые модели"]
    G --> R["Запрос на слияние"]
    R --> T["Тесты и проверки"]
    T --> H["Ревью инженера"]
    H --> CI["CI/CD и Argo CD"]
    CI --> PR["Production"]

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

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

Самый неприятный вывод

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

Если ответ включает выполнение shell-команд, чтение файловой системы, доступ к сети, вызовы API, использование учётных данных, запуск субагентов, изменение Git и обращение к Kubernetes, перед нами уже не просто языковая модель. Перед нами полноценный субъект инфраструктуры. А субъект инфраструктуры должен иметь идентичность, минимальные полномочия, сетевые политики, журнал аудита, лимиты ресурсов и процедуру отзыва доступа.

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

Киберпанк действительно наступил. Просто рекламные буклеты забыли уточнить некоторые детали.

И всё-таки я не предлагаю запрещать агентов

После истории OpenAI легко прийти к выводу, что автономные агенты слишком опасны и проще оставить разработчикам старый добрый Vim. Я с этим не согласен. Агенты слишком полезны, чтобы отвечать на их появление только запретами.

Cursor, Claude Code, Copilot, GigaCode в GigaIDE и их будущие аналоги действительно меняют разработку. Они могут помогать исследовать большие кодовые базы, писать тесты, готовить миграции, анализировать логи, создавать Terraform-код, искать ошибки и автоматизировать огромный пласт инженерной рутины. Через несколько лет работа без таких инструментов, вероятно, будет выглядеть примерно так же странно, как сегодня разработка без системы контроля версий.

Проблема не в том, что агент способен действовать. Проблема начинается, когда организация даёт ему все возможности действовать сразу. OWASP очень точно сводит Excessive Agency к трём составляющим: слишком много функций, слишком много полномочий и слишком много автономности. Сокращая каждую из этих составляющих до необходимого объёма, мы уменьшаем зону поражения и сохраняем полезность инструмента.

Вместо заключения: Скайнет оказался немного другим

История OpenAI и Hugging Face интересна не количеством агентов и даже не фактом реальной компрометации. Самый важный урок заключается в другом. Мы построили программные системы, которые способны исследовать своё окружение и искать неожиданные способы достижения цели, а инфраструктуру вокруг них пока продолжаем проектировать так, словно запускаем обычный детерминированный процесс. Так больше не работает.

Если агенту запрещён интернет, но доступен сервис, способный ходить в интернет, значит интернет потенциально доступен. Если агентам запрещено общаться, но доступно общее изменяемое состояние, значит потенциальный канал связи существует. Если агенту запрещён production промптом, но на диске лежит production kubeconfig, значит production потенциально доступен. Если агенту запрещено читать секреты, но его ServiceAccount позволяет создать pod с этими секретами, значит секреты потенциально доступны. Если агент не должен менять инфраструктуру, но обладает возможностью выполнить terraform apply с необходимыми полномочиями, ограничение существует только в нашей голове.

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

Мы уже проходили этот путь с пользователями, приложениями, контейнерами, CI/CD и Kubernetes. Именно поэтому появились принцип минимальных полномочий, Zero Trust, RBAC, NetworkPolicy, песочницы, короткоживущие учётные данные, GitOps, контроль допуска ресурсов и многоуровневая защита. Теперь в эту модель нужно добавить ещё одного пользователя.

Только пользователь этот читает тысячи строк в секунду, не устаёт ночью, способен запускать shell, может позвать несколько субагентов и, если дать ему слишком много прав, совершенно искренне превратит ваш production в очень познавательный эксперимент. И совершенно неважно, из какого интерфейса он пришёл: Cursor, Claude Code, GigaIDE с GigaCode или внутреннего корпоративного портала.

Так что Скайнет, возможно, действительно однажды появится. Только я всё меньше верю, что его построят в секретном военном бункере под Невадой. Скорее всего, кто-нибудь в пятницу вечером запустит его из среды разработки, выдаст cluster-admin, подключит MCP к AWS и Kubernetes, отключит ограничения выполнения, а затем уйдёт пить кофе со словами: «Пусть пока сам попробует разобраться».

Поэтому я бы предпочёл встретить киберпанковское будущее подготовленным. С запретом доступа по умолчанию, короткоживущими токенами, нормальным RBAC, отдельной песочницей и большой красной кнопкой REVOKE. Потому что если уж машины однажды решат захватить мир, будет особенно обидно узнать из расследования, что первоначальный доступ им достался через забытый kubeconfig в домашнем каталоге DevOps-инженера.