How we contain Claude across products

Twelve months ago, we'd have rejected out of hand the idea of granting Claude access sufficient to take down an internal Anthropic service. Today that level of access is routine, and Anthropic developers are more productive for it. The risk of these deployments has two components: how likely a failure is, and how much damage one could do. Progress on safeguards and model training has steadily driven down the first; the second—the theoretical blast radius—only grows as capabilities and access expand. Yet as agents become capable of doing work that once required a person or even a team, the cost of not deploying grows large enough that the risk-reward calculation tips heavily toward adoption, as long as products can be made safe. The engineering question becomes how to cap the blast radius.

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

There are broadly two ways to do this.

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

The first is to supervise the agent’s behavior via a human-in-the-loop. Claude Code previously protected against agents taking unintended actions by asking users for permission at each turn. Theoretically that works, but we’ve found the approach to be fallible. Our telemetry showed users approved roughly 93% of permission prompts. The more approvals a user sees, the less attention they pay to each, becoming over time much less diligent in their supervision. We recently built Claude Code auto mode, which automates safer approvals in order to reduce this approval fatigue. Still, vulnerabilities remain—any probabilistic defense has a non-zero miss rate.¹

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

The second approach to capping the blast radius—and the focus of much of this post—is containment. Rather than supervising what the agent does, we supervise what it’s able to do by enforcing access boundaries through, for example, sandboxes, virtual machines, and egress controls. This is where Anthropic engineering has devoted the most effort, and also where many of the most surprising security failures have occurred.

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

Over the past two years, we’ve shipped three primary agentic products: claude.ai, Claude Code, and Claude Cowork. Each serves a different audience, requiring a different containment architecture. This article shares what’s held up, what’s broken, and what we’ve learned about agent security along the way.

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

Three types of risk, three components of defense

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

Security risks to agents fall into one of three categories:

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

User misuse: A user—either maliciously or through carelessness—directs the agent to do something harmful. This includes everything from asking the agent to bypass a check they find annoying, to running a destructive command they don’t understand, to specifying intentional harm.

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

Model misbehavior: The agent takes a harmful action no one asked for. As our models have improved, they have become more aligned on most behavior evaluations, but this doesn’t mean risk necessarily shrinks. Less capable models are more likely to misread a situation and make obvious errors. More capable models make fewer mistakes, but they’re also better at finding unexpected paths to a goal, often by routing around restrictions nobody thought to write down.

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

At Anthropic, we’ve seen Claude models “helpfully” escape a sandbox in order to complete a task, examine git history to find answers to a coding test, and spontaneously identify the benchmark it was being run on in order to decrypt its answer key. Each model brings a new set of capabilities that are sometimes put to work in unexpected ways.

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

External attackers: The agent is attacked through external vectors such as tools, files, or network access. This category includes both prompt injection and conventional attacks on the agent's runtime, orchestration layer, or proxy.

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

When building containment and defense systems, we apply defenses to three main components:

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

The environment in which the agent runs. We constrain where and how an agent can act with process sandboxes, VMs, filesystem boundaries, and egress controls. The goal is to set a hard boundary on what an agent can reach. For example, if credentials never enter the sandbox, they can't be exfiltrated, regardless of whether the cause is a user, a model finding a “creative” path, or an attacker.

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

A tight perimeter also means you can relax oversight. Claude Code’s reference devcontainer exists precisely so that the agent can run unattended, without per-action approvals.

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

The model the agent consults. The mechanisms here include system prompts, classifiers, probes, and training modifications. Because models are probabilistic, these shape only what the agent tends to do, not what it is theoretically capable of doing.

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

These defenses are strong. On Gray Swan's Agent Red Teaming benchmark, which tests susceptibility to prompt injection, Claude Opus 4.7 holds attack success to roughly 0.1% on single attempts, and around 5–6% after 100 adaptive attempts. Claude Code auto mode catches roughly 83% of overeager behaviors before they execute. Yet even with best-in-class defenses, protection in the model layer will never be 100% effective, which is why it can't stand alone.

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

