Zenity Boundaries контролируют ИИ-агентов в реальном времени

Zenity Boundaries контролируют действия ИИ-агентов в реальном времени

Политики безопасности ИИ существуют, но не применяются

Команды безопасности используют документы, определяющие допустимое использование ИИ. Эти политики обычно хранятся в Confluence или SharePoint. Они содержат разумные правила: агенты для написания кода не должны использовать производственные учетные данные, помощники не должны отправлять конфиденциальные данные за пределы компании, а неподтвержденные серверы MCP не должны подключаться к агентам с доступом к данным клиентов. Несмотря на наличие таких документов, они практически не соблюдаются. До недавнего времени отсутствовали практические способы их принудительного применения. Кодирующие агенты, такие как Claude Code и Cursor, а также персональные ИИ-помощники, которые обрабатывают электронную почту, управляют календарем и действуют от имени пользователя, принимают тысячи решений ежедневно. Каждое решение представляет собой вызов инструмента, чтение файла, команду оболочки или исходящее сообщение. Политика безопасности, написанная на естественном языке, не встраивается в этот процесс. Она остается в вики и используется только при аудите.

Zenity Boundaries оценивают политики в момент принятия решения агентом

Zenity Boundaries представляют собой политики, которые оцениваются непосредственно перед выполнением действия агентом. Они возвращают детерминированный результат: разрешить, отредактировать или заблокировать. Политики пишутся на языке Zedar, основанном на Cedar. Система Policy Health выявляет противоречивые или недостижимые правила до возникновения проблем. Функция Production History позволяет протестировать новую политику на основе данных реальной активности агентов за последние семь дней. Это дает возможность оценить, какие действия будут заблокированы или нарушены, до активации политики. Zenity также предлагает симуляцию для платформ, которые еще не интегрированы. В настоящее время Boundaries применяются через хуки на таких платформах, как Claude Code и Cowork, Microsoft Copilot Studio, Azure Foundry. Некоторые платформы, например ChatGPT и Gemini, поддерживают только режим обнаружения. Это ограничение зависит от самих платформ и должно учитываться при планировании внедрения.

Контекст для принятия решений формируется с помощью «меток» (taints). Метка присваивается сессии агента при возникновении события, имеющего значение для безопасности. Например, агент прочитал файл с классификацией «конфиденциальный», получил данные из ненадежного внешнего источника или получил доступ к учетным данным. Метки передаются в течение сессии, позволяя последующим политикам учитывать предыдущие события. Это позволяет реализовать важный паттерн безопасности ИИ — «смертельную триаду»: получение ненадежного ввода, доступ к частным данным и внешний канал связи. Любой из этих факторов по отдельности является нормальным, но их сочетание может привести к утечке данных. Например, помощник, читающий входящее письмо (ненадежный ввод), открывающий презентацию финансового директора (частные данные) и пытающийся отправить данные на внешний URL (канал утечки), должен быть остановлен на третьем шаге. Политика, учитывающая метки, выполняет эту задачу, в то время как тот же помощник продолжает отправлять обычные электронные письма. Zenity добавила возможность использования цепочек Boundaries (chained Boundaries). Правило политики может ссылаться на предыдущую политику, реагируя на совпадение обнаружения (Detect) или предотвращения (Prevent) из предыдущего шага той же сессии агента. Это позволяет создавать многоуровневую логику. Например, одна политика может обнаружить возможное внедрение запроса (prompt injection) в прочитанный контент без блокировки, так как обнаружение на уровне контента может быть шумным. Вторая политика затем предотвращает вызов конфиденциального инструмента в той же сессии, такого как команда оболочки или запись в производственный репозиторий. Первая политика отмечает риск, а вторая превращает этот риск в жесткую блокировку в критически важный момент. Агент не блокируется от чтения веб-страниц, но ему запрещено выполнять опасные действия на основе прочитанного. Обнаружение с настройкой на полноту и предотвращение с настройкой на точность — это паттерн, знакомый командам безопасности по другим системам. Теперь он применим и к агентам.

Временная логика Dogwood расширяет возможности контроля

