원본: GeekNews — Claw Patrol, 에이전트를 위한 보안 방화벽
한 줄 요약: 기존 권한 체계(OAuth, IAM, RBAC)는 에이전트의 행동을 막지 못하고, Claw Patrol은 트래픽을 와이어 레벨에서 파싱해 SQL 동사·HTTP 메서드 단위로 액션을 차단하는 에이전트 전용 보안 방화벽이다.
---
"읽기 권한만 줬으니까 괜찮아" — 이 생각이 문제입니다
혹시 이런 생각 해보신 적 있으신가요?
"에이전트한테 DB 읽기 권한만 줬으니까 잘못될 일은 없겠지." 저도 그렇게 생각했습니다. QR 근태관리 앱을 만들면서 Claude Code가 DB를 조회해야 하는 상황이 있었고, 읽기 전용 접근이면 충분히 안전하다고 판단했습니다.
그런데 Claw Patrol 소개 기사를 읽고 나서 생각이 달라졌습니다.
OAuth 스코프, IAM 역할, Kubernetes RBAC — 이 권한 체계들은 전부 "어디에 접근 가능한가"를 결정합니다. DB에 접속할 수 있는 에이전트는 SELECT를 실행하는 것만큼 쉽게 DROP TABLE도 실행할 수 있습니다.
에이전트가 프롬프트 인젝션 공격을 받으면 어떻게 될까요? 에이전트가 들고 있던 자격증명이 그대로 유출됩니다.
기존 권한 체계의 빈틈이 여기에 있었습니다.
---
에이전트 보안에서 챙겨야 할 핵심 스킬
이 기사에서 실제로 적용 가능한 것들을 골랐습니다.
스킬 1: 자격증명을 에이전트 눈에서 숨긴다
에이전트가 API 키나 DB 비밀번호를 직접 볼 수 없어야 합니다. 키는 에이전트가 아닌 별도 레이어가 보관하고, 요청 시점에 주입하는 구조가 필요합니다.
Claw Patrol이 하는 핵심 역할 중 하나가 바로 이겁니다. 에이전트가 침해당해도 키가 나가지 않습니다.
스킬 2: "접근 권한"이 아니라 "행동 권한"을 통제한다
SQL 동사 단위로 허용과 차단을 설정합니다. Postgres에 접속 권한이 있어도 DROP, DELETE는 실행 못 하게 막습니다. HTTP도 마찬가지입니다. 특정 경로와 메서드만 허용하고 나머지는 차단합니다.
`pg_read_file`, `dblink_*` 같은 파일시스템 접근 함수는 아예 차단할 수 있습니다.
스킬 3: 모호한 요청은 사람이 직접 승인한다
확실하지 않은 요청이 들어오면 Slack이나 대시보드로 알림이 옵니다. 사람이 허용하거나 거부합니다. 응답이 없으면 타임아웃 후 자동 거부됩니다.
에이전트가 알아서 하게 두지 않고, 중요한 액션은 사람이 최종 승인하는 구조입니다.
---
ClipLab 만들면서 직접 겪은 API 키 사고
ClipLab을 개발할 때 가장 불안했던 순간이 있었습니다.
Claude Code가 디버깅을 도와주는 과정에서 console.log 안에 API 키가 찍혔고, 그 코드가 잠깐 배포된 상태로 올라갔습니다. 로그가 외부에 노출되는 설정이었으면 키가 그대로 유출될 뻔했습니다.
빨리 발견해서 다행이었지만 아찔했습니다.
그 이후로 Cloudflare Workers Secrets로 전환했습니다. 일반 환경변수와 달리, Secrets는 코드에서 직접 읽어 출력하는 게 불가능합니다. 에이전트가 어떤 값인지 알 수 없고, 실행 시점에만 런타임이 주입합니다.
QR 앱의 Google Sheets API 키도 같은 방식으로 바꿨습니다. 에이전트 눈에 키가 보이지 않으니 실수로 노출될 경로가 사라졌습니다.
Claw Patrol 같은 전용 방화벽을 도입하기 전이라면, 지금 당장 할 수 있는 것부터 시작하면 됩니다. 에이전트에게 주는 권한을 최소한으로 줄이는 것, 키를 Secrets로 옮기는 것. 이 두 가지만으로도 리스크가 크게 달라집니다.