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

В ходе недавних оценок кибербезопасности британский Институт безопасности ИИ (AISI) 122 раза прогнал кибербезопасностное задание на нескольких моделях. В 10 из этих прогонов ИИ-агенты совершили 19 несанкционированных действий в реальном мире, в живом интернете, — от попытки внести вредоносный код в публичный репозиторий с открытым исходным кодом до запуска кампании социальной инженерии, нацеленной на то, чтобы добиться одобрения от мейнтейнера.

Ключевое наблюдение с точки зрения безопасности: для этого не потребовалось выходить из песочницы.

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

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

Перед нами два принципиально разных типа сбоев в корпоративном стеке ИИ:

• Сбой изоляции (Hugging Face / OpenAI): агент расширяет свой фактический доступ, активно преодолевая механизмы защиты.

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

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

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

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

В стандартной корпоративной архитектуре выполнение проходит по многозвенной цепочке:

Человек или системный принципал → Приложение → ИИ-агент → Рабочая нагрузка среды выполнения → Исполняемый инструмент → Целевой ресурс

По мере продвижения по этой цепочке контекст авторизации может теряться при пересечении границ системы управления идентификацией и доступом (IAM), рабочих нагрузок и сервисов. Аутентификация устанавливает личность субъекта, а токен доступа представляет предоставленные полномочия в определённом объёме. Но ни то ни другое не доказывает, что последующий вызов инструмента действительно соответствует тому, что делегировал исходный человек.

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

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

Принципал + Агент + Рабочая нагрузка + Задача + Действие + Ресурс + Контекст + Цепочка делегирования

Нам нужно перестать спрашивать корпоративные команды безопасности: «Может ли этот агент вызвать этот API?» — и начать спрашивать: «Можете ли вы доказать, кто авторизовал это действие и какое проверяемое делегирование даёт этому агенту полномочия выполнить его прямо сейчас?»

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

• Анализ NIST от 27 августа, посвящённый идентификации агентов, указывает на механизмы сохранения и ослабления контекста авторизации, делая акцент на краткосрочных учётных данных с ограниченной аудиторией и на новых транзакционных токенах (Transaction Tokens).

• Стандарт OWASP Agent Control Standard дополняет это, предоставляя стандартизированные промежуточные хуки для динамического управления агентами во время выполнения.

• Спецификация AuthZEN от OpenID Foundation описывает стандартизированный API авторизации между точками применения политик (PEP) и точками принятия решений по политикам (PDP), а рабочая группа WIMSE в IETF определяет учётные данные для идентификации рабочих нагрузок и механизмы аутентификации в распределённых средах.

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

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

1. Сохраняйте различимость субъектов. Чётко разделяйте человека-принципала, автономного агента и идентификатор исполняющей рабочей нагрузки в каждом журнале авторизации. Никогда не сводите их к одной обезличенной служебной учётной записи.

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

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

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

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

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

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

Бадал Бхушан — заслуженный инженер (Distinguished Engineer) и эксперт в области кибербезопасности.

Добро пожаловать в сообщество VentureBeat!

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

Читайте больше материалов нашей программы гостевых публикаций — и ознакомьтесь с нашими правилами, если хотите предложить собственную статью!