Безопасность ИИ-агентов: защитные ограничения

Автор: Ai Flowi · Опубликовано 2026-10-10

Безопасность ИИ-агентов: защитные ограничения — это меры, которые ограничивают то, что агент может принимать, выдавать или делать. Они могут включать детерминированные проверки входных данных, разрешения для инструментов, выявление нежелательного содержимого с помощью модели и проверку человеком перед действиями с существенными последствиями. Каждая мера направлена на отдельный тип сбоя; ни одна проверка не обеспечивает полной защиты.

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

На какие вопросы отвечают разные защитные ограничения?

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

По теме: Навыки ИИ-агентов.

Проверки с помощью модели в каталоге

Компонент Guardrails описан так: Проверяет входной текст на соответствие нескольким требованиям безопасности с помощью LLM. Его обязательные входы — input_text, model и enabled_guardrails. В каталоге перечислены варианты «PII», «Tokens/Passwords», «Jailbreak», «Offensive Content», «Malicious Code» и «Prompt Injection».

Дополнительные поля включают heuristic_threshold, enable_custom_guardrail и custom_guardrail_explanation. Выходы pass_result и failed_result имеют формат JSON. В экспорте не опубликованы схема их содержимого, калибровка порога или точность выявления нарушений. Не считайте положительный результат измеренной гарантией безопасности.

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

Защита инструментов и фактические разрешения

Policies требует in_tools, принимающий Tool, и model, принимающий LanguageModel. В нём перечислены policies, enabled, mode и project, а выход guarded_tools имеет тип Tool. Каталог описывает создание кода защиты инструментов на основе текстовых бизнес-политик.

Это позволяет предложить этап защиты между источником Tool и входом tools компонента Agent. Это не подтверждает полноту контроля и не заменяет разрешений служебной учётной записи используемого сервиса. Предоставьте этой записи только необходимый доступ и проверяйте запрещённые операции непосредственно на границе сервиса.

Страница о контракте инструмента описывает настройку Flow as Tool; здесь проверьте, проходит ли каждый путь к этому инструменту через защиту.

Предлагаемая граница проверки источников

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

пример конфигурации, а не зафиксированный тест

Guardrails
input_text: supply the synthetic request text
enabled_guardrails: "Prompt Injection"
model: select your configured model

Policies
in_tools: connect your separately verified read-only Tool
policies: Permit reading approved sources only. Deny edits and publishing.
enabled: true
mode: "🛡️ Guard"
model: select your configured model

Agent
tools: connect Policies.guarded_tools
system_prompt: Review source support. Return unknowns; propose no edits.

Это предлагаемые настройки и вариант подключения Tool. Совместное выполнение не было зафиксировано. Прежде чем проектировать правила маршрутизации, нужно изучить фактическое содержимое JSON-результата Guardrails. Перечисленные компоненты выявления угроз и защиты инструментов документированы в каталоге; Ai Flowi не тестировала их в производственной среде. Для доступа к модели используются ваша учётная запись провайдера и API-ключ; провайдер выставляет счёт отдельно.

По теме: Управление использованием ИИ в компании: реестр и шаблон политики.

Маршрутизация отличается от выявления нарушений

Описание интерфейса Verification Router охватывает маршрутизацию решений — отдельную задачу по отношению к проверке содержимого и авторизации доступа к ресурсам.

Валидатор входных данных вебхука фиксирует результат 28 из 28 случаев прошли проверку для своих синтетических запросов в производственной среде. Этот сценарий использует детерминированные правила JSON и ветви ответов. Результат подтверждает конфигурацию валидатора по ссылке, а не Guardrails, Policies или предлагаемую здесь архитектуру агента. Справочник маршрутизатора объясняет его интерфейс.

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

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

Граница одобрения человеком должна предотвращать преждевременные действия

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

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

Проверьте охват защищённого пути

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

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

Типичные ошибки и полезные проверки сбоев

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

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

Использование рабочего процесса

Тарифы: Go от USD8 в месяц при годовой оплате (USD10 помесячно), Plus от USD16 (USD20 помесячно), Pro 100 от USD80 (USD100 помесячно), Pro 200 от USD160 (USD200 помесячно) и Pro 500 от USD400 (USD500 помесячно), от 5,000 до 250,000 Flowi Tokens в месяц с возможностью пополнения; 1 токен за каждый запуск узла; использование сторонних API и моделей не включено.