Agent containment

Agent containment는 AI agent가 실제 파일, 코드, 네트워크, 업무 도구에 접근할 때 피해 범위를 미리 좁혀 두는 보안 설계입니다. Agent가 똑똑해질수록 할 수 있는 일도 늘어나지만, 실수·오용·공격이 났을 때 망가질 수 있는 범위도 커집니다. Containment는 이 범위를 모델의 선의나 사용자의 매번 승인에만 맡기지 않고, 실행 환경과 권한 경계로 제한하려는 접근입니다.

한 줄로 말하면

Agent containment는 agent가 무엇을 할 수 있는지보다, 문제가 생겼을 때 어디까지밖에 못 하게 막을 것인지부터 설계하는 방식입니다.

비유로 이해하기

실험실에서 위험한 물질을 다룰 때 연구자를 계속 감시하는 것만으로는 부족합니다. 실험대, 보호 장비, 밀폐 장치, 배기 시스템, 출입 권한처럼 사고가 나도 밖으로 번지지 않게 하는 구조가 필요합니다.

Agent containment도 비슷합니다.

• agent가 코드를 실행하는 공간을 sandbox나 VM으로 제한합니다.
• 파일 접근은 허용된 작업 폴더 안으로 좁힙니다.
• 네트워크는 필요한 목적지와 기능만 열어 둡니다.
• credential은 agent가 직접 읽을 수 있는 곳에 두지 않습니다.
• 외부 도구는 읽기 전용, 쓰기 가능, 승인 필요 같은 권한으로 나눕니다.

비유의 한계도 있습니다. 물리 실험실의 벽은 눈에 보이지만, agent containment의 벽은 파일 시스템, 네트워크 egress, tool proxy, session token, sandbox runtime 같은 소프트웨어 경계입니다. 그래서 “막았다”고 생각한 경계가 실제로 어떤 기능까지 허용하는지 계속 검증해야 합니다.

정확한 정의

Agent containment는 LLM agent의 행동 가능 범위를 시스템적으로 제한해, 실패나 공격이 발생했을 때 피해가 정해진 경계 안에 머물도록 만드는 보안·운영 설계입니다.

Anthropic은 Claude 제품군의 containment를 설명하면서 크게 두 접근을 구분합니다.

1. 행동 감독: agent가 어떤 행동을 하려 할 때 사람에게 승인받게 합니다.
2. 환경 제한: agent가 애초에 접근할 수 있는 파일, 네트워크, credential, 실행 환경을 제한합니다.

중요한 차이는 두 번째입니다. 사람이 매번 승인하지 않아도, agent가 접근할 수 없는 것은 실행할 수 없습니다. 예를 들어 credential이 sandbox 안에 들어오지 않으면, prompt injection이 성공하더라도 agent가 그 credential을 읽어 외부로 보내기 어렵습니다.

Containment는 보통 다음 요소를 함께 씁니다.

요소	하는 일	왜 필요한가
Sandbox / VM	실행 환경을 격리	untrusted code가 host 전체에 접근하지 못하게 함
Filesystem boundary	읽기·쓰기 가능한 경로 제한	민감한 파일이나 작업 밖 데이터 노출을 줄임
Egress control	나갈 수 있는 네트워크 제한	데이터 유출과 임의 외부 호출을 줄임
Credential separation	비밀값을 sandbox 밖에 둠	agent가 토큰을 직접 읽지 못하게 함
Tool permission	도구별 권한을 세분화	읽기와 쓰기, 조회와 실행을 구분함
Audit trail	행동 기록을 보존	사후 추적과 개선을 가능하게 함

왜 중요한가

1. Agent의 능력이 커질수록 blast radius도 커진다

짧은 답변만 만드는 챗봇은 틀린 답을 할 수는 있어도, 보통 직접 파일을 지우거나 배포를 바꾸지는 않습니다. 하지만 coding agent, research agent, 업무 자동화 agent는 shell, repository, browser, database, API, 사내 도구에 접근할 수 있습니다.

이때 위험은 “agent가 나쁜 의도를 가졌는가”만의 문제가 아닙니다. 사용자가 잘못된 요청을 할 수 있고, 모델이 상황을 잘못 이해할 수 있으며, 외부 문서나 파일에 숨은 prompt injection이 agent를 속일 수 있습니다. Containment는 이런 일이 생겨도 피해가 전체 시스템으로 번지지 않도록 좁은 방 안에 가두는 설계입니다.

