How we contain Claude across products

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

Есть два основных способа это сделать.

Первый — контролировать поведение агента через человека в контуре управления. Ранее Claude Code защищал от непреднамеренных действий агента, запрашивая у пользователей разрешение на каждом шаге. Теоретически это работает, но мы обнаружили, что этот подход ненадёжен. Наша телеметрия показала, что пользователи одобряют примерно 93% запросов на разрешение. Чем больше одобрений видит пользователь, тем меньше внимания он уделяет каждому из них, со временем становясь куда менее тщательным в своём контроле. Недавно мы создали автоматический режим Claude Code, который автоматизирует более безопасные одобрения, чтобы снизить эту усталость от одобрений. Тем не менее уязвимости остаются — любая вероятностная защита имеет ненулевой процент пропусков.1

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

За последние два года мы выпустили три основных агентных продукта: claude.ai, Claude Code и Claude Cowork. Каждый обслуживает свою аудиторию и требует своей архитектуры изоляции. В этой статье мы расскажем, что выдержало проверку, что сломалось и чему мы научились в области безопасности агентов.

Три типа рисков, три компонента защиты

Риски безопасности для агентов попадают в одну из трёх категорий:

Злоупотребление со стороны пользователя: Пользователь — злонамеренно или по неосторожности — направляет агента на вредоносное действие. Это включает всё: от просьбы обойти проверку, которая кажется раздражающей, до запуска деструктивной команды, которую пользователь не понимает, до намеренного причинения вреда.

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

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

Внешние злоумышленники: Агент атакуется через внешние векторы — инструменты, файлы или сетевой доступ. Эта категория включает как инъекцию промптов, так и традиционные атаки на среду выполнения агента, уровень оркестрации или прокси.

При построении систем изоляции и защиты мы применяем защитные меры к трём основным компонентам:

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

Жёсткий периметр также позволяет ослабить надзор. Эталонный devcontainer Claude Code существует именно для того, чтобы агент мог работать без присмотра, без поэтапных одобрений.

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

Эти защитные механизмы сильны. На бенчмарке Agent Red Teaming от Gray Swan, который тестирует устойчивость к инъекции промптов, Claude Opus 4.7 удерживает успешность атак на уровне примерно 0,1% при одиночных попытках и около 5–6% после 100 адаптивных попыток. Автоматический режим Claude Code перехватывает примерно 83% чрезмерно активных действий до их выполнения. Тем не менее даже при лучших в отрасли защитных механизмах защита на уровне модели никогда не будет на 100% эффективной, поэтому она не может быть единственным рубежом.

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

Защитные механизмы должны перекрываться и дополнять друг друга. Когда защита на уровне среды недоступна, уровень модели должен компенсировать этот пробел (именно для этого предназначен автоматический режим Claude Code). Локально среда и модельные защитные механизмы могут противостоять вредоносным выходным данным инструментов, но защиту можно добавить и выше по цепочке, ограничив возможности и доступ самого инструмента.

Паттерны изоляции агентов

Сосредоточившись на уровне среды, мы описываем три паттерна изоляции и то, как они адаптированы для каждой платформы Claude — claude.ai, Claude Code и Cowork. К каждому дизайну мы пришли постепенно, найдя баланс между необходимыми возможностями агента и степенью вмешательства пользователя.

Паттерн 1: Эфемерный контейнер (выполнение кода в claude.ai)

Хотя claude.ai наиболее известен как чат-интерфейс, он также пишет и запускает код, генерирует файлы и вызывает коннекторы. Когда Claude выполняет код внутри claude.ai, он делает это в контейнере gVisor на изолированной инфраструктуре. Агент полностью серверный; никакой код не выполняется на локальной машине, а файловая система эфемерна (на уровне сессии). Радиус поражения минимален, но и потолок возможностей Claude ограничен — нет постоянного рабочего пространства и нет доступа к файловой системе пользователя.

