이건 AI 코딩 도구를 쓰는 팀에게 꽤 중요한 전환점입니다. 지금까지 많은 팀은 agent 보안을 “파일 쓰기 범위”, “shell 승인”, “network egress”, “danger mode 금지” 정도로 봤습니다. 이 기준은 여전히 필요합니다. 하지만 이번 흐름은 한 단계를 더 요구합니다. agent가 직접 실행하지 않아도, agent가 남긴 설정 파일·hook·task·metadata·dependency가 다음 실행자의 입력이 될 수 있습니다. 그러면 공격면은 agent sandbox가 아니라 sandbox와 host 사이의 handoff 지점으로 이동합니다.

이 글은 Agent Sandbox Egress Policy, Repo-local Agent Policy, Agent Instruction Context Hygiene, Agent Resource Provenance Gate와 이어집니다. 핵심 질문은 “우리 도구에 sandbox가 있는가"가 아니라, agent가 영향을 준 산출물을 누가 언제 sandbox 밖에서 신뢰하는가입니다.

근거로는 Pillar Security의 2026년 7월 20일 연구 공개, BleepingComputer의 보도, 2026년 7월 6일 arXiv에 올라온 Agent Data Injection 논문, 그리고 Codex 릴리스 노트의 sandbox·approval 관련 개선 흐름을 함께 봤습니다. 각 자료가 말하는 표현은 조금 다르지만 방향은 같습니다. AI agent는 답변 생성기가 아니라 endpoint에서 파일, 명령, 도구, 권한 사이를 이어 주는 실행 주체가 되고 있습니다.

이 글에서 얻는 것

• AI 코딩 agent sandbox escape가 왜 단순한 “격리 실패"보다 넓은 문제인지 이해할 수 있습니다.
• workspace config, hook, task, virtualenv, Git metadata, Docker socket이 왜 agent handoff 공격면인지 설명할 수 있습니다.
• agent 도입 전 점검해야 할 write surface, host trust surface, approval bypass, telemetry 기준을 만들 수 있습니다.
• 개발자 PC와 CI runner에서 agent가 쓴 파일을 host 도구가 실행하기 전 어떤 gate를 둬야 하는지 정리할 수 있습니다.

핵심 개념/이슈

1) sandbox 경계는 프로세스 경계와 다르다

전통적인 sandbox 사고방식은 비교적 단순합니다. 프로세스가 어디를 읽고 쓸 수 있는지, 어떤 명령을 실행할 수 있는지, 네트워크로 어디에 나갈 수 있는지를 제한합니다. AI 코딩 agent에도 이 기준은 필요합니다. 하지만 agent는 보통 저장소 안에서 파일을 수정하도록 허용됩니다. 그리고 저장소 안의 파일은 개발 도구 생태계에서 절대 inert하지 않습니다.

예를 들어 아래 파일들은 단순 텍스트처럼 보이지만 host 도구가 해석합니다.

agent가 이 파일을 쓰는 순간에는 sandbox 안일 수 있습니다. 하지만 나중에 IDE가 프로젝트를 열거나, Git이 상태를 스캔하거나, Docker Desktop이 socket 요청을 받으면 실행 주체는 agent가 아니라 host component가 됩니다. 이게 handoff 공격면입니다.

2) prompt injection은 명령이 아니라 미래 입력을 오염시킨다

간접 prompt injection을 “README에 적힌 나쁜 문장을 모델이 따른다” 정도로만 보면 위험을 작게 봅니다. 실제 문제는 agent가 그 문장을 읽고, 저장소 안에 host가 나중에 실행할 파일을 만들 수 있다는 점입니다. 즉 공격자는 agent에게 즉시 rm -rf를 하라고 시키는 대신, 다음 IDE 실행, 다음 Git 명령, 다음 dependency install, 다음 Docker 작업에서 host가 신뢰할 입력을 심을 수 있습니다.

2026년 7월 arXiv의 Agent Data Injection 논문도 비슷한 축을 짚습니다. 공격자 제어 데이터가 instruction처럼 보이는 경우뿐 아니라, resource id, origin, tool response format 같은 신뢰 메타데이터처럼 위장될 수 있다는 점입니다. 기존 방어가 “명령문을 무시하라"에 머물면, 데이터처럼 보이는 공격은 통과할 수 있습니다.

실무적으로는 untrusted input을 두 종류로 나눠야 합니다.

