Зачем каждому действию агента нужна цель?

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

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

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

Разрешения отвечают не на все вопросы

Обычная авторизация спрашивает, может ли субъект выполнить операцию над объектом, иногда при заданных условиях среды. NIST определяет управление доступом на основе атрибутов (ABAC) как оценку атрибутов субъекта, объекта, запрошенной операции и, где применимо, среды по правилам политики. Эта модель не исключает цель. Напротив, цель можно передать как атрибут действия или контекста и проверять вместе с остальными.

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

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

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

Цель должна иметь тип и выдаваться политикой, а не описываться агентом

Высказывание агента о собственном намерении не является атрибутом авторизации. Фраза «я помогаю клиенту» может быть правдоподобным объяснением, ошибочным выводом или удобной рационализацией. Среда исполнения не может установить субъективное намерение по такой фразе. Зато она может проверить связанный с политикой контекст работы и ограничить поведение его рамками.

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

Полезна аналогия с OAuth Rich Authorization Requests. RFC 9396 задаёт структуру для передачи детализированных данных авторизации вместо опоры только на широкие строки scope. Универсального поля цели он не определяет. Но принцип проектирования применим: важный контекст авторизации должен быть структурированным, машиночитаемо проверяемым и привязанным к конкретному запросу, а не выводиться из грубой метки разрешения.

Связывайте цель с графом исполнения

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

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

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

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

В журнале аудита должны быть не только ID агента и вызов инструмента. Для каждого значимого решения или эффекта следует фиксировать использованный грант цели, версию политики и релевантный результат её проверки, класс данных или возможности, при необходимости — делегировавшее рабочее задание, а также созданный эффект либо отказ. Это не доказывает, чего агент «на самом деле хотел». Но делает проверяемым организационное основание, по которому действие было разрешено.

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

Цель — дополнительное ограничение, а не короткий путь к соответствию

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

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

Операционное следствие

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

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