Руководитель просит ИИ-агента оформить подрядчика из другой страны. Агент находит анкету, создаёт карточку в кадровой системе и отправляет документы на подпись. Все вызовы API проходят без ошибок. Задача выглядит завершённой.
Позже выясняется, что перед отправкой требовалось проверить статус подрядчика и получить согласование ответственного отдела. Технически агент сделал всё, что ему позволяли подключённые инструменты. Проблема в том, что инструменты позволяли сделать слишком много.
Успешная операция и разрешённая операция — не одно и то же. OWASP относит избыточные полномочия и действия без независимой проверки к рискам агентных систем.
Основной блок
1. Разделите задачу и полномочия
Запрос «оформи подрядчика» описывает желаемый результат. Он не даёт агенту автоматического разрешения создавать записи, менять условия договора или отправлять документы. Для каждого шага нужно определить, какие данные агент вправе прочитать и какие изменения вправе внести. Начните с перечня инструментов. Агенту, который сверяет сведения в анкете, достаточно чтения нужных записей. Возможность утверждать договор или менять платёжные реквизиты для этой задачи не требуется. OWASP рекомендует ограничивать как набор инструментов, так и полномочия каждого из них. genai.owasp.org Если агент действует по поручению сотрудника, система должна учитывать права этого сотрудника. Для фонового процесса нужна отдельная учётная запись с узкими полномочиями. Универсальный ключ с доступом ко всем данным лишает проверку прав пользователя смысла.
2. Проверяйте действие перед выполнением
В инструкцию модели полезно записать: «Не отправляй договор без согласования». Это помогает агенту соблюдать порядок работы, но не создаёт технического запрета. Проверка должна сработать и тогда, когда модель ошиблась или пропустила этап. Например, перед отправкой договора система проверяет статус подрядчика, наличие обязательных документов, право инициатора на отправку и запись о согласовании. Если одного условия нет, операция отклоняется. Агент получает причину отказа и может запросить недостающие сведения или передать задачу человеку. Проверка может находиться в кадровой системе, её API или шлюзе, через который проходит запрос. Главное — применять её к каждому действию. OWASP рекомендует проверять авторизацию в системах, выполняющих операцию, а не поручать это решение языковой модели.
3. Оставьте человеку решения с высокой ценой ошибки
Не каждому действию нужно ручное подтверждение. Агент может искать разрешённые записи, готовить черновик и собирать недостающие данные. Отправку договора, изменение реквизитов, платёж или удаление записей стоит оценивать отдельно: последствия таких действий труднее исправить. Один из вариантов — разрешить агенту подготовить операцию, но выполнять её только после подтверждения уполномоченного сотрудника. Согласование должно происходить до выполнения действия, когда ошибку ещё можно остановить. OWASP рекомендует участие человека при действиях с серьёзными последствиями.
4. Проверьте запреты до запуска
Демонстрация, в которой агент успешно завершает стандартную задачу, показывает лишь часть картины. Во время пилота предложите ему ситуации, в которых система обязана отказать: - Сотрудник без нужной роли просит утвердить договор. - Агент пытается прочитать карточку другого подразделения. - Подрядчик ещё не прошёл обязательную проверку, но агент отправляет документы. - Согласование отозвали после подготовки действия. - Подключённый документ содержит инструкцию обойти установленный порядок. Для каждого случая зафиксируйте ожидаемый отказ, сообщение агенту и запись в журнале. Повторяйте проверки после изменения инструментов, прав доступа и рабочих сценариев.
Успешный ответ API подтверждает результат вызова. Он сам по себе не подтверждает право агента выполнить операцию.
редакция Speshu.AI
Что проверить перед запуском ИИ-агента
- Задача: какие действия агент выполняет сам, а какие только готовит для человека.
- Инструменты: нет ли среди них функций, не нужных для этой задачи.
- Доступ к данным: видит ли агент только разрешённые пользователю или процессу записи
- Права на изменение: разделены ли разрешения на создание, отправку, изменение и удаление.
- Бизнес-правила: блокирует ли система операцию без обязательного согласования.
- Журнал действий: можно ли установить инициатора, инструмент, результат проверки и итог операции.
- Сценарии отказа: отклоняет ли система попытку обойти каждый критичный этап.
При оценке пилота считайте не только завершённые задачи. Отдельно смотрите, сколько действий потребовало согласования, сколько запросов было отклонено и можно ли по журналу восстановить причину каждого отказа. Эти данные покажут, как агент ведёт себя за пределами идеального сценария.
FAQ
Можно ли обеспечить соблюдение регламента одним системным промптом?
Нет. Промпт объясняет агенту порядок работы. Запрет на действие должен независимо проверяться при обращении к инструменту или корпоративной системе.
Достаточно ли выдать агенту права сотрудника, который поставил задачу?
Это отправная точка, если агент действует от имени сотрудника. Дополнительно ограничьте доступ конкретной задачей, инструментом и типом операции. Право просмотреть договор не обязательно даёт право его отправить.
Нужно ли согласовывать каждый вызов API вручную?
Нет. Уровень контроля зависит от последствий. Чтение разрешённых данных и подготовку черновика можно автоматизировать, а для платежа или юридически значимой отправки предусмотреть подтверждение.
Проверяйте и то, что агенту запрещено
Корпоративного ИИ-агента недостаточно оценивать по числу завершённых задач. Перед расширением пилота проверьте, может ли он получить лишние данные, обойти согласование или выполнить действие от имени пользователя без нужных прав. Запреты должны срабатывать независимо от того, какой путь к цели выбрала модель.