Это также делает claude.ai объектом более традиционной модели угроз. Мы защищаем не машины пользователей от агентов, а нашу собственную инфраструктуру и каждого арендатора друг от друга. Наша работа перед запуском claude.ai была в основном посвящена традиционным задачам безопасности: конфигурации сети, внутренней аутентификации сервисов и оркестрации.

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

Паттерн 2: Песочница с человеком в контуре (Claude Code)

Claude Code работает на машине пользователя и имеет доступ к файловой системе, оболочке и сети. Без этого полезность агентов для программирования ограничена, поэтому критически важно найти способ предоставить этот доступ безопасно.

Один подход — полагаться на человека в контуре управления. Это приемлемое решение для Claude Code, потому что средний пользователь — это разработчик, знакомый со средой программирования: он может читать bash, понимает, что делает rm -rf, и уже несколько раз в неделю запускает npm install из ненадёжных источников. Всё это означает, что когда появляется диалог «разрешить это действие», пользователь с высокой вероятностью обладает экспертизой для точной оценки того, что агент пытается сделать и какой риск с этим связан. Учитывая это, Claude Code был запущен с простейшей защитой: чтение разрешено, для записи, bash и сетевого доступа требуется одобрение.

Однако, как уже упоминалось, усталость от одобрений проявилась в течение нескольких недель. По иронии, это означало, что функция, изначально предназначенная для обеспечения контроля, могла иметь обратный эффект — некоторые пользователи просто переставали обращать внимание. В качестве первого шага для предотвращения неосторожных одобрений мы выпустили песочницу на уровне ОС (Seatbelt на macOS, bubblewrap на Linux), которая укрепляет границу: чтение разрешено, запись разрешена внутри рабочего пространства, но сеть по умолчанию запрещена. Внутри песочницы агент работает практически без прерываний. Результат — сокращение запросов на разрешение на 84%, и мы открыли исходный код среды выполнения, чтобы границу можно было проверить.

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

Пропущенный риск: всё, что происходит до диалога доверия

В период с середины 2025 года по январь 2026 года мы получили сообщения об уязвимостях Claude Code через нашу программу ответственного раскрытия. Три из них эксплуатировали код, который выполняется до того, как пользователь дал согласие на что-либо. Чтобы понять, как это возможно, рассмотрим самый прямой случай: разработчик клонирует репозиторий для ревью пул-реквеста, и этот репозиторий содержит файл .claude/settings.json, определяющий хук. Поскольку Claude Code считывает настройки проекта при запуске — до отображения стандартного запроса «Доверяете ли вы этой папке?» — хук, который злоумышленник написал и закоммитил, выполнялся автоматически. Остальные случаи выглядели структурно аналогично: входные данные из ещё не доверенной директории обрабатывались до установления границы доверия.

Исправление во всех случаях имело одинаковую форму: отложить разбор и выполнение локальной конфигурации проекта до момента, когда пользователь примет запрос на доверие. Если вы строите что-то подобное, относитесь к открытию проекта, загрузке конфигурации и прослушиванию localhost так же, как к любому входящему запросу из интернета. Им не следует доверять неявно только потому, что они ощущаются локальными и поступают до того, как пользователь дал согласие.

Пропущенный риск: пользователь как вектор инъекции

В феврале 2026 года, во время контролируемого внутреннего учения по red-teaming, исследователь успешно применил фишинг против сотрудника, заставив его запустить Claude Code с вредоносным промптом. Фишинг выглядел как обычное сотрудничество — письмо «можешь запустить это для меня?» с готовым к вставке промптом — и сам промпт читался как обычные рабочие инструкции. Но где-то среди шагов настройки он мягко просил Claude прочитать ~/.aws/credentials, закодировать содержимое и отправить POST-запросом на внешний эндпоинт. При 25 повторных запусках этого промпта Claude завершил эксфильтрацию 24 раза.

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

Единственная защита, которая работает в этой ситуации, — это среда, а именно контроль исходящего трафика, блокирующий POST-запрос независимо от намерения, и границы файловой системы, которые изначально не допускают ~/.aws в зону доступа.

