← Все статьи
Искусственный интеллект8 минут чтения

Безопасность ИИ-агентов: 7 правил перед запуском в приложении

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

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

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

Тема стала особенно заметной в сентябре 2026 года: OWASP GenAI Security Project объявил Agent Control Standard и обновлённый список рисков для LLM-приложений, а 22 сентября Palo Alto Networks представила сервис постоянной проверки систем с помощью нескольких специализированных AI-моделей. Это сигналы смещения отрасли от демонстраций к контролируемому использованию агентов в рабочих средах. Заявления поставщиков о результатах их собственных проверок следует читать как данные этих компаний, а не как независимую оценку.

OWASP: Agent Control Standard и GenAI LLM Top 10 2026, 1 сентября 2026 года

Palo Alto Networks: запуск Unit 42 Continuous Frontier AI Defense, 22 сентября 2026 года

Сначала определите, что агенту действительно нужно

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

Семь правил перед подключением агента к рабочему приложению

  • Выдайте агенту собственную техническую идентичность. Не подключайте его под общей учётной записью администратора или пользователя: каждое действие должно быть связано с отдельным сервисным аккаунтом.
  • Ограничьте набор инструментов и прав. Разрешите только нужные API-операции и нужные поля; начните с чтения. Проверяйте права на сервере при каждом запросе, а не только в интерфейсе модели.
  • Изолируйте пилот. Используйте тестовую среду и синтетические данные, ограничьте сетевые адреса, файловую систему и выполнение команд. Не выдавайте доступ к production «на время проверки».
  • Считайте промпты и найденные документы недоверенным вводом. Инструкции внутри письма, страницы или вложения не должны расширять полномочия агента. Фильтрация текста полезна, но сама по себе не заменяет контроль действий и доступа.
  • Требуйте подтверждение человека для необратимых и внешних действий. Отправка сообщения, списание средств, изменение прав, удаление или публикация должны показывать оператору конкретное действие и его параметры до подтверждения.
  • Проверяйте результат до записи. Ответ модели — это предложение, а не доверенная команда: валидируйте схему, владельца записи, допустимые значения, лимиты и повторные запросы в обычной серверной логике приложения.
  • Ведите аудит и подготовьте остановку. Записывайте инициатора, вызванный инструмент, объект, результат проверки и подтверждение пользователя; маскируйте секреты и лишние персональные данные. Настройте лимиты, оповещение, отключение инструмента и восстановление из резервной копии.

Защита от prompt injection — это архитектура, а не фильтр слов

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

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

OWASP Top 10 for Agentic Applications 2026: риски агентных приложений и ориентиры для их снижения

Как провести небольшой пилот

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

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

Что учесть при оценке разработки

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

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

Частые вопросы

Можно ли безопасно запускать ИИ-агента в приложении?

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

Нужно ли давать агенту доступ к базе данных?

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

Как защититься от prompt injection?

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

Можно ли использовать AI-агента с персональными данными?

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

С чего начать бизнесу?

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

Ноутбук с панелью разрешений и ключом безопасности рядом, без людей
Ясные права доступа и отдельный ключ помогают ограничивать действия AI-агента.

TigerNova / Практические материалы о цифровых продуктах