Сегодня AI-агенты умеют многое: читать сайты, разбирать письма, вытаскивать факты, запускать инструменты, выполнять действия от имени пользователя. Удобно? Безусловно. Но вместе с удобством приходит и старая добрая проблема безопасности — только в новом костюме.

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

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

Prompt injection уже не тот, что раньше

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

Сейчас лобовые атаки работают хуже. Модели стали осторожнее, обучение — жёстче, защитные механизмы — взрослее. Поэтому и сами атаки поменялись. Вместо команды в духе «сделай X» злоумышленник оформляет всё как правдоподобный рабочий контекст: письмо от HR, служебную заметку, инструкцию по compliance, сообщение от финансового отдела. Всё выглядит нормально. Даже слишком нормально.

Вот в этом и подвох. Агент видит не просто текст, а текст, который имитирует легитимный бизнес-процесс. Он не «ломает» систему напрямую — он пытается её уговорить. Почти по-человечески.

Из-за этого идея «поставим AI firewall и будем классифицировать всё входящее как вредоносное или безопасное» выглядит слишком оптимистично. Красиво звучит, спору нет. Но в реальной среде такой подход часто упирается в почти неразрешимую задачу: отличить манипуляцию от правдоподобного делового текста без полного контекста. А контекста обычно как раз и не хватает.

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

Почему здесь полезно думать как о социальной инженерии

OpenAI предлагает смотреть на prompt injection не как на изолированную аномалию в тексте, а как на разновидность социальной инженерии против AI-агента. Такой взгляд многое ставит на место.

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

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

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

Отсюда и практический вывод: устойчивость к prompt injection начинается не с магического детектора, а с грамотной архитектуры AI-агентов, где недоверенный контент, чувствительные данные и опасные действия разведены по разным уровням контроля.

Что это меняет в защите AI-агентов

В ChatGPT OpenAI сочетает такой взгляд с классическими подходами security engineering — в частности, с логикой source-sink analysis. Смысл простой: для успешной атаки нужен источник влияния, и нужна точка, где это влияние превращается в риск.

Source — это недоверенный внешний контент: письмо, веб-страница, документ, заметка, комментарий. Sink — действие, которое становится опасным в неправильном контексте: отправка данных третьей стороне, переход по ссылке, вызов инструмента, изменение состояния системы, выполнение операции от имени пользователя.

Когда эти две вещи сходятся, появляется реальная уязвимость. Не раньше.

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

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

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

Это уже не просто «модель должна быть умной». Это полноценная безопасность AI-агентов на уровне архитектуры, политик и исполнения. Так надёжнее. И, честно говоря, иначе в enterprise-среде лучше не играться.

Какие принципы стоит закладывать в enterprise AI-системы

Если вы проектируете корпоративных агентов, полезно исходить из нескольких базовых принципов.

• Не доверяйте внешнему контенту по умолчанию. Письма, сайты, вложения, CRM-заметки, результаты поиска — всё это потенциально может содержать манипулятивные инструкции.
• Разделяйте чтение и действие. Агент может анализировать контент, но право отправлять данные, менять записи или обращаться к внешним системам должно контролироваться отдельно.
• Минимизируйте полномочия. Чем уже набор доступных действий и данных, тем меньше ущерб при успешной атаке.
• Добавляйте подтверждение для чувствительных операций. Особенно если речь о персональных данных, финансовых действиях, внешней отправке или изменении критичных записей.
• Изолируйте инструменты и окружения. Песочницы, ограничения сетевого доступа, allowlist-домены и контроль каналов связи сильно снижают риск.
• Логируйте и проверяйте цепочку решений. Когда агент сделал что-то странное, нужно понимать не только, что произошло, но и почему.

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

Ещё один важный слой — агентная память и RAG. Если агент умеет подтягивать знания из внешних источников или собственной памяти, нужно очень чётко отделять доверенные знания от недоверенного контента, а также контролировать, что именно может попасть обратно в решение модели. Иначе память превращается не в усилитель полезности, а в аккуратный канал заражения контекста. Такое, увы, бывает.

Что это значит для разработки AI-агентов

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

Иными словами: не спрашивайте только «распознает ли агент атаку?». Спрашивайте ещё и «что произойдёт, если не распознает?». Вот это, пожалуй, вопрос поважнее.

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

В общем, защита от prompt injection — это не один фильтр и не одна «волшебная» настройка. Это комбинация обучения модели, ограничений полномочий, контроля действий, безопасной архитектуры, изоляции инструментов и продуманного compliance-контура. Скучновато звучит? Может быть. Зато работает.

Что дальше

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

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

Если коротко: prompt injection — это уже не просто проблема текста. Это проблема доверия, полномочий и архитектуры. А такие вещи, как известно, решаются не магией, а инженерией.