(Когда мы поделились рабочим промптом во внутреннем Slack для обсуждения, кто-то указал, что некоторые внутренние агенты читают Slack. Вредоносная нагрузка стала фоновой. Мы добавили канареечную строку в тред, чтобы заметить, если что-то её подхватит. В мире, где агенты читают всё, инструменты расследования тоже являются поверхностью атаки.)

Паттерн 3: Локальная виртуальная машина (Claude Cowork)

Claude Cowork работает на рабочем столе пользователя с доступом к выбранной пользователем папке рабочего пространства. Поскольку платформа предназначена для работы со знаниями в целом, а не для разработки ПО, средний пользователь с гораздо меньшей вероятностью владеет bash.

Поэтому стратегия песочницы с человеком в контуре может не подойти: от нетехнического специалиста по работе со знаниями не следует ожидать оценки bash-заклинаний вроде find . -name "*.tmp" -exec rm {} \;. Когда для одобрения исключения требуется экспертиза, которой у типичного пользователя нет, администраторы должны установить границу, которая абсолютна и действует постоянно.

Для реализации этого первая версия Claude Cowork работала внутри полноценной виртуальной машины, используя гипервизор платформы-производителя (фреймворк виртуализации Apple на macOS, HCS на Windows). У ВМ собственное ядро Linux, собственная файловая система и собственная таблица процессов. Выбранное пользователем рабочее пространство и папка .claude монтируются; ничего другого на хосте не видно. Учётные данные остаются в связке ключей хоста и никогда не попадают в гостевую машину. Такая архитектура защищает от возможности того, что Claude в какой-то момент поведёт себя несогласованно. Скомпрометированный Claude всё ещё может повредить содержимое папки рабочего пространства, поэтому архитектура спроектирована так, чтобы это было единственным, к чему он может получить доступ (пока пользователь не добавит коннекторы), и чтобы пользователь контролировал, что именно туда монтируется.

В исходной архитектуре — которую мы называем режимом полной ВМ — цикл агента работал внутри гостевой системы, и Claude выполнялся как обычный пользователь Linux, не подозревая о песочнице. Сравните это с Claude Code, где привилегированный процесс находится за пределами песочницы и решает для каждой команды, применять ли изоляцию; убедительный инъецированный промпт или усталый клик одобрения могут заставить этот процесс выполнить что-то без песочницы. В данном случае не было внешнего процесса, хранящего ключ аварийного выхода, и, следовательно, не было компонента с полномочиями предоставить исключение.

Однако вскоре мы обнаружили, что запуск всего агента в режиме полной ВМ вызывал практические проблемы: любой сбой при запуске ВМ делал Cowork непригодным к использованию. Перенос цикла агента за пределы ВМ с сохранением выполнения кода внутри неё позволил Claude по-прежнему отвечать пользователю и помогать в диагностике проблем, а не зависать на ошибке. Это изменение оказало минимальное влияние на безопасность, поскольку ВМ по-прежнему обеспечивает контроль файловой системы и сети для кода, выполняемого агентом.

Отдельно мы также вынесли локальные MCP-серверы за пределы ВМ. Работа внутри ВМ затрудняла их аудит, создавала хрупкие проблемы зависимостей при обновлении ВМ и не поддерживала MCP, требующие взаимодействия с локальными процессами, такими как базы данных — такие серверы в любом случае должны были работать на хосте. Это изменение привело Claude Cowork в соответствие с тем, как локальные MCP-серверы уже работают в Claude Desktop: они рассматриваются как любое программное обеспечение, которое пользователь может установить, а администраторам предоставляется право решать, какие локальные MCP включать (если вообще). На удалённые MCP-серверы это не влияет, поскольку они не работают на машине пользователя.

Контроль файловой системы стал ещё одним важным архитектурным решением. Claude должен иметь доступ к некоторым файлам на хосте, чтобы быть полезным, но мы хотели минимизировать радиус поражения и обеспечить прозрачность для пользователя в отношении доступа к локальным файлам. Мы обнаружили, что предложение различных режимов монтирования файлов помогает детально контролировать риск; Claude Cowork предлагает режимы «только чтение», «чтение-запись» и «чтение-запись без удаления». Один потенциальный подводный камень здесь в том, что разрешение символических ссылок должно происходить до валидации пути, а не после, иначе символическая ссылка внутри разрешённой папки может указывать за её пределы и обойти изоляцию. Для корпоративных клиентов мы позволяем администраторам управлять этим через списки разрешённых путей монтирования в настройках MDM.