The external content the agent can reach. MCP servers, third-party plugins, and web search tools all feed content into the agent’s context from sources you don’t control. An audited connector isn’t the same as audited data—a GitHub connector, for instance, can load a poisoned README straight into the model’s context despite passing malware checks. Granularly limiting tool permissions can help limit the blast radius. An agent with read-only DB access, for instance, can be deployed far more broadly than one that writes to prod.

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

Defenses should overlap and complement each other. When environmental defenses aren’t available, the model layer has to pick up the slack (this is precisely what Claude Code’s auto mode is designed for). Locally, the environment and model defenses can guard against malicious tool outputs, but defenses can be added higher up the chain by limiting the tool’s capabilities and access.

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

Patterns for containing agents

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

Focusing on the environment layer, we describe three isolation patterns and how they’re tailored for each Claude platform—claude.ai, Claude Code, and Cowork. We arrived at each design gradually, after finding the balance between the capabilities we need from the agent and the degree of intervention required from the user.

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

Pattern 1: The ephemeral container (claude.ai code execution)

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

Though best known as a chat interface, claude.ai also writes and runs code, generates files, and calls connectors. When Claude runs code inside claude.ai, it does so in a gVisor container on isolated infrastructure. The agent is entirely server-side; no code runs on the local machine, and the filesystem is ephemeral (per-session). The blast radius is minimal, but so is the ceiling on what Claude can do—there's no persistent workspace and no access to the user's filesystem.

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

This also makes claude.ai subject to a more traditional threat model. We're not protecting user machines from agents; we're protecting our own infrastructure and each tenant from one another. Our pre-launch work for claude.ai was dominated by traditional security work like network configuration, internal service auth, and orchestration.

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

That work reinforced the oldest lesson in security: the weakest layer is the one you built yourself. gVisor and seccomp have been hardened against well-resourced adversaries for far longer than agentic AI has existed, so the review effort went into the newer pieces we'd built around them. We’ll come back to this later, since our custom proxy is also the piece that broke in our most consequential incident.

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

Pattern 2: The human-in-the-loop sandbox (Claude Code)

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

Claude Code runs on a user's machine and has access to their filesystem, shell, and network. Without this, coding agents have limited usefulness, so it’s imperative to find a way to grant that access safely.

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

One approach is to rely on a human-in-the-loop. This is only a tractable solution for Claude Code because the average user is a developer who’s familiar with coding environments: they can read bash, they understand what rm -rf does, and they already run npm install from untrusted sources several times a week. All that means that when an “allow this” dialog pops up, they are highly likely to have the expertise to accurately evaluate what the agent is attempting to do and the risk involved. Given this, Claude Code launched with the simplest possible defense: allow reads, require approval for write, bash, and network access.

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

However, as mentioned, approval fatigue showed up within weeks. Ironically, this meant that a feature originally designed to provide oversight could arguably have the opposite effect—some users might simply stop paying attention. As a first step to mitigate incautious approvals, we shipped an OS-level sandbox (Seatbelt on macOS, bubblewrap on Linux) that hardens the boundary: reads are allowed, writes are allowed inside the workspace, but network is denied by default. Within the sandbox, the agent runs largely without interruption. The result was an 84% reduction in permission prompts, and we open-sourced the runtime, so the boundary is auditable.

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

Our anonymized usage data also showed that experienced users auto-approve roughly twice as often as new users, but they also interrupt the agent mid-execution more frequently. Instead of gating individual steps, experienced users are more likely to supervise the agent only when it goes off track. While this may be a natural evolution in how people prefer to work with agents, this too is fallible, requiring users to be technical and attentive enough to notice drift in the first place. As model capabilities improve and agents begin writing increasingly ambitious bash, it becomes harder to notice any such drift. And as users move to multi-agent systems, this approach is also much less likely to be an effective oversight strategy.

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

Risk we missed: everything before the trust dialog

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

