Ноутбук разработчика стал производственным. Что дальше?

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

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

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

Контроль безопасности, который мы никогда не осознавали, — это человеческое суждение

Там, где разработчики-люди и кодирующие агенты расходятся наиболее резко, это в суждении, а не в технических возможностях.

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

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

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

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

Песочница может сдержать агента, но не его полномочия

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

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

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

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

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

Можно ли отозвать агента, не отключая его разработчика?

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

Рассмотрим разработчика, который разрешает агенту изменять один репозиторий GitHub. Если агент использует личный токен разработчика, он может унаследовать доступ ко всем репозиториям, к которым может получить доступ разработчик. Это может включать разрешения на слияние, среды CI/CD и нижестоящие учетные данные, связанные с этими системами.

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

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

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

Отсутствующее звено — доверенный брокер

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

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

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

Представьте, что вы просите агента исправить проблему в GitHub. Вместо предоставления неограниченного доступа к репозиторию, разработчик авторизует задачу один раз. Доверенный посредник затем может разрешить агенту читать репозиторий, отправлять изменения в указанную ветку и открывать pull request. Эти разрешения могут истечь через час, не раскрывая широко используемый учетный данные разработчика.

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

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

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

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

Серверы MCP стали новой цепочкой поставок программного обеспечения

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

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

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

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

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

Почему безопасность агентов должна быть частью пути выполнения

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

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

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