Пропущенный риск: эксфильтрация через разрешённый домен

Наглядный пример эксфильтрации через разрешённый домен пришёл из стороннего раскрытия. Список разрешённых исходящих адресов Claude Cowork корректно пропускал трафик на api.anthropic.com — продукт не может работать без вызовов нашего собственного API. В данном случае вредоносный файл, помещённый в смонтированное рабочее пространство пользователя, содержал скрытые инструкции вместе с API-ключом, контролируемым злоумышленником. Claude, следуя инструкциям, прочитал другие файлы в рабочем пространстве и вызвал Files API Anthropic с ключом злоумышленника. Прокси исходящего трафика проверил адрес назначения, увидел api.anthropic.com и пропустил запрос. Файлы были загружены в аккаунт злоумышленника в Anthropic. Песочница работала идеально, и тем не менее данные были похищены.

Ранее мы концептуализировали список разрешённых адресов как фильтр назначений — нечто, сообщающее Claude, что с этими доменами можно общаться. Но лучше рассматривать его как предоставление возможностей. Каждая функция, доступная через любой домен в списке разрешённых, теперь является поверхностью атаки. Разрешение api.anthropic.com означало разрешение загрузки файлов в произвольные аккаунты Anthropic.

Мы исправили это с помощью защитного прокси типа «человек посередине» внутри ВМ, который перехватывает трафик к нашему API. Он пропускает только запросы с собственным сессионным токеном ВМ; ключ, встроенный злоумышленником, отклоняется прокси. Он также блокирует заголовки, которые могли бы активировать серверный fetch. Прокси находится внутри ВМ, а не на наших серверах, потому что только ВМ знает происхождение запроса — с точки зрения сервера запрос от Cowork неотличим от любого другого API-клиента.

Это также второй пример принципа, что программное обеспечение, которое вы создаёте сами, часто оказывается самым слабым. Гипервизор, seccomp и gVisor во всех наших продуктах были надёжны. Наш собственный прокси со списком разрешённых адресов — вот что сломалось.

Пропущенный риск: изоляция ВМ не пропустила и софт для обнаружения угроз на конечных точках

При оценке Claude Cowork корпоративные команды безопасности спрашивали: «Почему наш EDR не видит происходящее внутри?» Ответ заключался в том, что та же изоляция, которая удерживала Claude, не пропускала и хостовые системы обнаружения и реагирования на конечных точках. С точки зрения EDR, Claude Cowork — это непрозрачный процесс гипервизора. Он не может инспектировать гостевую систему.

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

Доверие к тому, что читает агент

Корпоративные клиенты часто спрашивают нас, как защитить MCP-соединения. Это хороший вопрос, но правильный вопрос шире, чем конкретно MCP. Любой внешний ресурс, предоставленный агенту, представляет два риска одновременно: риск выполнения кода в традиционном смысле цепочки поставок и вектор инъекции промптов. Традиционный аудит зависимостей (фиксация версий, проверка подписей, ревью исходного кода) решает первый, но упускает второй.

Различие между удалённым и локальным важнее, чем кажется. Локально установленный инструмент можно проверить. Вы можете прочитать код, зафиксировать версию и знать, что он не изменится без вашего ведома. Удалённый инструмент — размещённый MCP-сервер, облачный коннектор — может изменить поведение в любой момент после одобрения; ваше решение о доверии на момент установки может больше не действовать. Наш каталог коннекторов решает эту проблему через непрерывную проверку, но всё, что за его пределами, следует рассматривать как недоверенное. Сначала запустите его на тестовых данных в среде, где радиус поражения вредоносного инструмента ограничен.

