Security Firewall for Agents — Ryan Dahl, Deno

한 줄 핵심

에이전트가 생산 시스템에 접근할 때는 모델의 순응성에 기대지 말고, 에이전트 바깥에서 네트워크 수준으로 bytes 단위의 경계를 강제하는 보안 방화벽이 필요하다는 주장이다.

시간별 요약

1. 0:00
   Deno Deploy, 사고, 그리고 호출기 Deno Deploy의 장애 대응에 에이전트를 투입해 보며, 사람이 밤에 깨우는 호출기 대신 자동화된 복구를 시도한 배경을 설명한다. 여러 시스템에 접근 가능한 에이전트 운용에서 반복적으로 유효한 패턴이 있었고, 이를 공유하려는 목적이 제시된다.
2. 1:28
   에이전트에 생산 환경 쓰기 권한 주기 에이전트에게 PostgreSQL, Kubernetes, ClickHouse, AWS, GitHub, Slack 등 여러 시스템의 읽기·쓰기 권한을 주면 장애 해결에 큰 힘이 된다. 그러나 같은 권한은 psql로 users 테이블을 삭제하거나 kubectl로 prod namespace를 지우는 식의 파괴적 행동도 가능하게 만든다.
3. 2:47
   Opus의 거절과 그것만으로는 부족한 이유 Opus는 사용자를 삭제하라는 지시를 매우 잘 거부하지만, 그 사실만으로 보안이 성립하지는 않는다. 에이전트가 언제나 올바르게 행동할 것이라는 기대는 방어책이 될 수 없으며, 외부 입력에 의해 쉽게 흔들릴 수 있다.
4. 3:28
   지원 시스템을 통한 프롬프트 인젝션 에이전트가 지원 시스템과 연결되어 있으면 외부에서 prompt injection을 당할 수 있고, 그 결과 잘못된 행동을 정당한 조치처럼 착각할 수 있다. 따라서 에이전트 자체를 신뢰 가능한 소프트웨어로 취급하지 말고, 에이전트 내부에 방어선을 두지 말아야 한다.
5. 4:05
   모든 행동은 와이어 위의 바이트다 에이전트의 좋은 행동이든 나쁜 행동이든 결국은 네트워크를 통해 나가는 bytes로 나타난다. MCP 호출뿐 아니라 subprocess, PostgreSQL 같은 비HTTP 프로토콜도 모두 포함되며, 핵심은 에이전트에서 나가는 바이트를 정밀하게 파악하는 일이다.
6. 5:24
   어려운 사례: EKS 엔드포인트를 통한 psql AWS VPC 안의 PostgreSQL에 EKS endpoint를 통해서만 도달할 수 있는 상황처럼, 경로가 복잡해지면 에이전트가 우회적으로 psql을 띄워 users 테이블을 삭제할 가능성까지 고려해야 한다. 이런 경우에는 단순 권한 관리가 아니라, SQL을 이해하는 규칙으로 아웃바운드 경로 전체를 통제해야 한다.
7. 6:47
   자격 증명과 ACL만으로는 충분하지 않은 이유 세심한 credential provisioning과 ACL은 필요하지만, 여러 시스템을 조합하는 순간 권한의 합성에서 구멍이 생긴다. MCP 도구로 권한을 구조화해도 subprocess가 개입되는 순간 경계가 무너질 수 있다.
8. 7:26
   MCP 도구 권한이 무너지는 지점 LLM gateway, HTTP proxy, sandbox 같은 기존 도구들은 일부 문제를 해결하지만, 대부분 HTTP나 모델 입력에만 초점이 있다. 그러나 실제 위험은 데이터베이스나 subprocess처럼 다른 계층에서 발생하므로, 그 경계만으로는 충분하지 않다.
9. 8:48
   기존 프록시와 샌드박스의 현황 OpenShell 같은 프로세스 샌드박스, agent vault 같은 credential injection 프록시, HTTP jail이나 Crabt Trap 같은 HTTP 계층 제어 도구들이 이미 존재한다. 하지만 VM 수준 격리를 사용하면 파일·시스템콜보다 네트워크 경로 통제가 더 중요한 문제로 남는다.
10. 10:09
    Claw Patrol Claw Patrol은 에이전트 앞에 서는 오픈소스 프록시로, HTTP보다 낮은 수준에서 에이전트가 내보내는 모든 바이트를 이해한다. 비밀값은 에이전트가 직접 보지 못하게 보관하고 주입하며, 강력한 규칙 시스템으로 외부 통신을 통제한다.
