[Перевод] Все вызовы API успешны. Почему ИИ-агент всё равно нарушает правила?

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

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

Почему успешный вызов API ничего не говорит о соблюдении правил

Языковая модель выбирает инструмент и формирует его параметры. Программа, в которой работает агент, получает этот запрос и вызывает инструмент. Именно так разделяются роли модели и среды исполнения в документации Open Policy Agent. Допустим, агенту поручили оформить зарубежного подрядчика. Он нашёл человека в кадровой системе, создал договор и передал данные в платёжную систему. Каждый API принял запрос. Но перед заключением договора компания требует определить статус исполнителя и получить согласование ответственного специалиста. Если эти этапы контролируются только инструкцией агенту, их можно пропустить.

Здесь есть два разных вопроса:

• Технический: вправе ли агент вызвать этот API и корректны ли параметры запроса?

• Процессный: допустимо ли выполнить действие над этим объектом сейчас, с учётом его статуса и необходимых согласований?

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

Где должны находиться проверки

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

Проверку вызова инструмента можно вынести в отдельный механизм правил. Например, документация Open Policy Agent описывает схему, в которой среда исполнения спрашивает у механизма правил разрешение до запуска инструмента. Но этого недостаточно, если тот же результат достижим через другой API. Защищаемый сервис должен сам проверять действие над конкретным объектом.

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

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

Какие решения создают ложное чувство безопасности

«Мы написали правила в системном промпте». Промпт помогает агенту выбрать правильный путь, но не заменяет серверную проверку. Полученные из документов или инструментов данные тоже могут содержать инструкции, влияющие на дальнейшие действия модели. OWASP рекомендует проверять последующие вызовы в доверенном коде приложения независимо от того, как модель истолковала эти данные.

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

«У агента права сотрудника, значит, всё разрешено». Сотрудник может иметь право подготовить платёж и при этом не иметь права утвердить собственный платёж. Роль отвечает лишь на часть вопроса; решение зависит также от объекта, его текущего состояния и истории согласований.
«Скопируем все правила в отдельный ИИ-сервис». Такое решение потребует поддерживать изменения организационной структуры, полномочий и процессов сразу в нескольких местах. Сначала стоит определить владельца каждого правила и получать решение или необходимые атрибуты из авторитетной системы. Дублирование допустимо только там, где продуманы обновление, отзыв полномочий и поведение при сбое.

Как испытать агента перед запуском

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

Затем проведите испытания на обычных и запрещённых сценариях:

1. Допустимый путь: все проверки пройдены, действие выполняется и попадает в журнал.

2. Пропущенный этап: агент пытается активировать договор до обязательного согласования; система отклоняет запрос.

3. Превышение полномочий: агент обращается к записи другого подразделения; данные недоступны.

4. Изменение прав: полномочия инициатора отозваны в ходе задачи; следующий значимый вызов отклоняется.

5. Обходной маршрут: то же действие запрашивается через другой инструмент или версию API; правило продолжает действовать.

6. Недоступность механизма правил: чувствительная операция не выполняется без действительного решения.

7. Ошибочные данные: параметры корректны по формату, но противоречат состоянию договора; запрос отклоняется.

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

Вывод

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

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