We Gave an Agent Production Code Access and Then Tried to Sleep at Night — Moritz Johner, Form3

한 줄 핵심

대규모 저장소의 CVE 패치를 에이전트로 자동화할 수 있지만, 생산 환경에서는 에이전트의 권한과 샌드박스를 설계하지 않으면 곧바로 공급망 리스크가 되므로, 결정적 오케스트레이션과 에이전틱 추론을 분리하는 구조가 핵심이다.

시간별 요약

1. 0:01
   의존성 패치는 규모가 커질수록 끝나지 않는 백로그가 되며, Dependabot·Renovate 같은 기존 도구만으로는 컨테이너와 복잡한 빌드 체인을 따라가지 못한다. 단순한 버전 상향이 아니라 CVE의 실제 위치와 연관된 주변 변경까지 이해하는 추론이 필요하다.
2. 3:01
   생산 환경에서 생산 코드 접근을 가진 유용한 에이전트는 사실상 공급망 행위자가 되므로, 엔지니어와 비슷한 수준의 가드레일을 적용해야 한다. 이 사례에서는 Patch Pilot를 운영하며 보안팀의 우려를 실제 설계로 받아들이는 방향으로 정리했다.
3. 4:01
   구조는 결정적 Go 애플리케이션이 아티팩트 발견·스캔·오케스트레이션을 담당하고, 에이전트는 최소 변경과 CI 실패 원인 추론만 맡는 2계층 방식이다. 에이전트는 파일만 수정하고, 커밋·푸시·PR 생성·CI 제어는 결정적 계층이 처리해 책임 경계를 분리한다.
4. 11:00
   GitHub 접근, OCR registry 자격 증명, 각종 런타임과 셸, 네트워크 접근을 제공하되, 위험한 권한은 에이전트가 아닌 결정적 계층에 남겨 두어야 한다. 프롬프트 인젝션은 완전히 해결할 수 없으므로 신뢰할 수 없는 디렉터리와 로그를 경계하고, 합성 저장소 기반 eval로 공격 벡터를 계속 점검해야 한다.
5. 14:01
   일반적인 샌드박스는 Docker socket을 다루는 순간 한계가 드러나므로, micro VM과 별도 커널, Vsock 기반 네트워크 제어처럼 더 강한 격리가 필요하다. 핵심 결론은 에이전트의 blast radius가 권한 분리와 실행 환경 설계에 의해 결정된다는 점이며, 이는 보안 모델 자체를 아키텍처로 풀어야 한다.

실무 인사이트

• 에이전트에게 필요한 권한만 주고, PR 생성·CI 트리거·푸시 같은 고위험 동작은 결정적 레이어로 빼면 사고 범위를 크게 줄일 수 있다.
• 운영 전에는 실제 악성 입력을 포함한 합성 저장소로 반복 평가를 돌려 프롬프트 인젝션과 CI 복잡성 실패를 미리 잡아야 한다.
• Docker socket이 필요한 작업은 일반 샌드박스보다 micro VM 수준의 격리와 네트워크 정책 분리가 사실상 전제조건이다.