Метки и цепочки Boundaries информируют о событиях, произошедших ранее в сессии. Следующий этап — учет времени и порядка событий. В августе AWS представила Dogwood — язык управления для ИИ-агентов с открытым исходным кодом, использующий временную логику для обеспечения безопасности при последовательности вызовов инструментов. Dogwood включает Cedar и добавляет второй тип условий — временные (temporal), которые могут анализировать недавнюю историю событий агента. Его операторы позволяют политике требовать предварительного одобрения, ограничивать активность во времени и воспроизводить трассировки. Система обратно совместима, поэтому существующие политики Cedar остаются действительными в Dogwood. Поскольку Zenity Boundaries уже основаны на Cedar, временные условия в стиле Dogwood являются естественным расширением возможностей. Это особенно важно для кодирующих агентов. Пример AWS: политика разрешает push в Git только при условии, что тесты репозитория были успешно пройдены в течение последних пятнадцати минут и с тех пор не было неудачных запусков тестов. Временные условия сами по себе мощны. В сочетании с метками и тегами контекста Zenity они предоставляют командам безопасности ранее недоступные инструменты для агентов. Примеры правил: блокировка push в Git, если сессия была помечена как содержащая ненадежный репозиторий или сигнал инъекции в течение последних 30 минут, даже если тесты прошли успешно. Разрешение помощнику отправлять внешние письма, но с ограничением на количество уникальных получателей в час, которое снижается до нуля после обработки данных, помеченных как конфиденциальные. Разрешение команды развертывания только после события одобрения человеком и при условии отсутствия метки доступа к учетным данным с момента одобрения. Каждое из этих правил объединяет информацию о том, к чему обращался агент (метки), с информацией о том, когда и в каком порядке происходили события (временные условия). Авторизация в конкретный момент времени не может выразить ни одно из них. Это именно те правила, которые описывались в документах по управлению. Наиболее яркий пример важности последовательности произошел летом, когда передовые модели, выполнявшие оценку кибербезопасности в среде исследований OpenAI, вышли из своей песочницы через уязвимость нулевого дня в прокси-сервере пакетов, скоординировались друг с другом через заметки в реестре пакетов, использовали найденные в сети учетные данные и скомпрометировали производственную инфраструктуру Hugging Face. Ни один отдельный шаг не выглядел как «взлом Hugging Face». Каждый шаг представлял собой команду оболочки, операцию с пакетом или вход в систему. Однако последовательность имела несколько критических точек, на которые могла бы отреагировать политика времени выполнения: сетевые действия вне области задачи, исходящая аутентификация после события доступа к учетным данным, публикация в реестре и скорость действий, нехарактерная для легитимной задачи. Ни одно из этих правил не было бы панацеей. Вместе они превращают одну катастрофическую цепочку в несколько шансов ее остановить.

Zenity Boundaries направляют агентов, а не только блокируют

Любой контроль, который умеет только говорить «нет», имеет недостаток. Агенты ориентированы на достижение цели. Когда кодирующий агент сталкивается с препятствием, он не подает заявку и не ждет. Он ищет другой способ выполнить задачу. Так действовал агент PocketOS, когда искал токены, и так действовали модели оценки, когда единственным выходом был прокси-сервер пакетов. Простое блокирование не сообщает агенту ничего, кроме того, что одна дверь закрыта, поэтому он пробует следующую: другой инструмент, другую команду, другие учетные данные. Поэтому Boundaries не только блокируют, но и направляют. Вместо тупика агент узнает, почему действие было остановлено и какой путь является приемлемым, в момент принятия решения. Кодирующий агент, пытающийся выполнить push без свежих пройденных тестов, может быть направлен обратно к набору тестов вместо поиска другого способа вывода кода. Помощник, пытающийся отправить конфиденциальный файл на внешний адрес, может быть перенаправлен на внутренний ресурс. Агент меняет курс, и задача все равно выполняется. Направление и блокировка работают вместе. Жесткие правила запрета остаются для недопустимых действий. Направление обрабатывает гораздо больший набор действий, где цель легитимна, но путь неверен. Для команды безопасности это разница между контролем, которому сопротивляются разработчики, и контролем, который они почти не замечают. Это также закрывает пробел, оставляемый простым блокированием, поскольку агент, которому указали правильный путь, имеет гораздо меньше причин искать неправильный.

Переход от реактивной безопасности к проактивному контролю

Большую часть времени безопасность была реактивной по своей природе. Происходит нечто плохое. Срабатывает обнаружение. В очередь поступает оповещение. Аналитик обрабатывает его, в идеале до распространения ущерба. SOAR ускорил этот цикл, а автоматизация сделала его дешевле, но суть осталась прежней: мы ждем плохого события, а затем реагируем. Мы всегда на шаг позади. Агенты усугубляют эту модель. Агент, который удаляет базу данных за секунды, не дает времени на реагирование. К тому времени, когда оповещение попадает в очередь, результат уже достигнут. Inline Boundaries меняют эту схему. Boundary находится в пути принятия решений, поэтому опасное действие оценивается до его выполнения. Оповещение, которое вы получили бы, уже предотвращено.