에이전트에 프로덕션 코드 접근 권한을 주고 잠들어 본 이야기 — Moritz Johner, Form3

핵심 주장

• 유용한 코딩 에이전트는 그 자체로 공급망(supply chain) 행위자다. 의도했든 안 했든, 프로덕션 자격 증명을 에이전트에 쥐어주는 순간 그 에이전트는 조직 내 엔지니어와 동일한 수준의 보안 통제(guardrail)를 받아야 하는 대상이 된다. "에이전트는 위험하다" 혹은 "에이전트는 안전하다"는 이분법이 아니라, 어떤 순간에 자격 증명을 넘기느냐가 문제라는 것이 이 발표의 핵심 명제다.
• 에이전트의 블라스트 레이디어스(blast radius, 피해 반경)는 곧 아키텍처 결정이다. 무엇을 결정론적(deterministic) 레이어에 맡기고 무엇을 에이전트(agentic) 레이어에 맡길지를 나누는 그 경계선 자체가 사실상 보안 모델이다.
• 샌드박스는 슬라이드에서는 그럴듯해 보이지만, 에이전트에게 Docker 소켓 접근 권한을 주는 순간 사실상 게임 오버다. 진짜 격리를 원한다면 컨테이너 기반 샌드박스가 아니라 자체 커널을 가진 마이크로 VM(Firecracker 등)으로 가야 한다.

주요 논거 및 근거

1. 기존 자동화 도구(Dependabot, Renovate)의 구조적 한계

   • 이들 도구는 "CVE 발견 → 매니페스트에서 버전 하나 올리기"라는 단순한 세계관 위에서 만들어졌다. 그러나 실제 프로덕션 환경(특히 컨테이너 기반)은 훨씬 복잡하다.
   • 문제 1 — 가시성의 한계: 취약점이 매니페스트에 없는 곳에 숨어 있을 수 있다. 예를 들어 베이스 이미지 안의 OS 패키지, 혹은 Dockerfile 빌드 과정에서 URL로 받아오는 바이너리(버전 번호가 URL에 있어도 도구가 이를 해석해 조치할 방법이 없음)에 CVE가 있을 수 있다. 도구는 매니페스트만 보고 패치할 뿐, 그 외의 것은 전부 보이지 않는다.
   • 문제 2 — 패치는 고립되어 일어나지 않는다: Go 런타임 버전을 올리면 Go 린터도 함께 올려야 하는 경우가 있고, 린터를 올리면 새 린팅 규칙이 생겨 기존 코드베이스가 깨질 수 있다. Dependabot류는 그냥 버전을 올린 PR만 던져놓고 끝이라, 나머지 뒤처리는 사람 몫이 된다. 즉 이것은 단순 패칭 문제가 아니라 추론(reasoning) 문제다.

2. Patch Pilot 아키텍처 — 결정론적 레이어 + 에이전틱 레이어의 2계층 구조

   • 결정론적(Go 애플리케이션) 레이어: 지루하고 예측 가능한 오케스트레이션만 담당. 취약한 아티팩트(OCI 이미지) 발견 → 이미지 스캔 → 어떤 이미지가 어떤 저장소에서 빌드되는지 매핑 → 저장소 클론 → 에이전트용 컨텍스트(약 2,000단어 프롬프트 + 평가 매니페스트) 준비.
   • 에이전틱 레이어: 추론이 필요한 지점에서만 호출됨. CI 실패 시 "이건 CI 실패인데, 뭘 해야 할지 판단해봐"라고 에이전트에게 넘긴다(이전 변경 때문인지, 플레이키 CI인지, 인프라 타임아웃인지 구분해서 대응).
   • CVE 리미디에이션 에이전트: 발견된 CVE에 연결된 것만 최소 변경으로 고친다(불필요한 리스크를 피하기 위해 "최신 버전으로 무조건 올리기"는 지양). 작업 후 스스로 Dockerfile 빌드 검증, 이미지 재스캔 등 자기 검증을 수행. 단, 이 에이전트는 파일시스템만 건드릴 뿐 커밋·푸시·PR 생성·CI 관찰은 전혀 하지 않는다 — 이 권한들은 전부 결정론적 레이어의 몫.
   • 결정론적 레이어가 에이전트 결과물을 검수(빈 파일, 실수로 남은 바이너리 등 "에이전트가 저지르는 멍청한 실수" 필터링) → 커밋 → 푸시 → PR 생성 → CI 관찰.
   • CI 실패 시 PR 리미디에이션 에이전트가 CI 로그·워크플로우 메타데이터를 받아 최소 수정만 시도(LLM은 이전 변경을 그냥 되돌리려는 경향이 있어 "되돌리지 말라"고 명시적으로 지시해야 함). 최대 재시도 횟수에 도달하면 사람에게 에스컬레이션.
   • 자기 회고(retrospective) 루틴: 모든 에이전트 호출이 끝날 때마다 "무엇이 잘 됐고, 무엇이 잘못됐고, 어떤 툴이 부족했고, 다음번에 어떤 컨텍스트가 필요한지"를 스스로 짧게 요약하게 함. 이걸 PR 단위로 취합·집계하면 대규모 운영에서 에이전트의 문제 패턴(인프라 이슈 vs. 저장소별 복잡도 이슈)을 파악할 수 있어 관측성(observability)에 크게 도움이 됨. (에이전트 자체의 옵저버빌리티는 아직 커뮤니티 차원에서 정립 중인 미해결 영역이라고 인정.)

