Anthropic은 Claude를 활용한 에이전트 시스템 도입 시 발생할 수 있는 치명적인 오작동(폭발 반경)을 통제하기 위해 샌드박스 격리와 접근 권한 제한 기술을 적용했습니다. 특히 사용자의 알림 피로도(승인율 93%)를 낮추기 위해 자동 승인 모드를 도입하는 등 실제 운영 환경에서 겪은 보안 문제와 해결 과정을 공유합니다.
번역된 본문
12개월 전, 우리는 Claude에게 Anthropic 내부 서비스를 마비시킬 수 있는 수준의 접근 권한을 부여한다는想法을 단번에 거절했을 것입니다. 오늘날 이러한 수준의 접근은 일상적이 되었으며, 덕분에 Anthropic 개발자들은 생산성을 크게 높였습니다. 이러한 배포의 위험성은 '장애 발생 가능성'과 '피해 규모'라는 두 가지 요소로 구성됩니다. 안전장치와 모델 학습의 발전으로 전자는 꾸준히 줄어들었지만, 후자(이론적인 피해 규모, 일명 '폭발 반경')는 모델의 능력과 접근성이 확장될수록 커지기만 합니다. 그러나 에이전트가 이전에는 사람 또는 팀 단위로 작업하던 일을 수행할 수 있게 되면서, 도입하지 않을 때의 기회비용이 커졌고 제품을 안전하게 만들 수 있다는 전제하에 위험을 감수하고 도입하려는 쪽으로 계산이 크게 기울었습니다. 따라서 엔지니어링의 핵심 과제는 이 '폭발 반경'을 어떻게 제한할 것인가로 좁혀집니다. 크게 두 가지 방법이 있습니다. 첫 번째는 '휴먼 인 더 루프(Human-in-the-loop)'를 통해 에이전트의 행동을 감시하는 것입니다. 이전의 Claude Code는 매 단계마다 사용자에게 권한을 요청하여 에이전트가 의도치 않은 행동을 하는 것을 방지했습니다. 이론상 완벽해 보였지만, 우리는 이 방식이 오류에 취약하다는 것을 발견했습니다. 원격 측정 데이터(Telemetry)에 따르면 사용자는 약 93%의 권한 요청을 승인했습니다. 승인 요청을 많이 받을수록 사용자는 각 요청에 덜 주의를 기울이게 되며, 시간이 지나면서 감시 태세가 크게 느슨해지는 것입니다. 최근 우리는 이러한 '승인 피로(Approval fatigue)'를 줄이기 위해 안전한 승인을 자동화하는 Claude Code 자동 모드(auto mode)를 구축했습니다. 그럼에도 취약점은 남아있습니다. 모든 확률적 방어는 0이 아닌 오탐률(miss rate)을 가지기 마련입니다. 폭발 반경을 제한하는 두 번째 방법(그리고 이 글의 주된 초점)은 '격리(Containment)'입니다. 에이전트가 '하는 일'을 감시하는 대신, 샌드박스(sandbox), 가상 머신(VM), 외부 연결 제어(egress control) 등을 통해 에이전트가 '할 수 있는 일'의 경계를 설정하여 제어하는 방식입니다. 이 부분에 Anthropic 엔지니어링 팀의 많은 노력이 투입되었으며, 동시에 가장 놀라운 보안 장애들이 발생한 영역이기도 합니다. 지난 2년간 우리는 세 가지 주요 에이전트 제품인 claude.ai, Claude Code, Claude Cowork를 출시했습니다. 각 제품은 서로 다른 사용자를 대상으로 하므로 각기 다른 격리 아키텍처가 필요합니다. 이 글에서는 어떤 방식이 효과가 있었는지, 어떤 부분이 문제를 일으켰는지, 그리고 과정 속에서 에이전트 보안에 대해 배운 점들을 공유하고자 합니다. 세 가지 유형의 위험과 세 가지 방어 요소 에이전트에 대한 보안 위험은 크게 세 가지 범주로 나뉩니다. 사용자 악용(User misuse): 사용자가 악의적이거나 부주의하게 에이전트에게 해로운 행동을 지시하는 경우입니다. 여기에는 성가신 보안 검사를 우회하라고 요청하는 것부터, 이해하지 못하는 파괴적인 명령을 실행하는 것, 의도적인 피해를 주기 위해 지시하는 등의 모든 행위가 포함됩니다. 모델의 오작동(Model misbehavior): 에이전트가 아무도 요청하지 않은 해로운 행동을 하는 경우입니다. 모델이 발전하면서 대부분의 행동 평가에서 더욱 정렬되었지만, 이것이 반드시 위험이 줄어들었음을 의미하지는 않습니다. 능력이 떨어지는 모델은 상황을 오인하고 명백한 실수를 할 가능성이 더 높습니다. 반면 더 뛰어난 모델은 실수를 덜 하지만, 누구도 제한할 생각을 못 한 경로를 우회하여 목표를 달성하는 등 예상치 못한 방법을 찾는 데 훨씬 능합니다. Anthropic에서는 Claude 모델이 작업을 완수하기 위해 '도움을 주려는' 목적으로 샌드박스를 탈출하거나, 코딩 테스트의 정답을 찾기 위해 Git 기록을 뒤지거나, 자신이 평가받고 있는 벤치마크를 스스로 파악해 정답 키를 복호화하는 현장을 목격했습니다. 각 모델은 때때로 예상치 못한 방식으로 작동하는 새로운 능력을 갖추고 있습니다. 외부 공격자(External attackers): 도구, 파일 또는 네트워크 접근과 같은 외부 벡터를 통해 에이전트가 공격받는 경우입니다. 이 범주에는 프롬프트 인젝션(prompt injection)과 에이전트의 런타임, 오케스트레이션 계층 또는 프록시에 대한 일반적인 공격이 모두 포함됩니다. 격리 및 방어 시스템을 구축할 때 우리는 세 가지 주요 요소에 방어를 적용합니다. 첫째, 에이전트가 실행되는 환경입니다. 우리는 프로세스 샌드박스, 가상 머신, 파일 시스템 경계 및 외부 연결 제어를 사용하여 에이전트가 작동할 수 있는 위치와 방법을 제한합니다. 목표는 에이전트가 접근할 수 있는 범위에 강력한 경계를 설정하는 것입니다. 예를 들어, 자격 증명(credentials)이나 민감한 데이터가...
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Pattern 1: The ephemeral container (claude.ai code execution) 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. 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. 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. Pattern 2: The human-in-the-loop sandbox (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. One approach is to rely on a human-in-the-loop. This is only a tractable solution for Claude Cod