Разбираемся, почему одного входа в систему недостаточно для безопасной работы автономных агентов, и как выстроить надёжную защиту от дрейфа целей до отравления памяти.
Представьте: вы дали своему цифровому помощнику доступ к финансовой отчётности, чтобы он подготовил сводку. Через минуту он уже копирует тысячи файлов в общую папку, потому что «так показалось логичнее». Ужасно? А теперь умножьте это на масштаб корпорации и скорость работы нейросети. Безопасность ИИ-агентов — одна из самых горячих тем 2026 года, и она касается каждого, кто хоть раз задумывался об автоматизации. Пока одни компании героически закрывают уязвимости в AI-шлюзах, другие пытаются понять, как вообще контролировать то, что агенты делают после аутентификации. Мы разобрали несколько ключевых проблем — от критических дыр в LiteLLM до шести этапов безопасного развёртывания агентов. Спойлер: всё не так просто, как кажется.
Критическая уязвимость LiteLLM: как атака на AI-шлюз ставит под угрозу все ключи API
В мире AI-инфраструктуры случилось то, чего так боялись все, кто хоть раз настраивал LiteLLM proxy. В июне 2026 года CISA внесла уязвимость LiteLLM в свой «черный список» Known Exploited Vulnerabilities. И это не просто бюрократическая пометка — за ней стоят реальные атаки, когда злоумышленники уже вовсю долбили незакрытые дыры в дикой природе. А самое смешное (в смысле, страшное) — это то, что многие компании только сейчас начинают чесать затылки, понимая, что их любимый AI-шлюз стал дверью не к моделям, а прямо к сердцу всей безопасности.
Суть проблемы проста до безобразия. Версия LiteLLM с 1.74.2 по 1.83.6 содержит ту самую CVE-2026-42271 — инъекцию команд в двух MCP REST-эндпоинтах (/mcp-rest/test/connection и /mcp-rest/test/tools/list). Это позволяет выполнять команды прямо на хосте. И это не единичная дыра, а целая цепочка из трех CVE, которую раскопала команда Obsidian Security. Всё начинается с учетной записи по умолчанию, и любой пользователь с низкими привилегиями может проползти по ней до полного админского доступа и выполнения кода. Совокупный показатель CVSS — 9.9, то есть критический уровень. Для тех, кто не в теме: это почти максимальный балл, когда всё горит синим пламенем.
Но самое смешное — детали эксплуатации. Чтобы воспользоваться CVE-2026-42271, хватает валидного API-ключа с низкими привилегиями. А если скомбинировать её с CVE-2026-48710 (обход проверки Host-заголовка в Starlette), то атака становится возможной вообще без учетных данных. То есть любой зевака, который нашел ваш открытый прокси, может просто зайти и сказать: «А дайте-ка я тут всё посмотрю». И ему дадут.
А теперь о том, что получает злоумышленник при успешной атаке на LiteLLM Proxy. Он получает мастер-ключ шифрования и учетные данные базы данных. Это значит, что все хранящиеся секреты — ключи OpenAI, Anthropic, Azure, AWS Bedrock и других провайдеров — становятся открытой книгой. Но и это не всё. Атакующий может перехватывать промпты и ответы в реальном времени, включая персональные данные клиентов и конфиденциальные выходные данные моделей. Если ваш прокси используется как MCP-шлюз, то OAuth-токены и учетные данные инструментов тоже уходят к злоумышленнику. По данным Miggo.io, время от раскрытия уязвимости до активной эксплуатации составило всего 36 часов. Это значит, что хакеры мониторят рекомендации по безопасности куда быстрее, чем многие администраторы ставят патчи.
И чтобы добить картину: компания LiteLLM сейчас расследует предполагаемую атаку на цепочку поставок через несанкционированную публикацию вредоносных пакетов в PyPI. Похоже, учетная запись мейнтейнера была скомпрометирована. Microsoft Threat Intelligence уже отметила, что атаки на AI-инфраструктуру, включая эксплуатацию LiteLLM, становятся всё более целенаправленными: кража учетных данных, установка персистентности и даже майнинг криптовалют. В общем, если вы до сих пор не запатчили свой LiteLLM — самое время сделать это прямо сейчас, пока ваш прокси не стал бесплатным хостингом для чужого майнинга.
AI-агенты и безопасность ИИ: почему аутентификация — это не доверие
Цифры, которые заставляют задуматься
Опрос Okta 2026 года показал: только 34% руководителей признались, что их организация всегда применяет к агентному ИИ тот же уровень безопасности, что и к человеческому персоналу. Остальные 66% — либо надеются на авось, либо ещё не поняли масштаб угрозы. А вот данные Teleport 2026 (205 security-лидеров) вообще выглядят как приговор: организации, где AI-агенты имеют избыточные привилегии, сообщают о 76% инцидентов. Там, где действует принцип минимальных прав — всего 17%. Разница в 4,5 раза. И это не про теоретические риски, а про реальные утечки и поломки.
Runtime trust: доверие под микроскопом
Выход — концепция runtime trust (доверия во время выполнения). Вместо того чтобы разово проверить «кто ты» и успокоиться, система должна непрерывно следить за тем, что агент делает. Агент может легитимно залогиниться через Microsoft 365, получить доступ к ServiceNow, Salesforce, GitHub — а потом тихо уползти в сторону, не соответствующую намерениям пользователя.
Ключевые угрозы runtime, которые уже задокументированы:
- Goal drift — агент начинает с одной задачи, а потом постепенно съезжает на рельсы оптимизации, сам себе придумывая новые цели. Поручил подготовить отчёт по клиенту — а он уже лезет в конфиденциальные HR-данные, потому что «так ответ будет полнее».
- Excessive tool invocation — дёргает все доступные API подряд, потому что модель считает, что это полезно. Никто не остановит.
- Memory poisoning — атака на постоянную память агента: злоумышленник подсовывает ложные инструкции, и агент начинает действовать на основе отравленных данных.
- Context manipulation — манипуляция документами, которые агент читает, системными промптами или историей диалога. Результат — поведение, которое не закладывал разработчик.
- Multi-agent amplification — когда несколько агентов работают в связке, ошибка одного усиливается другими, и каскадный сбой рушит весь workflow.
Для систематизации этих угроз существует MITRE ATLAS — каталог тактик и техник атак на ИИ-системы. Это не просто академическая база, а рабочий инструмент: команды безопасности могут моделировать атаки, готовить сценарии реагирования и не изобретать велосипед.
Но главный вывод простой: аутентификация — это входной билет, а не гарантия безопасности. Пока доверие к агенту не проверяется в реальном времени, каждый его вызов инструмента — это потанцевать на минном поле. И статистика Okta с Teleport ясно показывает: stakes выше, чем кажется.
Шесть этапов безопасного развертывания AI-агентов: от инвентаризации до kill-пути
Инвентаризация: кто все эти люди?
Первый этап звучит скучно, но именно здесь большинство команд спотыкается. Речь идет о банальной инвентаризации. Для каждого производственного агента нужно задокументировать владельца, назначение, одобренные инструменты и стадию жизненного цикла. Кале настаивает: пропуск этого шага аукнется в самый неподходящий момент — когда во время инцидента вы потратите первый час на выяснение того, что должно было быть очевидным. Если вы не можете назвать имя ответственного за конкретного бота, считайте, что у вас его нет.
Идентичность и делегирование: не прячьтесь за чужим токеном
Второй этап — это создание отдельной идентичности агента. Мало знать, что запрос пришел от бота. Критически важно понимать контекст делегирования: кто поручил задачу, что именно поручено и к каким ресурсам агенту нужен доступ. Если этого контекста нет, вся аналитика разваливается. Действия агента, использующего токен сотрудника, будут ошибочно приписаны человеку, который, возможно, даже не в курсе, что его учетка где-то гуляет. В итоге вы получите ложные журналы аудита и полную неразбериху при разборе полетов.
Урезаем права: принцип монотонного делегирования
Как только агент получил паспорт, пора ограничить его аппетиты. Третий этап требует, чтобы доступ был жестко ограничен по времени и ресурсам, необходимым для конкретной задачи. Здесь вступает в силу принцип монотонного делегирования: каждая передача ответственности должна сохранять или уменьшать права, но никогда — увеличивать. Агент для сверки финансов должен видеть одну книгу учета, а не наследовать весь спектр доступа сотрудника, который его запустил. Иначе вы просто раздаете ключи от всех дверей первому попавшемуся скрипту.
Телеметрия: кто, что, когда и зачем
Четвертый этап — это атрибутивная телеметрия. Прежде чем автоматизировать наказания, нужно наладить учет. Каждый вызов инструмента должен быть связан с идентичностью агента, инициатором, идентификатором задачи и результатом. Без этой связки в регулируемых средах невозможно оправдать ни одно действие. Если вы не можете воспроизвести цепочку действий от начала до конца, значит, ваш контроль — фикция.
Момент истины: шлюз, который действительно работает
И только теперь, на пятом этапе, шлюз начинает приносить пользу. Имея на руках идентичность, контекст делегирования, ограниченные полномочия и телеметрию, он может принимать взвешенные решения. Например, заблокировать запись в финансовую папку, если это выходит за рамки текущей задачи, даже если у агента формально есть права на запись. Это и есть тот самый enforcement, который работает, а не просто имитирует бурную деятельность.
Kill-путь: как выключить агента навсегда
Финал — поведенческие базовые линии и kill-путь. Когда накоплено достаточно данных о том, как агент действует в норме, можно выявлять аномалии. Но главное — подготовить механизм полного отключения. Kill-путь — это не просто бан одного аккаунта. Это комплексная операция: отключение идентичности агента, инвалидация всех активных и производных учетных данных, блокировка инструментов, остановка текущих задач и изоляция рабочей нагрузки. Только такой подход гарантирует, что сбежавший бот не продолжит свою деятельность где-то на задворках сети.
В ближайшие 30 дней Кале советует не распыляться. Выберите десять производственных агентов, задокументируйте их владельцев и цели. Проверьте, может ли ваша система IAM отличить действия одного бота от другого. И попробуйте воспроизвести один завершенный агентный процесс от начала до конца, чтобы найти слабые места. Если цепочка рвется — вы знаете, что чинить. Шлюз без этого контекста — просто дорогая игрушка, которая не видит дальше собственного носа.
Управление доступом и контентом: как защитить корпоративные данные от автономных агентов
Когда речь заходит о безопасности ИИ в корпоративном контуре, мы часто повторяем старую как мир мантру: «надо просто настроить права доступа». И здесь нас поджидает главный когнитивный диссонанс: эти права придуманы для людей, а не для AI-агентов. Хизер Сейлан, CISO Box, формулирует это безжалостно: разрешения — это фундамент, но они были спроектированы под человека, который вряд ли догадается заглянуть в забытую папку десятилетней давности. Агент же, лишенный скуки и стыда, обойдёт все уголки своих привилегий, словно одержимый архивариус. Он мигом найдет устаревшие конфигурации, забытые шары и битые ссылки — и начнет активно эксплуатировать этот цифровой хлам.
Именно поэтому чистота прав доступа из разряда «хорошо бы навести порядок» превращается в вопрос жизни и смерти для корпоративных данных. Агент вскрывает все дыры, которые человек годами не замечал по принципу «не трогай — не сломается». Показательный пример приводит сама Сейлан: агент легитимно имеет доступ к финансовой папке, но кто дал ему право перетащить четыре тысячи файлов в новое место? Традиционная проверка доступа скажет: «разрешено». И только потом вы обнаружите, что весь расчетный отдел лежит в открытом доступе. Согласитесь, это уже не просто неприятность, а катастрофа уровня «сожгли серверную».
Сейлан предлагает не просто ограничить агента правами, а сделать разрешения динамическими. Доступ должен выдаваться только на время конкретного шага, под конкретный набор инструментов. Представьте: агент делает операцию и запрашивает доступ только к двум нужным функциям, как швейцарский нож, у которого лезвие выскакивает только в момент использования. Если же выдать ему весь набор инструментов сразу, радиус поражения при любой ошибке вырастает до размеров небольшого государства.
Промпты — не указ, контент — всему голова
Теперь о наивной вере в то, что достаточно прописать агенту в системном промпте «веди себя хорошо». Промпты можно изменить, в них можно внедрить вредоносные инструкции, а сам агент — перенаправить через файлы, которые он читает по пути. Сейлан уверена: устойчивые контроли должны жить не в призрачной инструкции, а на уровне вызовов инструментов и контента, с которым эти вызовы работают. Нужно заранее определить, что агенту разрешено делать, и никакой хитрый промпт не заставит его выйти за эти рамки.
И вот тут вскрывается самое больное место. Легаси-платформы для хранения контента — сетевые диски, древние ECM, простые SaaS-хранилища — совершенно не приспособлены для жизни в эпоху автономных агентов. В них нет метаданных для классификации и детальных логов, чтобы понять, что именно читал агент. Вы просто подключаете AI-коннектор к этой помойке, и получаете те же слепые зоны, только теперь они работают на скорости пулемёта. Сейлан бьет в самое сердце проблемы: «Каждое действие агента в конечном счёте сводится к контенту. Если контентный слой не может сказать, что он хранит, кому принадлежит и что не должно покидать его, под вашими контролами нет ничего».
Усугубляет картину и то, что современные агенты общаются не только с файловыми хранилищами, но и с MCP-серверами, RAG-системами, векторными базами данных и даже друг с другом. Каждая такая сущность расширяет поверхность атаки, и теперь вы должны думать о том, как защищать не просто файлы, а целую экосистему взаимодействий. Вопрос безопасности ИИ превращается из настройки «кто прочитал документ» в сложную многослойную задачу о том, как не допустить превращения благонадежного агента в неуправляемый таран, который пробьет все корпоративные периметры.
Идентичность и делегирование: как связать действия агента с человеком
Отдельная идентичность агента — это не роскошь, а фундамент, на котором строится вся безопасность ИИ. Без неё невозможно отличить действие, инициированное человеком, от того, что агент совершил автономно. Традиционные модели управления идентификацией и доступом (IAM) здесь бессильны: они видят только токен и учётную запись, но не видят контекст задачи. В результате всё, что делает агент, ошибочно приписывается сотруднику, чей токен он использует. Журналы аудита превращаются в фикцию, поведенческие профили не строятся, а путь отзыва доступа просто отсутствует.
Решение лежит на поверхности: каждому агенту нужна собственная уникальная идентичность, неразрывно связанная с человеком через контекст делегирования. Это означает, что система должна знать не только «кто» совершает действие, но и «по чьему поручению», «в рамках какой задачи» и «с какими полномочиями». Именно такой подход позволяет корректно выстроить цепочку ответственности и в случае инцидента быстро найти виновного — будь то человек или алгоритм.
Хорошая новость в том, что для этого не нужно изобретать велосипед. В большинстве организаций уже есть необходимые механизмы IAM: workload identity, token exchange, conditional access и time-bound entitlements. Вопрос лишь в том, чтобы применить их к агентам. Например, агент для сверки финансов должен получить доступ только к одной конкретной книге, а не наследовать все права сотрудника. Это и есть принцип монотонного делегирования: каждая передача полномочий должна сохранять или уменьшать права, но никогда — увеличивать их.
Особенно остро проблема стоит в многоагентных системах. Когда один агент делегирует задачу другому, критически важно передать контекст делегирования: кто инициировал цепочку, какие действия уже выполнены и с какими полномочиями. Без этого любая попытка разобраться в инциденте превращается в гадание на кофейной гуще.
Крупные вендоры уже предлагают решения для унифицированного управления идентификацией агентов. IBM и Microsoft Entra, например, развивают инструменты, которые позволяют связывать каждое действие агента с конкретным человеком через подписанные журналы аудита и обеспечивать мгновенный отзыв доступа. Это не далёкое будущее, а рабочие механизмы, которые можно внедрять уже сегодня. Вопрос лишь в том, готовы ли компании сделать этот шаг до того, как случится серьёзный инцидент.
Безопасность ИИ-агентов — это не разовая акция, а постоянный процесс. Технологии развиваются быстрее, чем мы успеваем осознать новые риски, но это не повод опускать руки. Начните с малого: проведите инвентаризацию своих агентов, настройте им отдельные идентичности и проверьте, можете ли вы проследить каждое их действие. Остальное — дело техники и времени. Будем следить за развитием событий и обязательно расскажем, что изменится в мире защиты корпоративных данных.