3. 실제 사례 — 에이전트가 사람보다 나은 판단을 한 경우

   • 실제 프로덕션 스크린샷(정보는 레닥션)에서, 베이스 이미지 버전을 올리는 건 Dependabot도 할 수 있는 단순한 작업이었지만, 그 아래에서 에이전트는 libcrypto3, libssl3 등을 업데이트하면서 이전에 핀(pin)되어 있던 패키지 두 개가 이미 베이스 이미지 업데이트로 해결된 것을 파악하고 제거했다. 발표자 본인이 직접 했다면 놓쳤을 거라고 인정 — 이는 에이전트가 코드베이스 맥락을 깊이 있게 추론한 사례.

4. 자격 증명 분리 — 프롬프트 인젝션에 대한 방어선

   • Patch Pilot 전체에는 GitHub read/write, OCI 레지스트리 크리덴셜, Go/Python 런타임, 린터, bash 쉘, 네트워크 접근 등을 부여했다.
   • 하지만 위험한 권한(GitHub push, CI 트리거)은 에이전트에게 절대 주지 않고 결정론적 레이어에만 남겨둠. 이렇게 하면 에이전트가 프롬프트 인젝션을 당해도 실질적 피해(블라스트 레이디어스)가 제한된다.
   • 실제로 의존성 몇 개 버전을 올리는 "작은" PR 하나에 7만 줄 변경이 딸려온 사례가 있었을 정도로 공격 표면이 넓다.
   • 대응책: (1) 프롬프트 스티어링 — vendor 디렉터리나 CI 로그 등 "신뢰할 수 없는 컨텍스트"가 담긴 위치를 명시적으로 지정해 에이전트에게 "이건 믿지 마라"고 지시. (2) 엔드투엔드 이블(eval) 테스트 — 프롬프트 인젝션을 유도하는 deprecated 함수나 마이그레이션 가이드를 심어놓은 테스트용 저장소를 만들어 patch pilot을 돌려보고 실제로 인젝션에 당하지 않는지 검증. 다만 아직 알려지지 않은 인젝션 벡터는 여전히 존재하므로 "희망에만 의존하지 않되, 완전히 해결된 건 아니다"라는 태도.

5. 샌드박싱의 진짜 함정 — Docker 소켓

   • 에이전트가 자기 작업을 검증하려면(Dockerfile 빌드, 컨테이너 실행 등) Docker 소켓 접근이 필요해진다. 그런데 Docker 소켓을 주는 순간 에이전트는 특권 컨테이너를 스폰해 탈출하고, 다른 프로세스의 환경 변수·메모리를 읽고, SSH 키를 심는 것까지 가능 — 사실상 게임 오버.
   • Form3는 실제로 이렇게 프로덕션에서 운영해본 적이 있었고, 좋은 경험이 아니어서 이 방식에서 벗어났다.
   • landlock, bubblewrap, seccomp, unotify, 비특권 Docker 빌드(Kaniko, buildkit) 등 리눅스 진영의 샌드박싱 기술들을 검토했지만, 컨테이너와 잘 조합되지 않고 호스트에서 도는 Docker 데몬/소켓을 격리하지 못한다는 공통된 한계가 있었다.
   • 대안으로 제시한 설계: Firecracker 기반 마이크로 VM 안에 에이전트와 Docker 소켓을 함께 넣고, 그 Docker 소켓이 자체 커널로 구동되게 함 — 이렇게 하면 탈출 문제 자체가 원천 차단됨(아직 초기 단계 설계라고 밝힘).

6. 네트워크 정책의 2계층 분리

   • 결정론적 레이어는 필요한 네트워크 접근(GitHub 등)이 명확히 정해져 있음.
   • 에이전트가 필요로 하는 네트워크는 저장소/언어에 따라 완전히 달라짐(Java 생태계 vs. Python vs. Go).
   • 해법: 마이크로 VM 내부에 DNS/TCP 포워더를 두고, 호스트와는 완전히 단절시킨 뒤 모든 트래픽이 vsock을 통해 호스트 프로세스로 전달되어 호스트명·포트·CIDR 기반 정책이 적용되게 함. 원한다면 커스텀 CA를 심어 TLS 중간자(MITM) 검사까지 할 수 있음(다만 Docker 소켓 관련해서는 아직 다루지 못한 영역이라고 인정).

