Команда Google Research опубликовала итоги Contextual Agent Privacy and Security (CAPS) Workshop — блог-пост и полностью открытый технический отчёт, в которых безопасность LLM-агентов впервые оформлена как отдельная исследовательская дисциплина с явным списком открытых задач. Главный вывод: привычные статические разрешения и всплывающие согласия не масштабируются на вероятностных агентов, а взамен предлагается «contextual security» — оценка уместности каждого действия агента в контексте до его исполнения.

image

Что произошло

5 октября 2026 года в блоге Google Research вышла публикация с итогами Contextual Agent Privacy and Security (CAPS) Workshop, который прошёл в Нью-Йорке в ноябре 2025 года. Совещание собрало более 50 исследователей из Google, Cornell Tech, UC Berkeley, University of Washington, Columbia и других организаций; итоговый технический отчёт подготовили около 60 авторов под руководством Eugene Bagdasarian и Marco Gruteser, и он выложен в открытый доступ в формате PDF. Авторы утверждают, что LLM-агенты ломают традиционную инженерию безопасности в трёх измерениях: планы на естественном языке недетерминированы и открывают поверхность для prompt injection; пути исполнения вероятностны, а не детерминированы, как у обычного кода; наконец, агент делегирует подпрограммы другим агентам, что неизбежно порождает у пользователя «consent fatigue». В качестве теоретической основы отчёт берёт концепцию Contextual Integrity Хелен Ниссенбаум и расширяет её с приватности информационных потоков на «contextual security» — уместность самих действий агента в конкретном контексте.

Контекст

Классическая модель безопасности строилась вокруг детерминированного кода: разработчик заранее описывает, что программа делает, а пользователь разово выдаёт разрешение — так работают статические permissions в обычных сервисах и языки политик вроде Cedar, CEL, Datalog и Open Policy Agent. Агенты с LLM-планировщиком в эту схему не помещаются: что именно агент сделает, определяется в рантайме на естественном языке, и заранее зафиксировать все траектории исполнения невозможно. Отсюда две известные беды: prompt injection, когда вредоносные инструкции попадают в тот же канал, которым управляется агент, и «consent fatigue» — состояние, в котором всплывающие подтверждения появляются так часто, что человек нажимает «разрешить» не глядя. Теория Ниссенбаум изначально описывала допустимость передачи информации между контекстами; авторы отчёта переносят этот аппарат с потоков данных на сами действия, добавляя агентной безопасности формальный словарь, которого у неё до сих пор не было. По сути, документ превращает набор разрозненных инцидентов с агентами в исследовательскую дисциплину: с языком описания проблем и открытым списком задач для следующих работ.

Почему это важно для индустрии

Для команд, строящих агентные системы, отчёт фактически является дорожной картой того, куда смещаются security-архитектуры Google и примыкающие исследования. Центральный архитектурный тезис: оценку уместности нужно вынести в отдельный от планировщика contextual policy engine, который до исполнения действия генерирует машиночитаемые политики онлайн и решает — пропустить, изменить, заблокировать действие или эскалировать решение пользователю. Такой движок задуман как эволюция существующих подходов на базе языков политик Cedar, CEL, Datalog и Open Policy Agent, но поверх вероятностного планировщика, а не детерминированного кода. Отчёт также фиксирует список нерешённых исследовательских задач — prompt injection, sandboxing динамических планов, emergent behavior мультиагентных систем, — на которые уже ссылаются академические и промышленные работы 2025–2026 годов, поэтому командам стоит сверять архитектуры с этим списком, а не закладывать permission-модели, которые на агентах не масштабируются. Реальное влияние пока идёт на уровне дизайн-решений: отделять guardrails от планировщика, логировать контекст действий агентов и проектировать эскалацию пользователю как отдельный интерфейсный канал, а не побочный эффект permission-диалогов.

Почему это важно для пользователей

Если вы пользуетесь coding-агентами, browsing-ассистентами или любыми инструментами, которые действуют от вашего имени, отчёт объясняет, почему бесконечные всплывающие «разрешить?» вас не защищают: при потоке таких диалогов наступает «consent fatigue», человек подтверждает не глядя — в том числе в момент, когда агент делает что-то действительно опасное. Предлагаемая замена — движок, который до исполнения сам оценивает уместность действия в контексте: например, список покупок уместно передать шопинг-ассистенту, но не родственникам, а согласие запрашивается только там, где контекст неоднозначен. Важно понимать, что это видение, а не доступная функция: опубликован исследовательский документ, и сегодня поведение продуктов не изменилось. Практическая польза для читателя — в самом отчёте, который открыт в PDF: по нему можно проверить свои сценарии — прикинуть, сколько consent-диалогов реально получает ваш агент, не наступила ли уже привычка подтверждать машинально и какие из описанных сломов относятся к вашей ситуации.

Что пока неизвестно / ограничения

Это позиционный исследовательский документ, а не работающая система: в представленных материалах нет ни одного измерения — отсутствуют attack success rate против prompt injection, частоты ложных разрешений и блокировок у движка, данные о задержке, API и прайсинг. Бенчмарков уместности поведения пока не существует: соответствующий раздел техотчёта (§10) прямо отмечен как открытый вопрос. Не решён и вопрос о защите самого contextual policy engine: без эмпирической проверки остаётся неизвестным, устойчив ли движок к манипуляции тем самым контекстом, на основании которого он признаёт действие «уместным». Поэтому трактовки отчёта как готового чертежа нового продуктового слоя или точки немедленной интеграции преждевременны: реальное влияние документа пока ограничено терминологией, картой открытых задач и дизайн-решениями, а озвученные сценарии ближайших лет — ожидания, а не подтверждённые факты.

Источники

Автор

Look at AI, редакция