Проблема безопасности, прячущаяся в ваших инструментах разработки

Давайте поговорим о том, что беспокоит меня уже несколько месяцев. Большинство команд разработки понятия не имеют, сколько AI-ассистентов сейчас работает в их сети. Cursor, Claude Code, GitHub Copilot, Gemini CLI, кастомные внутренние решения — список растёт каждый месяц. У каждого свои настройки, своя модель разрешений и своё представление о том, что считать «безопасным».

Это не теоретическая угроза. Это реальность, с которой сталкиваются компании прямо сейчас.

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

Что у Anthropic получилось правильно

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

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

Anthropic выстроили защиту в три слоя, от надёжности к вспомогательности:

1. Слой окружения — Жёсткие границы: изолированные VM, режимы монтирования файловой системы, сетевые allowlist'ы. Это фундамент.

2. Слой модели — Поведенческие ограничения: системные промпты, классификаторы, потоки одобрения. Полезно, но сами авторы признают: «никогда не бывает 100% эффективным».

3. Слой внешнего контента — Управление тем, какие данные вообще попадают к агенту. Включая аудит MCP-серверов и проверку вывода инструментов.

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

Атака, о которой никто не говорит

Абстрактные модели угроз легко игнорировать. Конкретные примеры — сложнее.

Возьмём сценарий, который исследователи безопасности воспроизводят регулярно: разработчик клонирует репозиторий, чтобы оценить open-source библиотеку. README выглядит нормально. Его проверили на малварь — всё чисто.

Но внутри README спрятаны инструкции для AI-агента. Не для человека, который читает файл — для агента, который может захватить его как контекст. Внедрённый промпт велит агенту «настроить окружение разработки», найдя файлы .env, поискав AWS-учётки и загрузив их на какой-нибудь endpoint.

Это не малварь. Это просто текст. Сканер его не замечает. Разработчик не видит. Но агент выполняет инструкции — потому что агенты именно это и делают: исполняют задачи, встроенные в контекст.

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

Почему ваш ноутбук — недостаточно

Вот неприятная правда: если агент работает в правильно настроенной песочнице, атака блокируется на сетевом уровне. curl не доходит до атакующего. Учётные данные не покидают машину.

Но вот что ещё хуже: ваша команда безопасности понятия не имеет, что это произошло.

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

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

Слепая зона MCP-серверов

Вот что удивляет большинство команд: Model Context Protocol серверы — недооценённая поверхность атаки в развёртываниях AI-агентов.

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

Проблема? Большинство команд одобряют MCP-сервер один раз и больше никогда его не аудитят. Скомпрометированный или вредоносный MCP-сервер может нанести гораздо больший урон, чем отравленный README — потому что работает на более высоком уровне привилегий и часто сохраняется между сессиями.

Ваш фреймворк управления должен обращаться с MCP-серверами как с зависимостями: аудит, версионирование, мониторинг. Агент, который может достучаться до вашей production-базы через MCP-сервер — это агент, который может эксфильтровать всю таблицу клиентов, если что-то пойдёт не так.

Что с этим реально делать

Ничего из этого не является неразрешимой задачей, но требует осмысления безопасности AI-агентов как инфраструктурной проблемы — а не проблемы инструментов разработки.

Начните со слоя окружения. Где возможно, запускайте агентов в изолированных окружениях с политикой запрета исходящих подключений по умолчанию. Разработчики могут жаловаться на трение. Меньше, чем будете жаловаться вы, когда учётки утекут.

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

Аудит ваши MCP-серверы. Составьте список всех MCP-серверов, к которым могут обращаться ваши агенты. Это как software inventory. Удалите всё, что не узнаёте или не можете проверить.

Вкладывайтесь в observability. Блокировать атаки — хорошо. Знать, что они произошли — лучше. Вашей команде безопасности нужна видимость всех агентов в организации, а не только того, что в песочнице.

Пишите политики, а не пожелания. «Будь осторожен с учётками» — это не политика безопасности. «Агентам запрещено инициировать сетевые подключения к доменам не из allowlist'а при работе с репозиториями, помеченными как внешние» — это политика безопасности. Делайте правила явными, исполняемыми и последовательными.

Итог

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

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

Ваши разработчики двигаются быстро. Убедитесь, что ваша инфраструктура успевает за ними.