Between mid-2025 and January 2026, we received reports of vulnerabilities in Claude Code through our responsible disclosure program. Three exploited code that executes before the user has consented to anything. To understand how this is possible, consider the most direct case: a developer clones a repository to review a pull request, and that repository contains a .claude/settings.json which defines a hook. Because Claude Code reads project settings during startup—before presenting the standard "Do you trust this folder?" prompt—the hook the attacker had authored and committed would execute automatically. The remaining cases looked structurally similar, in which input from the not-yet-trusted directory was parsed before the trust boundary had been established.

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

The fix in each case had the same shape: defer parsing and execution of project-local configuration until after the user accepts the trust prompt. If you're building something similar, treat project-open, config-load, and localhost listeners the way you'd treat any inbound request from the internet. They shouldn’t be implicitly trusted just because they feel local and arrive before the user has consented.

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

Risk we missed: the user as an injection vector

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

In February 2026, during a controlled internal red-team exercise, a researcher successfully phished an employee into launching Claude Code with a malicious prompt. The phish looked like ordinary collaboration—a "can you run this for me?" email with a ready-to-paste prompt attached—and the prompt itself read like routine task instructions. But somewhere among the setup steps, it gently asked Claude to read ~/.aws/credentials, encode the contents, and POST them to an external endpoint. Across 25 retries of that prompt, Claude completed the exfiltration 24 times.

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

This is a direct prompt injection—the attacker's instructions arrived through the user, not through tool output or fetched content. Our model-layer defenses anchor on user intent—when the user is the one typing the instruction, there's nothing anomalous for a classifier to catch. A human contractor handed the same script would have done the same thing.

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

The only defense that holds in this situation is the environment, specifically egress controls that block the POST regardless of intent and filesystem boundaries that keep ~/.aws out of reach in the first place.

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

(When we shared the working prompt in internal Slack for discussion, someone pointed out that some internal agents read Slack. The payload was now ambient. We added a canary string to the thread so we'd notice if anything picked it up. In a world where agents read everything, the investigation tooling is also an attack surface.)

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

Pattern 3: The local VM (Claude Cowork)

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

Claude Cowork runs on a user's desktop with access to a workspace folder selected by the user. Because the platform is built for general knowledge work, not software engineering, the average user is much less likely to be fluent in bash.

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

As a result, the human-in-the-loop sandbox strategy may not transfer; a non-technical knowledge worker shouldn’t be expected to judge bash incantations such as find . -name "*.tmp" -exec rm {} \;. When approving an exception requires expertise the typical user doesn’t have, admins should set a boundary that is absolute and always-on.

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

To enable this, our first version of Claude Cowork ran inside a full virtual machine using the platform's vendor hypervisor (Apple's Virtualization framework on macOS, HCS on Windows). The VM has its own Linux kernel, its own filesystem, and its own process table. The user's selected workspace and .claude folder are mounted; nothing else on the host is visible. Credentials stay in the host's keychain and never enter the guest machine. This design protects against the possibility that Claude will, at some point, behave in a misaligned manner. A compromised Claude could still damage what's inside the workspace folder, so the architecture is designed to make sure that's the only thing it can reach (until the user adds connectors), and that the user controls what's mounted there.

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

In the original architecture—what we call full-VM mode—the agent loop itself ran inside the guest, so Claude executed as an ordinary Linux user with no awareness it was sandboxed. Compare this to Claude Code, where a privileged process sits outside the sandbox deciding per-command whether to enforce it; a persuasive injected prompt or a fatigued approval click can get that process to run something un-sandboxed. Here, there was no outer process holding an escape-hatch key, and so no component with the authority to grant an exception.

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

However, we soon realized that running the whole agent in full-VM mode caused practical problems: any failure during VM startup made Cowork unusable. Moving the agent loop outside of the VM, while keeping code execution inside of it, allowed Claude to still respond to the user and help debug issues rather than freeze on an error. This change caused minimal security impact because the VM still enforces filesystem and network controls over code executed by the agent.

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

