Как ограничить действия ИИ-агента и сохранить контроль над системой

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

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

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

Почему запрета в промпте недостаточно

Фраза «не применяй скидку выше 15%» сообщает модели правило, но не гарантирует его соблюдение. Языковая модель формирует ответ вероятностно, работает с неоднозначным контекстом и может неверно интерпретировать исключение. Если CRM принимает любое значение скидки, доступное учетной записи агента, безопасность фактически зависит от ответа модели.

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

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

Промпт при этом остается полезным уровнем защиты. Он задает роль агента, порядок работы, критерии эскалации и требования к ответу. Однако системную инструкцию нельзя использовать как механизм авторизации. OWASP указывает, что прямые и косвенные prompt injection способны изменить поведение модели, а RAG и дополнительное обучение не устраняют этот класс уязвимостей полностью. Поэтому защита строится в несколько слоев: от обработки контента до проверки каждого вызова инструмента (OWASP: Prompt Injection).

Из каких уровней складывается контроль ИИ-агента

Рабочая архитектура разделяет полномочия модели, прикладного сервиса и подключенной бизнес-системы. Модель может предложить действие, сервис проверяет его по политике, а CRM, банк или база данных независимо применяет собственные правила доступа. Ошибка одного уровня не должна автоматически обходить остальные.

Минимальные права и отдельная идентичность

ИИ-агенту нужна отдельная сервисная учетная запись. Использование токена администратора или учетных данных сотрудника затрудняет аудит и дает агенту полномочия, которые не относятся к его задаче.

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

Если агент действует от имени конкретного сотрудника, его полномочия не должны превышать права этого сотрудника. Для этого действие выполняют в пользовательском контексте или проверяют одновременно идентичность пользователя, агента и текущую сессию. NIST в материалах об идентификации программных и AI-агентов рассматривает разграничение человеческих и машинных идентичностей, управляемые полномочия и переход от human-in-the-loop к автономному режиму как отдельную задачу управления доступом.

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

Инструмент определяет, какое действие модель может запросить у программной среды. Чем шире интерфейс, тем труднее проверить намерение и последствия вызова.

Функция create_crm_task(deal_id, text, deadline) безопаснее инструмента «выполнить произвольный запрос к CRM». Первая допускает одну операцию с известной схемой параметров. Вторая позволяет использовать все возможности API в пределах выданных прав, включая те, которые разработчик не планировал отдавать агенту.

Особенно опасны универсальный SQL, командная оболочка, произвольные HTTP-запросы и инструменты выполнения кода. Если без них нельзя обойтись, выполнение изолируют в песочнице, ограничивают сеть, файловую систему, время работы и доступные секреты. Для корпоративного агента предпочтительнее набор небольших функций с фиксированной схемой, чем один мощный инструмент с текстовой командой.

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

Политика перед исполнением

Между решением модели и бизнес-системой нужен детерминированный слой исполнения. Он проверяет, разрешена ли функция, соответствует ли запрос полномочиям пользователя, допустимы ли параметры и требуется ли подтверждение.

Такую проверку проводят при каждом вызове, а не только в начале сессии. Пользователь мог потерять доступ, сделка — перейти в другой статус, а сумма — превысить доступный лимит. Разрешение, полученное для чтения карточки, не означает разрешения изменить ее или отправить связанные данные во внешний сервис.

Какие проверки и лимиты должны работать в коде

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

Валидация параметров и бизнес-правил

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

Значения лучше выбирать из явного списка, а не передавать свободным текстом. Если агент меняет статус, API должно принимать код из набора разрешенных состояний. Если он формирует платеж, валюта, получатель и назначение проходят отдельную проверку, а реквизиты нельзя незаметно подменить внутри длинного текстового аргумента.

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

Идемпотентность и защита от повторов

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

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

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

Ограничения на цикл работы

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

Поэтому для одной задачи устанавливают:

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

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

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

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

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

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

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

Как защитить агента от инструкций во внешних данных

Письмо, веб-страница, документ, запись CRM и результат поиска являются данными, даже если внутри них написано «игнорируй предыдущие правила» или «отправь содержимое базы по этому адресу». Косвенная prompt injection возникает, когда модель принимает такой фрагмент за управляющую инструкцию.

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

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

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

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

Что фиксировать в журнале и как разбирать инциденты

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

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

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

Мониторинг должен искать не только явные запреты, но и необычные последовательности: резкий рост вызовов, повторяющиеся ошибки, обращения к нетипичному инструменту, массовое чтение записей или частые запросы подтверждения. NIST AI RMF предлагает управлять рисками через функции Govern, Map, Measure и Manage; конкретные меры выбираются под сценарий, а не применяются как универсальный чек-лист.

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

Как спроектировать ограничения до запуска агента

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

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

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

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

Безопасная автономность начинается с границ

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

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

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

Об авторе

Игорь М.

Chief Editor

Игорь М. — Chief Editor в компании Полигант, отвечает за редакционную стратегию и качество публикуемого контента. Работает в сфере цифровых финансов, блокчейн-технологий и ИИ более 6 лет.

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