11. 10:50
    HCL로 규칙 작성하기 권한 규칙은 HCL 설정 파일로 관리되며, Git에 커밋된 약 천 줄 규모의 파일로 서비스별 접근 정책을 엄격하게 유지한다. PostgreSQL의 특정 함수 호출을 막는 식의 정밀한 규칙을 정의할 수 있고, 다른 시스템을 거쳐 터널링하더라도 적용된다.
12. 12:07
    프로토콜 플러그인 Claw Patrol은 여러 프로토콜을 지원하고, 아직 모르는 프로토콜은 플러그인으로 확장할 수 있다. 이로써 단순 HTTP 프록시가 아니라 PostgreSQL 같은 비HTTP 프로토콜도 해석하고 규칙을 적용할 수 있다.
13. 12:52
    users 테이블 삭제 차단 데모 Codex가 Psql subprocess를 띄워 users 테이블을 삭제하려는 상황을 재현한 뒤, Claw Patrol이 Postgres 프로토콜을 파싱해 해당 동작을 최종적으로 거부한다. 여기서 핵심은 에이전트의 의도보다 바깥쪽 규칙이 destructive action을 차단한다는 점이다.
14. 13:34
    대시보드 대시보드는 여러 에이전트와 기기에서 흘러오는 요청과 차단·승인 상태를 한눈에 보여준다. 각 action의 세부 내용을 클릭해 분석할 수 있고, 운영 관점에서 어떤 에이전트가 무엇을 시도했는지 추적하는 데 초점이 맞춰져 있다.
15. 14:14
    LLM 심사자 또는 사람의 승인 규칙은 단순 차단뿐 아니라 Slack의 사람 승인이나 LLM judge를 통한 승인 흐름도 만들 수 있다. 필요하면 LLM 심사를 먼저 거치고 그다음 사람이 승인하는 식으로, 에이전트 소프트웨어를 수정하지 않고도 정교한 통제 체계를 구성한다.
16. 14:58
    자격 증명 주입 인증 정보는 bearer header만이 아니라 cookie, PostgreSQL, ClickHouse, AWS Sig v4 등 다양한 형식으로 존재하며, 이를 프록시가 대신 주입한다. 에이전트는 비밀값을 직접 보지 않고 플레이스홀더만 보내며, 실무 시스템에 맞는 보안 모델을 제공한다.
17. 15:38
    Tailscale 또는 WireGuard로 실행하기 Claw Patrol은 Tailscale이나 WireGuard 위에서 동작하며, 내부 네트워크와 대시보드 인증까지 함께 묶어 운용한다. 이 구조는 시스템을 인터넷 바깥에 두고 민감한 접근을 좁은 경로로만 허용하려는 운영 방식과 잘 맞는다.
18. 16:58
    에이전트는 스스로를 감시할 수 없다 보안 플러그인이나 에이전트 내부 수정만으로는 충분하지 않으며, 경계는 항상 더 바깥에 있어야 한다. 에이전트는 스스로를 경찰처럼 감시할 수 없기 때문에, 실제 보안은 외부의 백스톱 메커니즘으로 구현해야 한다.
19. 17:42
    Q&A: 규칙 파일 테스트 규칙 파일은 fixture request를 흘려보내는 테스트 체계를 갖고 있어 특정 요청이 항상 차단되는지 단위 테스트처럼 검증할 수 있다. Claw Patrol 자체도 별도의 큰 테스트 스위트로 안정성을 점검한다.
20. 18:22
    Q&A: 모델이 좋아지면 이 문제가 쉬워지는가 모델이 더 똑똑해지고 문맥 이해가 좋아질수록 문제는 줄어들 수 있지만, 완전히 신뢰할 수는 없으므로 백스톱 보안은 계속 필요하다. 더 나은 정렬은 도움이 되지만, 실전 보안은 여전히 외부 통제층에 의존해야 한다.

실무 인사이트

• 에이전트 보안은 모델의 의도 판단보다 네트워크 경로와 프로토콜 단위의 강제 차단에 두는 편이 훨씬 견고하다.
• 읽기·쓰기 권한을 넓게 주더라도, subprocess·터널링·비HTTP 프로토콜까지 포함한 합성 경로를 막지 못하면 실질적 보호가 되지 않는다.
• 실무 적용에서는 비밀값 주입, 승인 흐름, 감사 대시보드를 함께 묶어 운영해야 에이전트를 생산 환경에 안전하게 붙일 수 있다.