Separately, we also moved local MCP servers outside the VM. Running them inside the VM made them harder to audit, created brittle dependency issues when the VM updated, and didn’t support MCPs that required interaction with local processes such as databases—such servers had to run on the host regardless. The change brings Claude Cowork in line with how local MCP servers already work in Claude Desktop: treating them like any software a user might choose to install and entrusting admins to decide which local MCPs to enable (if any). Remote MCP servers are unaffected since they do not run on the user's machine.

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

Filesystem controls were another important architectural choice. Claude needs to be able to access some files on the host in order to be useful, but we wanted to minimize the blast radius and provide transparency to the user about local file access. We found that offering different file-mount modes helps to granularly control risk; Claude Cowork offers read-only, read-write, and read-write-no-delete. One potential gotcha here is that symlink resolution has to happen before path validation, not after, or a symlink inside an authorized folder can point outside and escape. For enterprise customers, we allow admins to control this via mount-path allowlists in MDM settings.

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

Risk we missed: exfiltration through an approved domain

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

A clear example of exfiltration through an approved domain came from a third-party disclosure. Claude Cowork's egress allowlist correctly passed traffic to api.anthropic.com—the product can't function without calling our own API. In this case, a malicious file placed in the user's mounted workspace carried hidden instructions along with an API key controlled by the attacker. Claude, following the instructions, read other files in the workspace and called Anthropic's Files API using the attacker's key. The egress proxy checked the destination, saw api.anthropic.com, and let it through. The files were uploaded to the attacker's Anthropic account. The sandbox worked perfectly, and yet the data was exfiltrated.

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

Previously, we’d conceptualized the allowlist as a destination filter, something that told Claude these domains are okay to talk to. But it may be better conceptualized as a capability grant. Every function reachable through any domain on an allowlist is now an attack surface. Allowing api.anthropic.com meant allowing file uploads to arbitrary Anthropic accounts.

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

We fixed it using a defensive man-in-the-middle proxy inside the VM that intercepts traffic to our API. It only passes requests carrying the VM's own provisioned session token; an attacker-embedded key is rejected by the proxy. It also blocks headers that would enable server-side fetch. The proxy sits inside the VM rather than on our servers because only the VM knows provenance—from the server's perspective, a Cowork request is indistinguishable from any other API client.

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

This is also a second instance of the principle that the software you build yourself is often the weakest. The hypervisor, seccomp, and gVisor across our products have been dependable. Our custom allowlist proxy was the piece that failed.

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

Risk we missed: VM isolation kept the endpoint detection software out too

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

When evaluating Claude Cowork, enterprise security teams asked, "Why can't our EDR see inside?" The answer was that the same isolation keeping Claude contained also kept host-based endpoint detection and response out. From the EDR's perspective, Claude Cowork is an opaque hypervisor process. It can't inspect the guest.

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

Isolation reduces visibility, and opacity is problematic for teams whose compliance posture depends on endpoint visibility. Our current mitigation is to use pull-based OTLP exports that let administrators retrieve event logs after the fact, but this is not the same as live monitoring. If you're building something similar, budget for this conversation early.

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

Trusting what the agent reads

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

Enterprises often ask us how to secure MCP connections. It's a good question, but the right one is broader than MCP specifically. Any external resource provided to an agent represents two risks at once: a code execution risk, in the traditional supply-chain sense, and a prompt injection vector. Traditional dependency auditing (pinning versions, verifying signatures, reviewing source) addresses the first, but misses the second.

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

Remote versus local is more important than it seems. A locally installed tool is auditable. You can read the code, pin the version, and know it won't change under you. A remote tool—a hosted MCP server, a cloud connector—can change behavior at any point after you’ve approved it; your install-time trust decision may no longer apply. Our connector directory addresses this through ongoing review, but anything outside it should be treated as untrusted. Run it against fake data first, in an environment where the blast radius of a malicious tool is contained.

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

