Перейти к основному содержимому

Намерение — не область действия: почему контроль доступа для агентов нельзя выводить из промптов

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

Крупный план серверной стойки с сетевым оборудованием и индикаторами состояния

Предложение и его привлекательность

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

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

Проблема не в направлении. Она в том, где принимается решение.

Крупный план освещённых серверных стоек в дата-центре

Проблема замкнутого круга

Если агент объявляет своё намерение, агент является одновременно субъектом и автором собственной авторизации. Плоскость управления просят доверять описанию, созданному тем, что она контролирует. Это не граница; это зеркало.

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

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

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

Рабочая форма: скомпилировать, затем ограничить

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

Механизм состоит из четырёх частей.

Преобразование намерения в план. Возьмите заявленное намерение и преобразуйте его до выполнения в конкретный план: именованные ресурсы, именованные операции, именованные назначения. Не «доступ к CRM», а конкретные типы объектов, конкретные глаголы, конкретные цели исходящего трафика, которые требует план. Преобразование — это этап планирования, и его может выполнять отдельный компонент, не разделяющий контекст с исполняющим агентом.

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

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

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

Набросок потока управления:

намерение ──▶ планировщик ──▶ манифест (ресурсы, операции, исходящий трафик)
                          │
                          ▼
                    утверждение политики ──▶ брокер учётных данных ──▶ токен с ограниченной областью
                          │                                        │
                          ▼                                        ▼
                    запись аудита                          исполняющий агент
                                                                   │
                                          потребность в середине запуска ────────────┘
                                                │
                                                ▼
                                     новый манифест, новое утверждение

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

Что измерять

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

  • Предоставленные и использованные возможности за запуск. Сравните, что авторизовал манифест, с тем, к чему запуск действительно обращался. Большой разрыв — это долг привилегий: план слишком широк, планировщик угадывает или рабочий процесс сместился. Отслеживайте соотношение по запускам и рабочим процессам и рассматривайте расширение разрыва как сигнал ужесточить планировщик, а не расширять политику.
  • Отказы, зарегистрированные с намерением, которое их вызвало. Каждый раз, когда брокер отклоняет запрос — ресурс вне манифеста, цель исходящего трафика не указана — записывайте намерение и фрагмент плана, породивший запрос. Отказы — не шум; это карта того, где намерение и область действия расходятся. Журнал отказов, который молчит, — это политика, которая не тестируется.
  • События расширения. Считайте повторные авторизации в середине запуска по рабочим процессам. Высокая частота означает, что планировщик недостаточно разрешает; нулевая частота в разнообразных рабочих процессах может означать, что расширение поглощается молча там, где не должно.

Граница должна быть вне агента

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

Макросъёмка компонентов электронной печатной платы с микросхемами и цепями

Правило проектирования просто сформулировать и трудно соблюдать: сущность, которая решает, что агенту можно делать, не должна быть сущностью, которая описывает, что он делает. Компилируйте намерение, ограничивайте область действия, подписывайте манифест и делайте каждое расширение новым решением. Всё остальное — это промпт, одетый в политику.

ПоделитьсяXLinkedInПостоянная ссылка6 мин чтения

Связанное чтение

На какие вопросы это отвечает

Why can't an agent's stated intent be trusted at call time?

Because the agent is both the subject and the author of its own authorisation. An injected tool output can restate the intent, and the control plane has no independent basis for refusal — the same failure mode as prompt-level guardrails, where the policy lives inside the thing being policed.

What does it mean to compile intent into a scope?

A separate planner resolves the declared intent into a concrete manifest of named resources, operations, and egress targets before the run starts. A credential broker then mints short-lived tokens bounded to exactly that manifest, and the manifest is signed off by a human or a separate policy engine.

How should mid-run scope expansion be handled?

As a new authorisation event, not a continuation. The agent can request a new plan fragment, but it cannot extend its own scope; the request goes through a fresh manifest and a fresh sign-off before new credentials are issued.

What should teams measure once scopes are compiled?

The ratio of granted to exercised capabilities per run (a wide gap is privilege debt), every refusal logged with the intent that triggered it, and the rate of mid-run expansion events per workflow.