Выходные данные инструмента — это поверхность атаки, даже если сам инструмент доверенный. Пример с README на GitHub, упомянутый ранее, — именно такой случай; любое сканирование входных данных, применяемое к веб-страницам, должно с той же строгостью применяться к результатам работы сетевых инструментов. Хотя это добавляет задержку и не является идеальной защитой, мы склоняемся к инспекции в реальном времени: как только отравленный ответ инструмента направил агента на эксфильтрацию данных, в логах виден лишь успешный авторизованный API-вызов. Постфактум найти следы невозможно.

В Claude Code и Claude Cowork вызовы инструментов проходят через прокси, которые обеспечивают сетевую и файловую политику и могут инспектировать возвращаемые значения до их попадания в контекст модели. Классификатор, выполняющий инспекцию, может быть небольшой быстрой моделью — ему не нужно быть тем, кто выполняет рассуждение.

Взгляд в будущее

Модели и продукты развиваются стремительно. По мере их развития риски видоизменяются и эволюционируют, и наши меры противодействия должны успевать за ними.

Отравление постоянной памяти. Доля контекста агента, сохраняющаяся между сессиями, продолжает расти — сюда входят память продукта, файлы CLAUDE.md, смонтированные рабочие пространства и директории состояния запланированных и длительно работающих агентов. Инъекция, попавшая в любой из этих элементов, перезагружается при каждом запуске агента. По мере того как всё больше состояния агента переживает сессию, мы сталкиваемся с новыми механизмами закрепления в классическом смысле пост-эксплуатации. Качественные классификаторы при запуске сессии должны стать более распространёнными.

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

Идентичность агента. Ответ Claude Cowork на вопрос идентичности агента конкретен: учётные данные остаются в связке ключей хоста, ВМ получает сессионный токен с ограниченными правами, и этот токен может быть отозван независимо от токена пользователя. Тем не менее мы начинаем разбираться с более широким вопросом кроссплатформенной идентичности агента. Должен ли агент обладать собственной субъектной идентичностью, или он должен действовать как расширение пользователя и наследовать его права? В конечном счёте ответ, вероятно, будет сочетанием обоих подходов.

По мере роста возможностей агентов поверхности атаки постоянно смещаются. Типы сбоев, с которыми мы столкнулись, скорее всего, повторятся в разных отраслях и лабораториях. Необходимы коллективные инвестиции в безопасность, специфичную для агентов — от общих бенчмарков и норм раскрытия до единых стандартов идентичности и межвендорного red-teaming. В этой статье мы сосредоточились на изоляции, но это лишь одна часть картины безопасности агентов. О вопросах управления, наблюдаемости и остальных уровнях стека см. проект NIST по идентичности и авторизации AI-агентов, руководство шести агентств по внедрению агентного ИИ под руководством австралийского ACSC совместно с CISA и британским NCSC, а также ISO/IEC 42001 — стандарт управления ИИ. Наша инициатива Glasswing — это один из вкладов, но мы рассчитываем на сотрудничество как с партнёрами, так и с конкурентами по этому критически важному вопросу.

Итоги

Если коротко, есть несколько принципов, к которым мы постоянно возвращаемся:

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

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

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

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

Благодарности

Авторы: Max McGuinness, Mikaela Grace, Jiri De Jonghe, Jake Eaton и Abel Ribbink.

Мы также благодарим Hanah Ho, Hasnain Lakhani, Pedram Navid, Molly Villagra, Maya Nielan, Akila Srinivasan, Sam Attard, Alfred Xing, Mohamad El Hajj, Gabby Curtis, David Dworken, Adam Jones, Amie Rotherham, Christian Ryan, Lucas Smedley, Brett Andrews и других за их вклад.

Отдельная благодарность нашим командам безопасности и продуктовой инженерии, а также людям и организациям, сообщившим об уязвимостях в продуктах Claude.

Примечания

Автоматический режим Claude Code делегирует одобрение команд классификатору на основе модели; он минимизирует трение (примерно 0,4% безвредных команд блокируется) ценой пропуска части рискованных (~17% чрезмерно активных действий проходят), поэтому это один из уровней эшелонированной защиты внутри песочницы, а не замена ей.