• instruction injection: “이 지시를 따라라"처럼 명령으로 위장한 데이터
• data injection: “이 파일이 안전하다”, “이 origin이 내부다”, “이 tool result가 성공이다"처럼 신뢰 판단 재료로 위장한 데이터

두 번째가 더 까다롭습니다. 모델이 명령을 따른 것이 아니라, 잘못된 근거를 믿고 정상 행동을 한 것처럼 보이기 때문입니다.

3) allowlist는 command name이 아니라 invocation을 봐야 한다

이번 보도에서 특히 실무적으로 중요한 대목은 “안전한 명령"의 정의입니다. 많은 agent CLI와 IDE는 git status, git diff, git show 같은 읽기 명령을 비교적 안전하게 봅니다. 하지만 실제 위험은 명령 이름이 아니라 인자, 옵션, 환경변수, config, alias, external helper까지 포함한 invocation입니다.

운영 기준은 이렇게 바꿔야 합니다.

• git show라는 이름만으로 허용하지 않는다.
• write 가능한 옵션, output redirection, external diff/filter/helper 호출 가능성을 본다.
• command allowlist에는 arg schema와 working directory constraint를 같이 둔다.
• repo-local config가 command 동작을 바꿀 수 있으면 승인 대상으로 올린다.
• “읽기 명령"도 host config를 로드하거나 hook을 트리거하면 안전 명령이 아니다.

이 관점은 Tool Permission Manifest와 Runtime Attestation와 같습니다. 권한은 도구 이름에 붙는 것이 아니라 실제 호출 형태와 실행 환경에 붙습니다.

4) Docker socket은 sandbox 바깥의 작은 클라우드다

개발자 PC에서 Docker socket은 편리하지만 강력합니다. agent가 sandbox 안에서 Docker socket에 닿을 수 있으면, 실제 실행은 로컬 daemon이 맡습니다. 이 daemon은 sandbox와 다른 권한을 가질 수 있고, volume mount, network, privileged container, host filesystem 접근으로 이어질 수 있습니다.

그래서 agent 세션에서 Docker는 “개발 도구"가 아니라 privileged local daemon으로 분류해야 합니다. 기본 정책은 보수적으로 잡는 편이 맞습니다.

• agent 세션에서 /var/run/docker.sock 또는 Docker Desktop socket 접근 기본 차단
• container 실행이 필요하면 read-only volume, no-new-privileges, network deny부터 시작
• host path mount는 명시 allowlist 없이 금지
• --privileged, broad :rw, host network는 승인 없이는 금지
• Docker build context에는 secret, SSH key, token 파일이 포함되지 않게 .dockerignore 점검

개발 속도만 보면 번거롭습니다. 하지만 source code, SSH key, cloud token, browser session이 붙어 있는 개발자 endpoint에서 Docker socket은 사실상 작은 클라우드 관리자 권한입니다. agent가 다룰 수 있는 표면으로 그냥 열어두면 blast radius가 커집니다.

5) 패치 관리는 agent 도구에도 적용된다

AI 코딩 도구는 빠르게 업데이트됩니다. 기능 개선만큼 sandbox, approval, shell, MCP, plugin, hook 관련 보안 개선도 자주 들어갑니다. 그런데 많은 팀은 IDE plugin과 CLI를 개인 생산성 도구로 보고 버전 관리를 느슨하게 둡니다. 이제는 그렇게 보기 어렵습니다. agent CLI는 저장소를 읽고 쓰고, shell을 호출하고, MCP 서버와 secret에 접근하며, 외부 이슈와 PR 내용을 프롬프트로 가져옵니다.

의사결정 기준은 아래처럼 둘 수 있습니다.

• 인터넷에서 받은 저장소를 agent로 열어보는 개발자 PC: agent CLI/IDE patch SLO 72시간
• production secret이나 배포 권한이 있는 workstation: high severity 공지 후 24~72시간
• CI runner에서 agent 실행: 버전 pinning + 주 1회 보안 릴리스 확인
• EOL 또는 abandoned agent extension: 사용 금지 또는 격리된 실험 환경만 허용
• sandbox/approval 관련 changelog가 있으면 기능 릴리스가 아니라 보안 변경으로 triage

Dependency Update Pipeline을 애플리케이션 패키지에만 적용할 이유가 없습니다. agent 도구 자체도 개발 생산 환경의 runtime입니다.

실무 적용

1) agent write surface와 host trust surface를 교차 inventory한다

가장 먼저 할 일은 “agent가 쓸 수 있는 파일"과 “host가 자동으로 믿는 파일"을 따로 나열한 뒤 교차하는 것입니다.