Tool output is an attack surface even when the tool is trusted. The GitHub README example mentioned earlier is exactly this case; any input scanning applied to web pages needs to be applied to network-enabled tool results with the same rigor. Even though this adds latency and isn't a perfect defense, we err toward live inspection: once a poisoned tool return has steered the agent into exfiltrating data, the log just shows a successful, authorized API call. There's no after-the-fact signal to find.

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

In Claude Code and Claude Cowork, tool calls route through proxies that enforce network and file policy and can inspect return values before they enter the model's context. The classifier that does the inspection can be a small, fast model; it doesn't need to be the one doing the reasoning.

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

Looking ahead

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

Models and products are advancing fast. As they do, risks morph and evolve, and our mitigations must keep pace to meet them.

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

Persistent memory poisoning. The share of agent context that persists across sessions keeps growing—this includes product memory, CLAUDE.md files, mounted workspaces, and the state directories of scheduled and long-running agents. An injection that lands in any of these is reloaded each time the agent starts. As more agent state survives the session, we are threatened by new persistence mechanisms in the classic post-exploitation sense. Good classifiers on session startup will need to become more commonplace.

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

Multi-agent trust escalation. On the one hand, sub-agents can isolate untrusted content, returning structured facts rather than raw text up to the main agent. On the other hand, this can be abused: if a sub-agent's output is treated as higher-trust than raw tool results, because such output came from "us,” a new vector for prompt injection is introduced. In multi-agent systems, there is a tradeoff between allocating differing trust levels and becoming liable to trust escalation.

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

Agent identity. Claude Cowork's answer to agent identity is concrete: credentials stay in the host keychain, the VM gets a per-session scoped-down token, and that token can be revoked independently of the user's. However, we are starting to grapple with the broader question of cross-platform agent identity. Should an agent possess its own principal identity, or should it act as an extension of the user and inherit the user’s permissions? Ultimately, the answer may be a blend of the two.

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

As agents grow more capable, attack surfaces are constantly shifting. The types of failures we’ve seen are likely to be repeated across industries and labs. We need collective investment in agent-specific security posture, from shared benchmarks and disclosure norms to common identity standards and cross-vendor red-teaming. We focus on containment in this piece, but that's only one part of the security picture for agents. For governance, observability, and the rest of the stack, see NIST's project on AI agent identity and authorization, the six-agency guidance on adopting agentic AI led by Australia's ACSC with CISA and the UK's NCSC, and ISO/IEC 42001, the AI management standard.Our Glasswing initiative is one contribution, but we look forward to working with both partners and competitors on this critical issue.

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

Summary

Итоги

In short, there are a few principles we keep returning to:

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

Design for containment at the environment layer first, then steer behavior at the model layer. Two of the incidents that taught us the most—the employee phish and the third-party allowlist disclosure—were both cases of egress, in which data left through a permitted path. In each, the model layer couldn't help; there was nothing anomalous for it to catch. The deterministic boundary is what gets hit when everything probabilistic misses.

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

Match isolation strength to the user's capacity for oversight. A developer who can read bash and a knowledge worker who can't are not running the same threat model. The question of whether a user can evaluate what an agent is about to do should help determine the containment strategy, and answering it wrong in either direction—too much friction for experts, too much trust for non-experts—is its own failure.

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

Be wary of custom components. Battle-tested hypervisors, syscall filters, and container runtimes have survived more adversarial attention than anything you'll build. Across every deployment described here, the standard primitives held while our own work around them exposed flaws.

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

Ultimately, while agents may be a new category of software, their system-level interactions are not. They still read files, open sockets, and spawn processes; this makes containment with mature tooling a crucially viable defense. The risk-reward balance of deployments will keep shifting as AI develops, but placing a hard limit on blast radius often forces that balance into the right direction.

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

Acknowledgements

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

Written by Max McGuinness, Mikaela Grace, Jiri De Jonghe, Jake Eaton, and Abel Ribbink.

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

We're also grateful to 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, and others for their contributions.

Мы также благодарим 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 и других за их вклад.

Special thanks to our security and product engineering teams, and to the individuals and organizations that have reported vulnerabilities in Claude products.

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

Footnotes

Примечания

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