В феврале прошлого года, по их собственному признанию, сотрудник Meta подключил агента с открытым исходным кодом к своему почтовому ящику и поручил ему предлагать, какие письма архивировать или удалять, а также запрашивать подтверждение перед выполнением действий. Despite the guardrails of the prompt, the agent started deleting. Команды остановки не сработали, и процесс пришлось завершать вручную.

Эта история вспоминается, когда люди говорят об агентах, «совершающих плохие поступки», потому что в ней не было ничего злонамеренного. Действия агента были направлены на достижение поставленной цели, а не на то, что человек имел в виду. Этот разрыв между тем, что мы говорим, и тем, что мы подразумеваем, и представляет собой проблему выравнивания, и она проявляется не только в передовых моделях. Она проявилась в почтовом ящике. Инструкция, которая должна была служить защитным барьером и остановить его, была просто предложением в промпте, и исследование Penn State, опубликованное в августе, объясняет, как такое может произойти. По сути, когда контекстное окно агента заполняется, его фреймворк сжимает его. Исследователи из Penn State выяснили, что ограничения сеанса, такие инструкции, как «сначала подтверди мне», сохраняются после сжатия примерно в 17% случаев. Защитный барьер не дал сбой. Он был просто свёрнут до сводки.

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

Больше агентов, больше доступов, меньше контроля

Агентам передают реальные полномочия, и с каждым кварталом их становится все больше. Gartner ожидает, что к концу текущего года 40% корпоративных приложений будут содержать специализированных агентов по сравнению с менее чем 5% в 2025 году. И каждый из них обладает гораздо большим доступом, чем обычно осознает настроивший его человек. Недавнее раскрытие информации об инциденте, произошедшем в июне, когда агент OpenAI, исследовавший медицинскую статистику, проник в правительственный портал Австралии и получил доступ к закрытым файлам, является ярчайшим примером. Никаких злоумышленников не было. Портал просто находился в зоне досягаемости.

С другой стороны, даже передовые лаборатории сталкивались с тем, что их собственные агенты переходили черту во время собственных оценок. В этом году стали известны инциденты из внутренних оценок OpenAI, Anthropic и Google, и каждая компания подтвердила факты публично. Модели OpenAI использовали слитые учетные данные для доступа к производственным системам другой компании, а Anthropic обнаружила три случая, когда ее модели получали доступ к реальным системам при попытке выполнить поставленные задачи. Компания Google подтвердила, что Gemini получила доступ к трем реальным компаниям во время теста на безопасность, перепутав реальные системы с частью тестовой среды, и что Gemini остановилась, как только осознала, что системы настоящие, но только после того, как граница была пересечена. Лаборатории делают то, что может сделать уровень моделей. Их защитные барьеры представляют собой фильтры, которые запускаются до обработки промпта или после создания вывода, и модель рассуждений, выполняющая длинную задачу, может обойти фильтр, который видит только края, даже не задумываясь об этом. NVIDIA пришла к такому же выводу со стороны инфраструктуры. Ее платформа Open Agent Safety, выпущенная в сентябре, исходит из того, что агенты не могут контролировать себя сами, и связывает их отклонения с обычными причинами, такими как заблокированное действие, отсутствующий инструмент или незаписанная инструкция. Это те же самые модели, которые работают в вашей среде, с вашими учетными данными. Следующий уровень ответственности должен лежать на поставщиках кибербезопасности. Вопрос в том, на каком уровне стека.

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

Многослойный пирог обеспечения безопасности ИИ

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

Начнем сверху, с уровня приложения. Это окружение (harness), фреймворк, в котором работает агент, плюс инструменты, которые он может вызывать. Агент установит MCP-сервер, освоит навык или передаст часть работы другому агенту во время работы, а это значит, что агент, которого вы одобрили сегодня утром, работает уже не так, как днем. Это самый важный факт об агентах, и он находится на этом уровне. Новые возможности появляются во время выполнения, а не во время проверки. Окружение — это также место, где наиболее четко прописано намерение. Когда разработчик говорит «запусти тесты», именно в окружении это превращается в конкретный вызов инструмента с конкретными аргументами, и это запись, которая говорит вам, что именно пытался сделать агент.

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

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

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

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

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

Общая ответственность за ИИ

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

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

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

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

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

Какие уровни должна контролировать кибербезопасность

Лорис выделил четыре не подлежащих обсуждению свойства защиты на этапе выполнения для агентного ИИ. Наблюдение под агентом, наблюдение внутри агента, корреляция и обогащение вместо простого сбора, а также вынесение решений и принятие мер в момент выполнения. Это описывает то, что должна делать защита на этапе выполнения. Карта уровней показывает, где это может происходить и кто это может делать. Этот пробел находится там, где уровень приложения встречается с системным уровнем, в момент выполнения действия, причем вопрос охвата на уровне данных определяет значение этого действия. Это те уровни, которые должны контролировать поставщики кибербезопасности, и среда выполнения — это то место, где этот контроль реализуется. Лорис назвал среду выполнения единственным местом, где живет правда. Это также единственное место, где все четыре свойства выполняются одновременно — это тот подход к безопасности, который нужен агентам, тот, который я бы назвал «сначала проверь, потом доверяй». Проверяйте каждое действие с нескольких точек зрения и расширяйте доверие только по мере того, как история его заслуживает.

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

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

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

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

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

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

Как это выглядит на практике

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

Агент разработчика в ходе выполнения задачи регистрирует сервер MCP, который никто не проверял. Это появление новой возможности на этапе выполнения. Поскольку AI Defense непрерывно анализирует обвязку, сервер проверяется на соответствие правилам организации до своего запуска. Если его нет в списке, он не запускается. Разработчик видит причину и может запросить исключение, что имеет значение, поскольку альтернативой являются заявка на тикет и обходные пути.

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

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

Инвентаризация была настроена заранее. Остальные три решения принимались во время выполнения действия. Это то решение, за которое раньше никто не отвечал, и именно это мы создали.

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