agent_handoff_inventory:
  workspace_write_allowed:
    - "src/**"
    - "package.json"
    - ".vscode/**"
    - ".github/**"
    - ".venv/**"
  host_trust_surface:
    - path: ".vscode/tasks.json"
      trusted_by: "VS Code task runner"
      action: "executes commands"
      default_policy: "approval_required"
    - path: ".git/config"
      trusted_by: "git integration"
      action: "loads helpers"
      default_policy: "agent_write_denied"
    - path: "package.json"
      trusted_by: "npm/pnpm/yarn"
      action: "runs lifecycle scripts"
      default_policy: "diff_gate_required"

출발 기준은 간단합니다. host가 자동 실행, 자동 로드, 자동 스캔, credential 접근, 외부 네트워크 호출을 할 수 있는 파일은 agent가 마음대로 쓰지 못하게 합니다. 꼭 수정해야 한다면 task id, diff, reviewer approval을 남깁니다.

2) repo-local policy에 금지 파일과 승인 파일을 명시한다

저장소마다 위험 파일은 다릅니다. Node 프로젝트는 package.json scripts와 lockfile이 중요하고, Python 프로젝트는 virtualenv, pyproject, tox/nox config가 중요합니다. VS Code를 많이 쓰면 .vscode/**가 중요하고, Kubernetes 팀은 Helm chart와 deploy script가 곧 production 경로입니다.

repo-local policy 예시는 이렇게 둘 수 있습니다.

agent_policy:
  denied_writes:
    - ".git/**"
    - ".venv/**"
    - "**/site-packages/**"
    - ".ssh/**"
    - ".env*"
  approval_required_writes:
    - ".vscode/**"
    - ".github/workflows/**"
    - "package.json"
    - "pnpm-lock.yaml"
    - "Dockerfile"
    - "docker-compose*.yml"
    - "scripts/**"
  safe_default:
    - "src/**"
    - "docs/**"
    - "tests/**"

중요한 것은 policy가 문서에만 있으면 부족하다는 점입니다. 가능한 경우 agent tool 권한, pre-commit hook, CI linter, IDE setting으로 강제해야 합니다. 최소한 PR 리뷰에서 agent가 수정한 위험 파일을 자동 라벨링해야 합니다.

3) host handoff gate를 만든다

agent가 파일을 수정한 뒤 host component가 그 파일을 실행하기 전에 한 번 멈춰야 합니다. 이 gate는 거창한 제품일 필요가 없습니다. 작은 팀이라면 아래 세 가지부터 시작해도 효과가 큽니다.

• IDE task, hook, package script 실행 전 “최근 agent가 이 파일을 수정했는가” 확인
• Docker build/run 전 build context와 volume mount diff 확인
• Git 명령 실행 전 repo-local config, hooks, fsmonitor, external helper 변경 확인

게이트 통과 기준은 숫자로 둡니다.

• agent가 수정한 executable/config 파일은 24시간 동안 high-risk로 표시
• high-risk 파일 실행은 reviewer 1명 또는 owner approval 필요
• CI에서 위험 파일 변경 PR은 최소 1개 이상의 sandboxed smoke 통과
• host에서 실행된 agent-influenced command는 command, args, cwd, env redaction, source file hash를 audit log에 남김

이런 증거가 있어야 사고 후 “agent가 무엇을 썼고, host가 무엇을 실행했는가"를 복원할 수 있습니다. 이 부분은 Execution Receipt와 직접 이어집니다.

4) 개발자 endpoint를 agent endpoint로 다시 분류한다

AI 코딩 도구가 깔린 개발자 PC는 더 이상 단순한 편집기가 아닙니다. source code, local secret, cloud CLI, browser session, package publish token, SSH key가 있는 환경에서 agent가 읽고 쓰고 실행합니다. 그래서 security baseline도 바뀌어야 합니다.

우선순위는 다음과 같습니다.

1. production 권한이 있는 개발자부터 agent tool 버전, sandbox mode, approval mode, MCP server, plugin 목록을 inventory한다.
2. Docker socket, local database admin, cloud CLI credential, package registry token 접근을 분리한다.
3. untrusted repo를 열 때는 별도 OS user, devcontainer, VM, 또는 disposable workspace를 쓴다.
4. agent 로그에는 secret 원문이 남지 않게 하고, 보존 기간을 정한다.
5. agent가 생성한 파일과 사람이 직접 쓴 파일을 PR metadata에서 구분한다.

모든 개발자를 감시하자는 이야기가 아닙니다. agent가 endpoint actor가 되었다면, endpoint risk model에 포함해야 한다는 뜻입니다.

트레이드오프/주의점

첫째, 보안을 이유로 agent를 전부 막으면 팀은 비공식 도구를 씁니다. 현실적인 방향은 사용 금지가 아니라 tiering입니다. 문서 요약, 테스트 생성, refactor 제안처럼 위험이 낮은 작업은 넓게 열고, hook/config/Docker/CI/secret/write-capable MCP가 섞이는 작업은 승인과 격리를 붙입니다.

둘째, allowlist를 너무 좁게 잡으면 생산성이 급격히 떨어집니다. 하지만 command name allowlist만으로는 충분하지 않습니다. 현실적인 절충은 위험도가 높은 invocation만 잡는 것입니다. 예를 들어 git diff, git status는 허용하되, repo config나 external helper가 최근 변경됐으면 다시 승인받게 하는 식입니다.

셋째, sandbox 벤더 패치만 기다리면 늦습니다. 이번 흐름의 핵심은 벤더별 버그 하나가 아니라 반복되는 구조입니다. workspace config가 executable code가 되는 생태계에서는 새로운 우회가 계속 나올 수 있습니다. 팀이 통제할 수 있는 것은 agent가 쓴 파일의 provenance와 host handoff 지점입니다.

넷째, telemetry는 privacy와 균형이 필요합니다. 모든 prompt와 파일 내용을 장기 저장하면 민감정보 리스크가 커집니다. 대신 command metadata, risk class, file hash, approval id, tool version, exit status처럼 사고 복원에 필요한 최소 증거를 남기는 편이 낫습니다.

체크리스트 또는 연습

운영 체크리스트

• agent CLI/IDE/plugin 버전과 sandbox mode를 inventory했다.
• agent가 쓸 수 있는 파일과 host가 자동 실행·로드하는 파일을 교차 점검했다.
• .git/**, .venv/**, secret 파일, IDE task, package script, Docker config의 agent write 정책이 있다.
• Docker socket과 privileged local daemon은 agent 세션에서 기본 차단 또는 승인 대상이다.
• command allowlist는 이름뿐 아니라 args, cwd, env, repo config 영향까지 본다.
• agent가 수정한 executable/config 파일은 일정 시간 high-risk로 표시된다.
• host가 agent-influenced 파일을 실행할 때 audit log나 receipt가 남는다.
• high-risk workstation은 agent 보안 릴리스 후 24~72시간 안에 패치한다.

연습

1. 지금 쓰는 저장소에서 .vscode, .github, package.json, Dockerfile, scripts, .venv, .git/config 중 host가 자동 실행하거나 로드할 수 있는 파일을 표시해 보세요.
2. 최근 agent가 만든 PR 5개를 골라 executable/config 파일 변경이 있었는지 확인해 보세요. 있었다면 사람이 어떤 근거로 승인했는지 PR에 남아 있는지 봅니다.
3. untrusted repo를 agent로 열어야 하는 상황을 가정하고, Docker socket, SSH key, cloud CLI token, package registry token을 어떻게 분리할지 30분 안에 실행 가능한 절차로 적어 보세요.
4. git, npm, python, docker 명령 allowlist를 command name 기준에서 invocation 기준으로 바꿔 보세요. 어떤 인자와 설정 파일이 승인 대상으로 올라가야 하는지 표로 만듭니다.

AI 코딩 agent 보안은 이제 “sandbox를 켜세요"로 끝나지 않습니다. sandbox는 필요하지만 충분하지 않습니다. agent가 쓴 파일이 다음 실행자의 입력이 되는 순간, 경계는 프로세스 밖으로 이동합니다. 좋은 팀은 agent를 덜 쓰는 팀이 아니라, agent가 만든 handoff를 추적하고, host가 무엇을 신뢰하는지 증명하고, 위험한 실행은 작은 승인 단위로 끊는 팀입니다.

참고 자료

• Pillar Security, The Week of Sandbox Escapes: https://www.pillar.security/blog/the-week-of-sandbox-escapes
• BleepingComputer, Cursor/Codex/Gemini CLI/Antigravity sandbox escape 보도: https://www.bleepingcomputer.com/news/security/cursor-codex-gemini-cli-antigravity-hit-by-sandbox-escapes/
• arXiv, Agent Data Injection Attacks are Realistic Threats to AI Agents: https://arxiv.org/abs/2607.05120
• OpenAI Codex releases: https://github.com/openai/codex/releases