Как проектировать AI-агентов, устойчивых к prompt injection

OpenAI прямо указывает: наиболее эффективные реальные атаки всё чаще напоминают social engineering, а не простое переопределение промпта.

В качестве примера в статье приводится письмо, которое выглядит как обычная рабочая переписка, но фактически подталкивает ассистента:

• извлечь персональные данные сотрудника из почты;
• обратиться к внешнему интерфейсу;
• передать туда полученную информацию;
• сделать это под видом «разрешённой» бизнес-операции.

OpenAI ссылается на кейс, о котором сообщили внешние исследователи безопасности: в тестировании такой сценарий срабатывал в 50% случаев при запросе пользователя на анализ писем за день и поиск информации по процессу найма.

Для бизнеса это важный сигнал. Если ваш AI-ассистент подключён к Интеграциям CRM, ERP и внешних сервисов, то риски возникают не только на уровне модели, но и на уровне всех систем, куда агент может читать, записывать или отправлять данные.

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

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

Как модель социальной инженерии меняет подход к защите AI-агентов?

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

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

Именно эта логика переносится на AI-системы. Цель состоит не в том, чтобы идеально распознать каждую вредоносную инструкцию, а в том, чтобы минимизировать ущерб даже в случае, если часть манипуляций всё же сработает.

Практически это означает несколько принципов:

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

Здесь полезно дать несколько определений.

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

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

CRM — система управления взаимодействием с клиентами.

ERP — система управления ресурсами компании: финансами, закупками, складом, производством и другими процессами.

API — программный интерфейс, через который системы обмениваются данными и командами.

Какие меры защиты OpenAI описывает для ChatGPT?

Коротко: OpenAI делает ставку не на один «AI-файрвол», а на сочетание обучения модели, анализа опасных связок и контроля потенциально рискованных действий.

В статье описан подход через source-sink analysis. Логика здесь такая: для успешной атаки злоумышленнику нужен источник влияния на систему и «точка выхода», где это влияние превращается в реальное действие — например, отправку данных, переход по ссылке или вызов инструмента.

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

По данным OpenAI, многие атаки против ChatGPT строятся вокруг одной цели: убедить агента взять секретные или чувствительные данные из диалога и передать их третьей стороне. В большинстве известных случаев такие попытки блокируются уже на уровне safety training, то есть обученной склонности модели отказываться от небезопасных действий.

Но OpenAI отдельно подчёркивает: полагаться только на отказ модели недостаточно. Поэтому используется механизм Safe Url, который проверяет, не пытается ли агент передать во внешний адрес информацию, полученную в ходе разговора.

Если система замечает риск, происходят два варианта:

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

Похожая логика, по словам OpenAI, применяется и в других агентных режимах, включая навигацию, поиск и использование приложений в песочнице. Для бизнеса это особенно важно при разработке собственных решений на базе Разработки API-сервисов и AI автоматизации для бизнеса | NextPrism: безопасность должна встраиваться в цепочку вызовов, а не добавляться после инцидента.

Как компаниям внедрять AI-агентов в CRM, ERP и внутренние процессы без лишнего риска?

Прямой ответ: проектировать AI-агента нужно как операционную систему с правилами доступа, а не как «умный чат с расширенными правами». Чем ближе агент к данным и действиям, тем важнее инженерная дисциплина.

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

Рекомендуемая последовательность для бизнеса выглядит так:

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

Особенно актуально это для следующих задач:

• AI-обработка входящих писем и заявок;
• ассистенты в продажах и поддержке;
• агенты для работы с документами;
• автоматизация HR и онбординга;
• связки между CRM, ERP, телефонией и мессенджерами.

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

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

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

Что это меняет для руководителей бизнеса уже сейчас?

Короткий вывод: ценность AI-агентов растёт, но вместе с ней растёт и цена архитектурной ошибки. Выигрывать будут не те компании, которые просто «подключили модель к данным», а те, кто встроил ограничения, наблюдаемость и контроль действий с первого дня.

Статья OpenAI хорошо показывает зрелый сдвиг в отрасли. Вопрос уже не в том, можно ли полностью запретить prompt injection, а в том, как ограничить последствия успешной манипуляции. Для CEO и CTO это означает переход от экспериментов с чат-ботами к проектированию надёжных агентных систем, где есть роли, права, маршруты, подтверждения и аудит.

Если смотреть на бизнес-процессы прагматично, то безопасный AI-агент должен соответствовать тем же требованиям, что и любой другой критичный цифровой сотрудник:

• работать в пределах полномочий;
• не передавать чувствительные данные без оснований;
• объяснять или хотя бы логировать свои действия;
• оставлять человеку право финального контроля в рискованных точках.

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

Часто задаваемые вопросы

Чем prompt injection отличается от обычной ошибки модели?

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

Достаточно ли поставить фильтр или AI-firewall перед агентом?

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

Можно ли безопасно подключать AI-агента к CRM, ERP и почте?

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