ИИ как новая поверхность атаки: реальные инциденты агентной эпохи
ИИ стал новой поверхностью атаки там, где модели получили доступ к данным, инструментам, браузеру, локальным сервисам и действиям от имени пользователя.
Проверено 3 июля 2026 года. ИИ как поверхность атаки появляется там, где модель перестаёт быть окном для текста и получает доступ к данным, файлам, браузеру, почте, репозиториям, локальным сервисам и действиям от имени пользователя. Риск рождается не из «магии модели», а из обычной инженерии: прав доступа, журналов, секретов, расширений, коннекторов и границ доверия.
Поэтому разговор про безопасность ИИ нельзя сводить к тому, «сломается ли чатбот от плохого промпта». Современный агент читает внешний контент, вызывает инструменты, работает с внутренними документами и иногда запускает команды. Если такой контур смешивает недоверенные данные с доверенными инструкциями, инцидент похож уже не на ошибочный ответ, а на действие привилегированного пользователя.
Хорошее рабочее определение такое: поверхность атаки ИИ — это все места, где модель, агент, расширение или AI-платформа соприкасаются с внешними данными, правами доступа и действиями в системе. В этот слой попадают indirect prompt injection, утечки секретов в AI-платформах, вредоносные расширения, ошибки изоляции арендаторов, supply chain в агентных навыках и слишком широкие права у инструментов.
Что изменилось по сравнению с обычным SaaS
ИИ-сервис похож на SaaS, но плотность данных в нём выше. В одном чате или логе могут оказаться фрагменты кода, клиентские данные, внутренние документы, токены, расследования службы безопасности и коммерческие планы. Ошибка в журналировании или изоляции уже затрагивает не только профиль пользователя, а рабочий контекст всей команды.
У агентных систем добавляется второй слой. Они не просто хранят данные, а действуют: открывают страницы, вызывают API, читают файлы, запускают тесты, делают pull request, отправляют письма. OWASP AI Exchange описывает для agentic AI три условия утечки данных: атакующий ввод попадает в модель, у агента есть доступ к чувствительным данным, и агент может отправить результат наружу. Если все три условия сходятся, «текст» становится управляющим воздействием.
В классическом приложении внешний текст обычно остаётся текстом. В агенте он может стать инструкцией: «прочитай файл», «вызови инструмент», «суммируй документ», «отправь результат». Поэтому старые границы вроде «localhost безопасен», «расширение установлено из магазина», «в репозитории нет вредоносного кода» или «письмо без вложения безопасно» приходится проверять заново.
Карта инцидентов: не один баг, а несколько классов риска
Исходный Habr-разбор собрал много публичных кейсов, но для редакционного вывода важнее не список имён, а повторяющиеся классы. Они показывают, где именно ИИ расширяет поверхность атаки.
| Класс атаки | Публичный пример | Что проверять в компании |
|---|---|---|
| Утечка данных AI-платформы | Wiz в январе 2025 года нашла открытую ClickHouse-базу DeepSeek с логами, историей чатов, ключами и backend-деталями. | Логи, секреты, изоляцию арендаторов, доступ к служебным БД, хранение промптов и ретеншн данных. |
| Секреты в AI-инструментах разработчиков | Hugging Face в мае 2024 года сообщила о несанкционированном доступе к Spaces secrets и отзывала часть токенов. | Где хранятся ключи Spaces, notebooks, демо-приложений, inference endpoints и webhook-интеграций. |
| Баг зависимости в массовом AI-продукте | OpenAI описала Redis bug 20 марта 2023 года: часть пользователей видела названия чужих чатов, а часть Plus-пользователей могла затронуться раскрытием платёжных данных. | Кэш, очереди, race conditions, tenant isolation, аварийное отключение функций и точность уведомлений пользователям. |
| Indirect prompt injection в агенте | Microsoft AutoJack показал, как страница в открытом вебе может стать каналом к локальному MCP/control-plane контуру агента. | Разделение недоверенного контента и команд, защиту localhost, allowlist инструментов, аутентификацию MCP/локальных сервисов. |
| Вредоносное AI-расширение | Microsoft Defender описал кампанию расширений, которые собирали ChatGPT/DeepSeek-чаты и browsing data; охват оценивался примерно в 900 000 установок. | Политику браузерных расширений, права на all sites, сбор URL, обновления расширений, корпоративный allowlist. |
Эта таблица полезна тем, что не смешивает всё в один страх. Открытая база DeepSeek — это инфраструктурная ошибка. Redis-инцидент OpenAI — баг зависимости и кэша. AutoJack — проблема доверия к локальному контуру, когда браузерный агент становится посредником. Вредоносные расширения — старая браузерная угроза, усиленная тем, что люди теперь несут в чат код, документы и рабочие секреты.
Почему prompt injection опаснее в агенте
Prompt injection в обычном чатботе часто заканчивается плохим ответом. В агенте последствия зависят от прав. OWASP Top 10 для LLM-приложений относит prompt injection к первому риску и отдельно выделяет excessive agency: слишком широкая автономия может бить по надёжности, приватности и доверию.
Слабое место не в том, что модель «непослушная». Слабое место в архитектуре, где модель одновременно читает недоверенные данные и имеет путь к действиям. Если агент суммирует страницу, в которой спрятана инструкция, а рядом у него есть доступ к файлам, почте или shell, то внешняя страница становится частью управляющего контура.
Microsoft показала этот паттерн в AutoJack. В исследовании AutoGen Studio был прототипом для экспериментов, но цепочка хорошо иллюстрирует общий риск: агент с браузером загружает страницу, страница взаимодействует с локальным control plane, а localhost перестаёт быть границей доверия. Microsoft прямо формулирует вывод: когда агент на рабочей станции может ходить в открытый веб и говорить с привилегированными локальными сервисами, защитникам нужно пересмотреть доверие к localhost.
Похожий урок даёт исследование 0Din про агентные coding tools. Там опасность не в одном видимом вредоносном файле в репозитории, а в цепочке доверенных действий: агент читает инструкции, пытается починить обычную ошибку установки и получает вредоносное поведение уже во время выполнения. Для редакции здесь важен не payload, а модель угроз: код-агент работает в среде, где есть env-переменные, ключи, локальные конфиги и сетевой доступ.
ИИ-бренд стал фишинговой и браузерной поверхностью
Есть отдельный, менее эффектный, но массовый слой: пользователь ставит «AI sidebar», «ChatGPT helper», «DeepSeek assistant» или похожее расширение, потому что такое поведение уже кажется нормальным. Microsoft Defender в марте 2026 года описал вредоносные Chromium-расширения, которые имитировали AI-assistant tools, собирали полные URL и содержимое AI-чатов, а затем отправляли данные наружу. По отчёту, кампания достигла примерно 900 000 установок, а телеметрия Microsoft видела активность более чем в 20 000 enterprise tenants.
Техника знакомая, контекст новый. Раньше расширение крало историю браузера и формы. Теперь оно может видеть промпты, ответы моделей, фрагменты кода, внутренние URL, черновики документов и переписку с AI-сервисом. Для компании такой плагин становится не «личной настройкой браузера», а неучтённым каналом утечки.
Отсюда простой вывод: политика расширений должна быть частью AI-безопасности. Нельзя защищать серверы, CI и облака, но оставлять рабочий браузер с неограниченными content scripts и правом читать все сайты. Особенно если сотрудники используют браузер как главный интерфейс к ChatGPT, Claude, Gemini, Copilot, внутренним агентам и SaaS-системам.
Что менять в практиках безопасности
ИИ как поверхность атаки не требует отдельной «магической» программы защиты. Большинство мер знакомы AppSec, DevSecOps и корпоративной безопасности, но их нужно применять к новым объектам: промптам, агентной памяти, MCP-серверам, расширениям, AI-workspace, traces и промежуточным артефактам.
- Агенты должны получать минимально необходимые права. Если агенту нужно читать документацию, ему не нужен доступ к production-секретам, платежам и удалению баз.
- Не храните секреты в контексте агента. Ключи должны жить в менеджере секретов, а не в промптах, логах, чатах, Spaces, notebooks и временных файлах.
- Разделяйте недоверенные данные и команды. Веб-страница, письмо, PDF, README и ошибка package manager должны считаться вводом, а не инструкцией к действию.
- Ограничивайте инструменты и MCP-серверы разрешённым списком. Локальный control plane должен иметь аутентификацию, журналирование и запрет на произвольный запуск команд.
- Для необратимых действий нужен human approval. Удаление данных, отправка письма, перевод денег, публикация, деплой и изменение прав не должны выполняться только из-за текста в контексте.
- Логируйте действия агента как действия автоматизации. Нужны actor, tool call, входные данные, итог, approval, источник внешнего контента и связь с пользователем.
- Проверяйте браузерные расширения. Инвентаризация, запрет неизвестных AI-sidebar, контроль прав на all sites и мониторинг подозрительных POST-запросов важны не меньше, чем проверка npm-зависимостей.
В отдельном материале Toolarium про AI Security агентных систем мы уже разбирали, почему одних prompt-level guardrails недостаточно. Здесь вывод ещё приземлённее: guardrails не заменяют архитектуру прав. Модель не должна сама решать, какие данные ей можно читать и какие операции ей можно выполнять.
Проверка тоже должна быть практической. Для agentic red teaming полезны сценарии вроде: агент читает недоверенную страницу; агент открывает репозиторий; агент обрабатывает входящее письмо; агент получает документ с вложенными инструкциями; агент вызывает MCP-сервер. Подходы к таким проверкам хорошо дополняют бенчмарки безопасности, например RIFT-Bench для AI-агентов.
Короткий ответ: почему ИИ стал новой поверхностью атаки
ИИ стал новой поверхностью атаки, потому что модели теперь подключены к рабочим данным и инструментам. Они читают недоверенный контент, действуют с правами пользователя и часто работают рядом с локальными сервисами, репозиториями, браузером и корпоративными SaaS. В такой схеме prompt injection, вредоносное расширение или утечка секрета могут привести не к плохому ответу, а к раскрытию данных, выполнению команды или разрушительному действию.
Главный практический принцип: агент должен быть спроектирован как привилегированная автоматизация, а не как «умный чат». У него должны быть минимальные права, песочница, журнал действий, явные границы между данными и командами, отдельное хранение секретов и подтверждение человеком для действий с серьёзными последствиями. Иначе обычный пользовательский ввод становится новым периметром безопасности.
