AI 에이전트 권한을 액션 단위로 막는 Claw Patrol

AI 에이전트 권한을 액션 단위로 막는 Claw Patrol

AI 뉴스 썸네일

AI 에이전트가 실제 서비스와 데이터베이스에 접근하는 순간, 기존 권한 관리만으로는 부족한 지점이 생겨요. Claw Patrol은 에이전트가 가진 키를 대신 보관하고, HTTP·SQL·Kubernetes 요청을 실제 전송 전에 검사하는 보안 계층이에요. 에이전트가 어디에 접속할 수 있는지보다, 접속한 뒤 어떤 행동을 해도 되는지를 따지는 도구에 가까워요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
에이전트 보안	Claw Patrol은 에이전트 자격 증명을 직접 넘기지 않고, 요청 내용을 검사한 뒤 허용 여부를 정해요	AI 에이전트에 프로덕션 접근 권한을 줄 때 가장 불안한 지점을 건드려요
액션 제어	HTTP 메서드, SQL 동사, Kubernetes 리소스·동사처럼 요청 안쪽 내용을 기준으로 규칙을 걸 수 있어요	단순 접속 허용·차단보다 세밀한 운영 정책을 만들 수 있어요
승인 흐름	위험하거나 애매한 요청은 LLM 판정이나 사람 승인을 거치게 할 수 있어요	자동화 속도와 운영 통제 사이의 절충안을 보여줘요
운영 검증	실제 액션을 녹화해 JSON fixture로 저장하고, 정책 변경 전 회귀 테스트를 돌릴 수 있어요	보안 규칙이 배포 뒤에 조용히 바뀌는 문제를 줄일 수 있어요

1. AI 에이전트 권한을 네트워크 앞단에서 다시 잡는 도구

Claw Patrol은 "에이전트용 보안 방화벽"을 내세우는 오픈소스 도구예요. 에이전트가 데이터베이스, Kubernetes, GitHub, Slack 같은 서비스로 나가는 요청을 Claw Patrol을 통해 보내고, 이 계층이 자격 증명 주입, 규칙 판정, 승인 흐름, 감사 로그를 맡아요. 공식 소개에 따르면 에이전트 코드는 크게 바꾸지 않고 WireGuard나 Tailscale로 게이트웨이에 붙인 뒤 실행할 수 있어요. 2

흥미로운 지점은 기존 권한 체계의 빈틈을 정확히 겨냥한다는 점이에요. OAuth 스코프, IAM 역할, Kubernetes RBAC는 보통 "어디에 접근할 수 있나"를 다뤄요. 하지만 Postgres에 접속할 수 있는 에이전트가 `SELECT`만 할지, 실수로 `DROP TABLE`을 실행할지는 별도 문제예요. Claw Patrol은 이 차이를 "접근"과 "액션"의 차이로 보고, 액션 내용을 다시 판정해요. 2

자격 증명 처리도 핵심이에요. 에이전트 프로세스가 키를 직접 들고 있으면 입력 조작이나 도구 오용이 생겼을 때 키가 함께 새어 나갈 수 있어요. Claw Patrol은 키를 에이전트 밖에 두고, 요청이 허용될 때 필요한 자격 증명을 중간에서 붙이는 방식을 택해요. 에이전트가 일을 하긴 하지만, 키를 직접 읽지는 못하게 만드는 구조예요. 2

2. URL 차단을 넘어 SQL과 Kubernetes 요청까지 읽어요

보안 프록시가 HTTP URL만 보는 수준이면 우회 여지가 커요. Claw Patrol은 HTTP 메서드·경로·헤더·본문을 보고, 필요하면 LLM 판정으로 요청을 넘길 수 있어요. 예를 들어 고객 지원 답변 API 호출을 검사해 공격적인 표현이나 잘못된 마크다운을 막는 식이에요. 2