세부 내용 및 사례

• 패치 파일럿의 이름과 계기: 발표 제목처럼, 인프라섹(Infosec) 팀이 "이거 자동화야, 아니면 벌어질 예정인 공급망 사고야?"라는 아주 합리적인 질문을 던진 게 이 발표를 하게 된 배경.
• 현재 에이전트 코딩 툴들의 샌드박스에 대한 평가: Codex, Claude Code 등이 자체 샌드박스를 갖고 있지만, 발표자 관점에서는 Docker 소켓 접근이 허용되는 순간 사실상 무의미하다고 평가. Open Code, Pi 같은 다른 에이전트 도구들은 애초에 샌드박스가 아예 없다고 언급.
• micro sandbox 프로젝트 소개: 최근 3~4개월 정도 운영된 오픈소스 프로젝트로, 네트워크 접근 제어 등 필요한 기능이 이미 다 갖춰져 있어서(batteries included) "지금 patch pilot을 다시 만든다면 이걸 쓸 것"이라고 언급. YC 펀딩을 받고 있으며, 오픈소스 커뮤니티로서 앞으로 트랙션을 확보할 수 있을지는 지켜봐야 하는 상태라고 평가.
• 생태계 성숙도에 대한 평가: 필요한 도구 자체는 이미 다 존재하지만 대부분 베타 단계이며, 엔터프라이즈 환경에 실제로 배포하는 데 필요한 기능(온갖 디테일)까지 갖추려면 아직 갭이 있다고 지적. Kubernetes 진영의 "agent sandbox" SIG(special interest group), "open sandbox" 프로젝트 등이 이 오케스트레이션 레이어를 만들어가고 있다고 소개.
• 커뮤니티에 대한 초청: 발표 다음 날 샌드박스 관련 전용 패널이 있다고 언급하며, 청중들에게 실제로 프로덕션에서 에이전트를 어떻게 운영하고 있는지 함께 논의하자고 제안하며 마무리.

시사점 및 액션포인트

• 자율 에이전트에 프로덕션 자격 증명을 부여할 계획이 있다면, 위험한 권한(원격 저장소 push, CI 트리거, 배포 등)은 에이전트가 아니라 결정론적 오케스트레이션 레이어에 남겨둘 것. 에이전트는 파일시스템 조작과 추론까지만 담당하게 하고, 그 결과물을 사람이 짠 검증 로직이 검수한 뒤에야 실제 액션(커밋/PR/CI 트리거)이 일어나도록 설계하는 게 프롬프트 인젝션 피해를 구조적으로 제한하는 가장 효과적인 방법이다.
• 에이전트에게 Docker 소켓을 주는 설계는 재고할 것. 컨테이너 기반 샌드박스(seccomp, bubblewrap 등)로는 Docker 소켓/데몬을 안전하게 격리할 수 없다는 게 실전에서 확인된 사실이므로, 격리가 정말 중요하다면 Firecracker 같은 마이크로 VM 기반 격리를 검토해야 한다. micro sandbox 같은 신생 오픈소스 프로젝트를 눈여겨볼 것.
• 프롬프트 인젝션은 "해결"하는 게 아니라 "블라스트 레이디어스를 제한"하는 문제로 접근할 것. vendor 디렉터리, CI 로그처럼 신뢰할 수 없는 컨텍스트가 담긴 위치를 명시적으로 프롬프트에 표시하고, 프롬프트 인젝션을 유도하는 테스트 저장소로 정기적인 이블(eval) 테스트를 돌려 검증하는 루틴을 갖출 것.
• 에이전트 자기 회고(retrospective) 로그를 습관화할 것. 매 에이전트 호출 후 "무엇이 잘 됐고, 뭐가 부족했는지"를 짧게 남기게 하고 이를 집계하면, 대규모로 에이전트를 운영할 때 반복되는 실패 패턴(인프라 문제 vs. 저장소별 컨텍스트 부족)을 구조적으로 찾아내고 시스템 프롬프트/저장소별 지침을 개선하는 데 활용할 수 있다.
• "CVE를 고쳐라"가 아니라 "가장 작은 효과적인 변경 집합만 고쳐라"로 에이전트 지시를 제한할 것. 무조건 최신 버전으로 올리는 식의 과잉 수정은 불필요한 리스크를 추가하므로, 발견된 문제에 정확히 대응하는 최소 변경 원칙을 프롬프트에 명시하는 것이 안전하다.
• 이 분야(에이전트 샌드박싱/오케스트레이션)는 아직 베타 단계 도구들이 대부분이므로, 자체 구축 전에 Kubernetes agent sandbox SIG, open sandbox, micro sandbox 등 커뮤니티 동향을 주기적으로 체크해볼 가치가 있다.