Anthropic рассказала, как ограничивает Claude в агентских продуктах
Claude получает больше доступа
Anthropic описала, как меняется безопасность ИИ-агентов по мере роста их возможностей. Год назад, по словам компании, идея дать Claude доступ, достаточный для вывода из строя внутреннего сервиса Anthropic, выглядела бы неприемлемой. Теперь такой уровень доступа стал рабочим сценарием для разработчиков, а главный вопрос сместился к тому, как ограничить потенциальный ущерб.
Компания делит защиту на два подхода. Первый - человек подтверждает действия агента. Второй — среда заранее ограничивает, что агент физически может сделать: через песочницы, виртуальные машины, границы файловой системы и контроль исходящих соединений. Anthropic прямо признаёт слабое место первого подхода: пользователи Claude Code одобряли около 93% запросов на разрешение, а при большом количестве таких запросов внимание падает.
Это важная деталь для всего рынка агентских систем. Чем полезнее агент, тем больше ему нужно доступа к файлам, сети, инструментам и рабочим данным. Но чем шире доступ, тем меньше безопасность можно сводить к диалогу «разрешить / запретить».
Три продукта Claude и разные схемы изоляции
Anthropic описывает три основные архитектуры для claude.ai, Claude Code и Claude Cowork. В claude.ai выполнение кода происходит в изолированном контейнере gVisor на серверной стороне. Файловая система временная, код не запускается на компьютере пользователя, а возможности агента ограничены самой средой. Это снижает риск, но одновременно ограничивает глубину работы: у Claude нет постоянного рабочего пространства и прямого доступа к локальным файлам пользователя.
Claude Code устроен иначе. Он запускается на машине разработчика и получает доступ к файловой системе, оболочке и сети. Изначально защита строилась на разрешениях: чтение разрешено, запись, сетевой доступ и команды требуют подтверждения. Затем Anthropic добавила песочницу уровня ОС: Seatbelt на macOS и bubblewrap на Linux. В результате число запросов на разрешение снизилось на 84%, а среда выполнения была открыта как open source.
Claude Cowork рассчитан на более широкие рабочие задачи, где пользователь может не понимать команды оболочки. Для него Anthropic выбрала более жёсткую схему: запуск внутри виртуальной машины с собственным Linux-ядром, файловой системой и таблицей процессов. Пользователь выбирает рабочую папку, а остальные файлы хоста остаются недоступны; учётные данные хранятся в связке ключей хоста и не попадают внутрь гостевой системы.
Проблемы не в стандартных механизмах
Самая полезная часть публикации — не описание «лучших практик», а список мест, где защита ломалась. Anthropic пишет, что в Claude Code несколько уязвимостей возникли до появления диалога доверия к папке. Например, проект мог содержать локальную конфигурацию, которая считывалась и выполнялась до того, как пользователь подтвердил доверие к каталогу. Исправление было прямым: откладывать чтение и выполнение локальных настроек до согласия пользователя.
Другой инцидент произошёл во внутреннем red-team-тесте в феврале 2026 года. Исследователь убедил сотрудника запустить Claude Code с вредоносным промптом. В 24 из 25 попыток Claude выполнил эксфильтрацию: прочитал AWS-учётные данные, закодировал их и отправил на внешний адрес. Для классификатора это выглядело как пользовательская инструкция, а не как внешняя атака. Защита сработала бы только на уровне среды: если нужные файлы недоступны, а исходящее соединение запрещено.
В Claude Cowork компания столкнулась с другой проблемой: разрешённый домен сам стал каналом утечки. Прокси пропускал трафик к api.anthropic.com, потому что продукту нужен доступ к собственному API. Злоумышленник смог заставить агента использовать ключ атакующего и загрузить файлы в чужой аккаунт Anthropic. Песочница при этом работала, но список разрешённых доменов оказался слишком грубым инструментом.
Редакционно это выглядит как главный вывод всей публикации: граница безопасности должна описывать не только «куда можно подключаться», но и «какое действие разрешено через этот канал». Для агентских продуктов домен уже не равен безопасному направлению.
MCP и внешние инструменты
Anthropic отдельно пишет о MCP-серверах, коннекторах, веб-поиске и сторонних инструментах. Компания предлагает смотреть шире, чем на MCP как протокол: любой внешний ресурс, который попадает в контекст агента, несёт два риска — обычный риск выполнения кода и риск prompt injection, то есть скрытой инструкции для модели.
Локальный инструмент можно проверить: прочитать код, закрепить версию, ограничить изменения. Удалённый инструмент сложнее: он может изменить поведение уже после одобрения. Даже доверенный коннектор не гарантирует, что данные внутри него безопасны. Пример с GitHub README в разборе Anthropic как раз про это: файл может пройти обычные проверки, но содержать инструкцию, которая влияет на поведение агента.
Для обычного пользователя это звучит технически, но практический смысл простой. Агенту нельзя бездумно давать доступ ко всем файлам, репозиториям, почте и внутренним базам только потому, что сам инструмент выглядит проверенным. Слабым местом часто становится не подключение как таковое, а содержимое, которое агент потом прочитает.
Главная ставка Anthropic
В финале Anthropic формулирует несколько принципов: сначала проектировать ограничения среды, затем настраивать поведение модели; подбирать силу изоляции под способность пользователя контролировать агента; осторожно относиться к собственным компонентам вокруг стандартных механизмов безопасности. Компания подчёркивает, что гипервизоры, gVisor и системные фильтры показали себя надёжнее, чем кастомные прокси и логика вокруг них.
Этот разбор важен не только для продуктов Claude. Он показывает, куда движется зрелая безопасность ИИ-агентов: от надежды на «правильный ответ модели» к инженерным ограничениям, которые срабатывают даже тогда, когда модель ошиблась, пользователь устал или атакующий нашёл обходной путь.
Открытый вопрос — видимость для корпоративной безопасности. Anthropic признаёт, что изоляция виртуальной машины мешает системам EDR видеть происходящее внутри. Сейчас компания использует экспорт журналов через OTLP, но это не равно живому мониторингу. Для корпоративного рынка такая деталь может оказаться не менее важной, чем качество самой модели.
