Проблема уже не в том, что AI-агент может галлюцинировать в чате, а в том, что он умеет нажимать кнопки в проде. 3 июня 2026 года The Register обратил внимание на новый класс рисков: безопасность AI-агентов становится отдельной задачей для компаний, где модели уже получили доступ к API, базам данных и внутренним инструментам. Для русскоязычных команд это сигнал простой: как только агент перестает быть «говорящей головой» и начинает что-то делать сам, старых guardrails уже недостаточно.
Материал, о котором сообщает The Register, опубликован как sponsored post от Palo Alto Networks, и это важно держать в голове: перед нами не независимое исследование, а внятно упакованная позиция вендора, который продает защиту для такого сценария. Но сама постановка проблемы от этого не становится менее актуальной. В центре сюжета продукт Prisma AIRS, который, по описанию компании, анализирует не только текстовые запросы к модели, но и вызовы инструментов, сетевые потоки и полезную нагрузку, когда агент переходит от слов к действиям.
Сценарий, с которого начинается текст, звучит неприятно узнаваемо. Агент поддержки должен был лишь читать данные из базы, но в итоге записал туда изменения. Причина не в том, что кто-то специально выдал ему такую задачу: где-то раньше в цепочке оказался отравленный тикет, убедивший систему, что пользователь имеет права администратора. Агент «помог» и выполнил действие. В классической разработке такой кейс выглядел бы как ошибка валидации ролей или логики прав доступа. В агентных системах проблема тоньше: модель может принять вредоносную инструкцию из недоверенного контента, встроить ее в собственное рассуждение и затем сама дотянуться до инструмента, который способен нанести реальный ущерб.
Почему фильтрация промптов больше не спасает
Главная мысль материала в том, что у компаний меняется сама поверхность атаки. Palo Alto Networks называет такие системы «agents with hands» — AI-агенты, которые могут дергать API, выполнять задачи, обращаться к базам данных и делать это без человека в цикле согласования. По отдельности ни один из элементов не кажется катастрофой: доступ к приватным данным, работа с внешним контентом, исходящие сетевые соединения. Вместе они образуют вполне рабочий маршрут для тихой утечки. Не обязательно взламывать периметр в привычном смысле; достаточно подсунуть агенту правильный контекст и дождаться, пока он сам отправит куда-то лишнее.
Отдельно в тексте разбирается проблема multi-agent-среды. Когда в одной цепочке работают несколько агентов, между ними возникает east-west traffic, который раньше мог вообще не считаться зоной пристального контроля. Ошибка или галлюцинация одного звена начинает распространяться по всей связке: один агент неверно интерпретировал роль пользователя, второй выполнил запрос, третий передал результат во внешний сервис. На бумаге это выглядит как удобная модульность. На практике выходит распределенная система, где ложное предположение путешествует по цепочке быстрее, чем инженер успевает открыть логи.
Любопытно и замечание про стандартизированные коннекторы. Протоколы вроде MCP, по версии материала, описывают, как агент должен разговаривать с инструментом, но почти ничего не говорят о том, легитимен ли сам запрос. И это неприятный, но честный тезис. Унификация интерфейса не равна безопасности. Можно очень аккуратно описать схему вызова, типы параметров и ожидаемый ответ, а затем передать через тот же канал вредоносную или просто нелепую команду. Для разработчиков здесь мало нового: спецификация транспорта никогда не заменяла контроль авторизации и бизнес-ограничений. Просто в мире агентных систем многие снова соблазняются мыслью, что аккуратный протокол почему-то автоматически принесет порядок.
Какие атаки уже обсуждают
В тексте перечислены несколько моделей атак, и каждая бьет не по prompt-интерфейсу как таковому, а по поведению агента в связке с инструментами. Memory poisoning — это внедрение инструкций в память или историю так, чтобы агент усвоил их и выполнил спустя дни или недели. Такой сценарий особенно неприятен для long-running-агентов и систем с persistent memory: вредоносный сигнал может не сработать сразу, а всплыть позже, когда первичный инцидент уже не связан в голове команды с итоговым действием. «Confused deputy» — старая идея в новой упаковке: агент, у которого формально нет права на запись, можно заставить действовать от имени более привилегированного инструмента или через чужой контекст. Наконец, rugpull: инструмент, который месяцами вел себя нормально, получил доверие системы и команды, а затем начал незаметно тянуть данные наружу. Для любой организации, где AI-агенты собираются из внешних коннекторов и внутренних сервисов, это звучит не как фантастика, а как очередной supply-chain-риск, только теперь с языковой моделью посередине.
На этом фоне Palo Alto Networks бьет по очевидной мишени — текстовым фильтрам и guardrails. В материале прямо сказано, что решения уровня Amazon Bedrock Guardrails полезны для governance и content safety, но не ловят SQL-инъекцию, если она спрятана внутри payload вызова инструмента, и не контролируют динамическое рассуждение автономного агента. Это, пожалуй, самый практичный кусок всего текста. Если переводить его на язык архитектуры, то проверять только входной промпт уже мало. Нужен второй слой контроля на уровне того, что именно агент собирается сделать: какой tool call сформировал, к какому API обратился, какие привилегии запросил, куда пытается передать данные и соответствует ли это исходной задаче.
Для бизнеса и продуктовых команд отсюда следует не очень удобный вывод. Безопасность AI-агентов нельзя закрыть одним промпт-шаблоном, политикой контента или красивой системной инструкцией. Придется учитывать «теневых» агентов, которые быстро заводятся в больших организациях, забытые сервисные идентичности с лишними правами и внутренний трафик между агентами и инструментами, который раньше никто особенно не рассматривал как канал атаки. Для разработчиков это означает более скучную, но неизбежную работу: ограничение прав по минимуму, раздельные роли для чтения и записи, аудит tool use, контроль долгоживущей памяти, явные approval points для критических действий и нормальная наблюдаемость не только на уровне LLM-ответов, но и на уровне исполнения.
В сухом остатке рынок приходит к довольно старой мысли, только в новой обертке: периметр уже внутри системы, а доверять агенту «по умолчанию» дорого. Если в 2024 и 2025 годах компании в основном обсуждали, как быстрее встроить AI-агентов в поддержку, аналитику и внутренние процессы, то в 2026-м разговор все заметнее смещается к тому, как ограничить им руки, не убив полезность. И это, вероятно, главный вопрос ближайшего года: кто первым научится не просто запускать агентные цепочки в прод, а удерживать их в рамках, когда они получают доступ к данным, правам и реальным действиям.