2. 사람 승인만으로는 부족할 수 있다

사람에게 매번 “이 명령을 허용할까요?”라고 묻는 방식은 직관적입니다. 하지만 승인 요청이 많아질수록 사람은 피로해지고, 위험한 명령을 읽지 않고 허용할 수 있습니다. 또한 비개발자 사용자는 shell 명령이나 네트워크 요청의 위험을 정확히 판단하기 어렵습니다.

그래서 containment는 사람의 주의력에만 의존하지 않습니다. 위험한 파일은 보이지 않게 하고, 외부 전송은 막고, credential은 밖에 두며, 특정 도구는 read-only로 제한합니다. 좋은 agent 제품은 “사용자가 조심하면 안전하다”보다 “사용자가 놓쳐도 기본 경계가 버틴다”에 가까워야 합니다.

3. 승인된 도메인도 공격 표면이 될 수 있다

네트워크 egress allowlist는 흔한 방어입니다. 하지만 “이 도메인은 허용”이라는 말은 그 도메인에서 제공하는 모든 기능을 허용한다는 뜻이 될 수 있습니다. Anthropic의 사례처럼 허용된 API 도메인을 통해 파일 업로드 기능이 열려 있다면, 목적지는 맞아도 데이터 유출이 일어날 수 있습니다.

따라서 containment는 목적지 주소만 보지 말고 어떤 capability를 허용하는가를 봐야 합니다. 파일 업로드, 서버 측 fetch, write API, 외부 계정 token 사용처럼 실제 기능 단위로 위험을 나눠야 합니다.

실제 예시

Claude Code식 sandbox

개발자용 coding agent는 repository, shell, package manager에 접근해야 쓸모가 있습니다. 하지만 모든 명령을 무제한으로 허용하면 위험합니다. 그래서 workspace 안의 쓰기는 허용하되, 네트워크는 기본 차단하거나, 위험한 명령은 승인 요구로 돌리는 식의 경계가 필요합니다.

이 구조에서는 agent가 계속 작업할 수 있지만, host 전체 파일이나 외부 네트워크로 피해가 번지는 것을 줄일 수 있습니다.

장기 실행 managed agent

Managed agents에서는 brain, hands, session을 분리합니다. 여기서 hands는 실제 코드 실행과 도구 호출이 일어나는 영역입니다. 이 hands를 sandbox나 VM으로 격리하고, credential은 별도 proxy나 vault 경로로 다루면 agent runtime은 더 오래 실행되면서도 권한 경계를 유지할 수 있습니다.

이 관점에서 containment는 Loop engineering의 하위 보안 조건입니다. loop가 길어질수록 재시도, 도구 호출, session 복구가 많아지므로, 실행 경계가 흐려지면 작은 오류가 큰 사고로 커질 수 있습니다.

업무 도구와 연결된 agent

agent가 CRM, 이메일, 문서, 결제, 배포 시스템에 연결된다면 권한을 더 세밀하게 나눠야 합니다. 고객 정보를 조회하는 권한과 수정하는 권한은 다르고, 초안 작성과 실제 발송도 다릅니다. Containment는 이런 차이를 tool permission과 승인 절차로 반영합니다.

헷갈리지 말아야 할 점

• Containment는 모델 안전성의 대체물이 아닙니다. 모델이 더 안전하게 행동하도록 훈련하는 일은 중요합니다. 다만 모델 방어는 확률적이므로, 환경 경계가 함께 필요합니다.
• Sandbox가 있으면 완전히 안전하다는 뜻도 아닙니다. Sandbox 설정, mount 경로, symlink 처리, egress proxy, tool 권한 설계가 잘못되면 경계가 뚫릴 수 있습니다.
• Human-in-the-loop는 containment와 같은 말이 아닙니다. 사람 승인은 행동 감독이고, containment는 agent가 접근 가능한 환경 자체를 제한하는 쪽에 가깝습니다.
• Allowlist는 목적지가 아니라 capability 기준으로 봐야 합니다. 허용된 도메인이라도 파일 업로드나 외부 계정 token 사용 같은 기능은 별도의 공격 표면입니다.
• Containment와 감사 가능성은 함께 가야 합니다. 경계를 만들었더라도 어떤 입력, 권한, tool call이 결과를 만들었는지 남지 않으면 사후 개선이 어렵습니다.

관련 문서

• Managed agents
• Loop engineering
• AI 시스템의 감사 가능성
• Agent memory consolidation
• AI agent runtime과 AI capex cycle의 차이