SQL 쪽은 더 직접적이에요. Postgres와 ClickHouse 트래픽을 동사 단위로 파싱하고, 테이블명·함수명·쿼리 일부 문자열을 기준으로 규칙을 걸 수 있어요. 공식 예시는 `pg_read_file`, `pg_read_binary_file`, `lo_get`, `dblink_` 계열처럼 데이터베이스 안에서 파일 시스템이나 외부 연결에 닿을 수 있는 함수를 차단해요. 단순히 데이터베이스 접속을 허용하는 것보다 훨씬 운영 보안에 가까운 기준이에요. 2

Kubernetes도 마찬가지예요. 네임스페이스, 리소스, 동사, 이름을 기준으로 요청을 검사하고, `kubectl exec`처럼 위험이 큰 액션은 명령 인자를 읽어 판단할 수 있어요. 공식 예시에서는 `ls`, `ps`, `df` 같은 확인 명령은 허용하고, 환경 변수 덤프나 토큰 접근은 거부하는 흐름을 보여줘요. 이건 "에이전트가 클러스터에 들어갈 수 있나"보다 "클러스터 안에서 뭘 하려 하나"를 보는 방식이에요. 2

3. 애매한 요청은 모델이나 사람이 한 번 더 봐요

모든 위험 요청을 규칙만으로 자르기는 어려워요. Claw Patrol은 이런 요청을 LLM 판정이나 사람 승인으로 넘기는 흐름을 제공해요. 모델 승인자는 요청마다 투표하고, 결과를 캐시해 같은 판단에 비용이 반복해서 들지 않게 해요. 사람 승인은 대시보드, 웹훅, 협업 도구를 통해 받을 수 있고, 응답이 없으면 시간 초과 뒤 자동 거부할 수 있어요. 2

이 구조는 완전 자동화와 수동 운영 사이의 중간 지점이에요. 예를 들어 에이전트가 운영 저장소에서 삭제 요청을 보내거나, 고객 응대 메시지를 대신 전송하려 할 때 바로 실행하지 않고 한 번 더 멈출 수 있어요. 속도는 조금 잃지만, 운영자가 나중에 로그만 보고 원인을 추적하는 상황보다는 낫겠죠.

회귀 테스트 기능도 운영 관점에서 중요해요. 실제 액션을 녹화해 JSON fixture로 저장하고, `clawpatrol test`로 정책 변경 전 판정이 뒤집히는지 확인할 수 있어요. 보안 규칙은 대시보드에서 고치기 쉬울수록 실수로 넓어지기도 쉬워요. 그래서 배포 전 테스트가 붙어 있다는 점은 실험용 도구와 운영용 도구를 가르는 기준이 될 수 있어요. 2

왜 중요한가요

AI 에이전트를 개발 환경 안에서만 쓰는 단계라면 이런 도구가 과하게 보일 수 있어요. 하지만 에이전트가 배포, 고객 지원, 데이터 조회, 인프라 조작까지 맡기 시작하면 이야기가 달라져요. 에이전트가 빠르게 움직일수록 "권한을 줄 것인가"보다 "권한을 가진 상태에서 어떤 액션을 허용할 것인가"가 더 큰 문제가 돼요.

Claw Patrol이 흥미로운 이유는 에이전트 보안을 모델 출력 검사로만 보지 않는다는 점이에요. 요청이 실제 서비스로 나가기 직전, 네트워크와 프로토콜 레이어에서 다시 읽어요. HTTP, SQL, Kubernetes처럼 운영팀이 이미 쓰는 경계에 맞춰 규칙을 만들 수 있어서, AI 도입을 보안팀과 함께 설계하려는 팀에 참고할 만해요. 3

물론 만능 방패는 아니에요. 규칙을 잘못 쓰면 필요한 자동화를 막고, 규칙이 너무 느슨하면 위험한 호출이 지나갈 수 있어요. LLM 판정도 비용과 지연, 오판 가능성을 함께 봐야 해요. 그래도 에이전트가 프로덕션에 가까워지는 흐름에서는 이런 액션 제어 계층이 점점 더 자주 논의될 가능성이 커요.

참고 자료

1. Claw Patrol - 에이전트를 위한 보안 방화벽 — GeekNews
2. Claw Patrol - The security firewall for agents — Claw Patrol
3. denoland/clawpatrol — GitHub