AI 에이전트에 데이터베이스 쓰기 권한을 주면 생기는 일과 Deno의 보안 해법

URL: https://www.youtube.com/watch?v=w0e6vBjYq3U
날짜: 2026-08-20
채널: Tech Bridge
발표: Ryan Dahl (Deno CEO, Node.js 창시자)

---

📌 핵심 질문 / 핵심 주장

==AI 에이전트(Agent)를 실제 운영 시스템에 투입하려면 에이전트의 선의나 정렬(alignment)에 보안을 맡기지 말고, 에이전트 바깥의 네트워크 경계에서 모든 바이트와 프로토콜 동작을 통제해야 한다.==

• Deno Deploy의 장애 대응에 OpenClaw와 다른 에이전트를 사용하면 인간 SRE가 하던 진단과 복구를 상당 부분 자동화할 수 있다.
• 에이전트에 Postgres, Kubernetes, ClickHouse, AWS, GitHub, Slack의 폭넓은 읽기·쓰기 권한을 주면 충분한 운영 맥락을 얻지만, DROP TABLE users나 kubectl delete namespace prod 같은 파괴적 동작도 가능해진다.
• Opus처럼 잘 정렬된 모델이 위험한 명령을 거부해도 지원 시스템의 문맥에 섞인 프롬프트 인젝션(prompt injection)이 모델의 판단을 바꿀 수 있으므로, 모델 자체를 보안 장치로 간주할 수 없다.
• Deno가 만든 오픈소스 MIT 프로젝트 Claw Patrol은 에이전트 앞단에서 HTTP에 국한되지 않고 PostgreSQL 같은 프로토콜의 바이트를 해석하며, HCL 규칙·자격 증명 주입·승인 절차로 외부 동작을 차단하거나 사람에게 넘긴다.

운영 에이전트의 핵심 문제는 “모델이 악의적인 명령을 거부하는가”가 아니라 “어떤 경로로 만들어진 어떤 바이트가 실제 시스템에 도착하는가”다. 파일 시스템은 독립 VM으로 격리할 수 있지만, 데이터베이스와 클라우드 API에 연결되는 네트워크는 별도의, 모델과 무관한 보안 경계가 필요하다.

1. 운영 장애 대응에 에이전트를 투입한 배경

Ryan Dahl은 Deno의 CEO이며 Node.js를 만든 개발자로 소개된다. Deno가 운영하는 Deno Deploy는 웹사이트를 호스팅하는 서비스라서 때때로 장애(downtime)가 발생하고, 장애가 나면 PagerDuty의 경보가 울린다. 한밤중에 사람을 깨우는 PagerDuty의 무서운 알람음은 전통적인 SRE 운영의 상징으로 제시된다.

1.1. 인간 SRE의 일을 자동화하는 OpenClaw

1. 장애 대응 에이전트의 도입

   1. Deno 팀은 최근 OpenClaw와 다른 에이전트를 사용해 장애(incident)를 자동으로 처리하는 실험을 했다.
   2. 목표는 단순한 챗봇 응답이 아니라, 에이전트가 장애의 원인을 조사하고 필요한 운영 조치를 실행하게 하는 것이다.

2. 운영 시스템 전체에 연결

   1. 에이전트는 Postgres, Kubernetes, ClickHouse, AWS, GitHub, Slack 등 다양한 시스템에 연결된다.
   2. Deno 팀은 에이전트에 조회 전용이 아닌 실제 변경(write/rewrite) 권한까지 부여한다. 자막의 “rewrite access”는 읽고 변경할 수 있는 강한 권한을 가리킨다.

1.2. 넓은 권한이 주는 진단 맥락

1. 관측 데이터와 사용자 맥락의 결합

   1. ClickHouse에서 트레이스(trace)를 살펴 장애가 어떤 요청과 경로에서 생겼는지 확인한다.
   2. 운영 Postgres에서 특정 사용자가 어떤 프로젝트를 소유하는지 조회한다.
   3. Slack의 팀 커뮤니케이션과 GitHub 로그까지 읽어 기술적 변화와 사람들의 논의를 연결한다.

2. 자동화의 실제 효과

   1. 여러 시스템의 맥락을 한 번에 볼 수 있어 에이전트는 과거에 인간 SRE가 개입하던 장애를 상당수 해결한다.
   2. 권한을 지나치게 좁히면 진단에 필요한 정보가 사라지므로, 유용한 SRE 에이전트는 어느 정도 폭넓은 접근을 요구한다.

2. 모델 정렬만으로는 운영 보안을 만들 수 없다

2.1. 파괴적 명령은 실제로 가능한가

1. 데이터베이스 파괴

   1. 에이전트가 psql 서브프로세스를 시작하고 DELETE users table 또는 사용자 테이블 삭제에 해당하는 명령을 실행할 수 있다.
   2. 장애 해결을 “모든 사용자를 제거하면 된다”라고 잘못 판단하면 서비스의 핵심 데이터를 잃을 수 있다.

2. 클러스터 파괴

   1. 에이전트는 kubectl delete namespace prod를 실행해 프로덕션 네임스페이스를 통째로 삭제할 수도 있다.
   2. 네트워크로 연결된 시스템이 많을수록 하나의 잘못된 판단이 데이터베이스에서 Kubernetes, 클라우드 계정으로 연쇄 확산된다.

2.2. Opus의 거부와 보안의 차이

1. 정렬된 모델의 장점

   1. Deno 팀은 Opus를 사용하며, Opus는 놀랄 만큼 잘 정렬되어 있다.
   2. 사용자가 매우 끈질기게 사용자 테이블 삭제를 요구해도 Opus는 반복해서 거부한다.

2. 거부를 최종 방어선으로 삼을 수 없는 이유

   1. 보안은 “Opus가 언제나 우리의 뜻을 따를 것”이라는 희망적 사고(wishful thinking)로 구성할 수 없다.
   2. 에이전트는 지원 시스템에 연결되어 있고, 외부 사용자가 남긴 지원 티켓·로그·메시지가 모델의 문맥으로 들어간다.
   3. 공격자는 특정 문자열의 조합으로 프롬프트 인젝션을 일으켜 Opus가 바람직하지 않은 행동을 올바른 장애 처리라고 믿게 만들 수 있다.

2.3. 에이전트를 신뢰하지 않는 위협 모델

1. 에이전트 자체는 신뢰할 수 없는 소프트웨어

   1. 에이전트가 무엇을 하는지 에이전트 스스로 감시하게 해서는 안 된다.
   2. 보안 가드를 에이전트 내부에 플러그인이나 프롬프트 형태로만 넣으면, 같은 모델과 문맥 오염에 함께 노출된다.

2. 파일 시스템과 네트워크의 경계 구분

   1. Deno 팀은 에이전트를 독립적인 VM(virtual machine)에서 실행하므로 에이전트가 VM 내부 파일을 만지는 문제에는 상대적으로 덜 걱정한다.
   2. 실제 외부 영향은 파일이 아니라 네트워크 통신으로 발생한다. 에이전트의 선한 작업과 악의적인 작업 모두 결국 네트워크를 흐르는 바이트(bytes on the wire)로 나타난다.

3. 모든 외부 행동은 네트워크 바이트로 나타난다

3.1. MCP만 감시해서는 부족한 이유

1. HTTP 바깥의 실행 경로

   1. 에이전트는 Model Context Protocol(MCP) 도구를 호출해 네트워크 요청을 만들 수 있다.
   2. 동시에 서브프로세스를 실행할 수도 있다. Postgres의 경우 에이전트가 psql을 직접 띄우고 HTTP가 아닌 PostgreSQL 프로토콜로 서버와 통신한다.

2. 보안 관찰 단위의 변경

   1. MCP 도구 목록만 검토하면 에이전트가 임의의 CLI를 실행하는 경로를 놓친다.
   2. 따라서 어떤 소프트웨어를 사용했는지가 아니라, 에이전트에서 나가는 모든 바이트가 어떤 프로토콜의 어떤 요청을 표현하는지 검사해야 한다.

3.2. 실제 AWS·EKS·VPC의 우회 시나리오

1. 복잡한 네트워크 토폴로지

   1. Deno의 프로덕션 Postgres는 AWS VPC 안에 있다.
   2. 외부에서 직접 접근할 수 없고 EKS 엔드포인트를 통해서만 사실상 접근할 수 있다.

2. 터널링 공격을 포함한 위협

   1. 에이전트 호스트의 일반적인 ACL을 통과한 뒤 EKS 서버를 터널로 이용하고, 그 안에서 psql을 실행할 수 있다.
   2. 그 경로로 사용자 테이블을 삭제할 수 있다면, “에이전트 호스트에서 Postgres로 직접 연결하지 못한다”는 단순한 규칙은 의미가 없다.

3. 필요한 정책의 성격

   1. 허용해야 할 대상은 에이전트 호스트에서 나가는(outbound) 경로다.
   2. HTTP가 아닌 프로토콜까지 이해해야 한다.
   3. 단순한 IP·포트 규칙이 아니라 SQL을 이해하고 특정 쿼리나 Postgres 함수를 차단하는 규칙이 필요하다.

4. 기존 접근법의 장점과 한계

4.1. ACL과 읽기 전용 자격 증명

1. 기본 원칙으로서의 ACL

   1. 접근 제어 목록(ACL)과 권한 설정, 읽기 전용 Postgres 자격 증명은 반드시 사용해야 한다.
   2. 자격 증명을 신중하게 프로비저닝하면 위험을 낮출 수 있다.

2. 권한 조합의 허점

   1. 여러 시스템에 걸쳐 자격 증명을 아주 조심스럽게 발급해야 한다.
   2. 한 시스템에 접근한 뒤 다른 시스템으로 이동할 수 있으면 각 시스템의 권한을 따로 검토해도 조합(composition)에서 구멍이 생긴다.

4.2. MCP 도구와 서브프로세스의 경계 붕괴

1. 정교한 MCP 도구

   1. MCP를 업무별 도구로 구조화하고 각 도구에 적절한 권한을 부여하면 허용 작업을 세밀하게 제한할 수 있다.
   2. 이 방식은 에이전트가 정의된 MCP 인터페이스만 사용할 때 효과적이다.

2. psql이 만드는 탈출구

   1. OpenClaw가 psql 서브프로세스를 시작하는 순간, MCP 도구의 보안 경계를 벗어난다.
   2. 데이터베이스 프로토콜은 HTTP가 아니므로 일반적인 HTTP 게이트웨이만으로는 같은 통제를 유지할 수 없다.

4.3. 에이전트 앞단의 기존 프로젝트들

1. LLM 게이트웨이

   1. OpenRouter와 LiteLLM 같은 LLM 게이트웨이는 모델 제공자와 오가는 텍스트를 살펴본다.
   2. 가드레일(guardrails) 기능으로 프롬프트 인젝션이나 의심스러운 표현을 검색할 수 있지만, 주로 LLM 호출 자체를 보호한다.
   3. 에이전트가 데이터베이스나 기타 비-LLM 시스템과 직접 통신하는 문제까지 해결하지는 못한다.

2. HTTP 프록시

   1. HTTP Jail은 GET은 허용하되 POST는 금지하거나, 특정 HTTP 서브패스만 허용하는 규칙을 작성하게 한다.
   2. Brex의 Crab Trap은 오가는 HTTP 요청을 LLM judge가 판단한다.
   3. HTTP 계층에 머무는 프록시는 PostgreSQL 같은 비-HTTP 프로토콜과 터널링 경로를 직접 이해하지 못한다.

3. 자격 증명 프록시

   1. Agent Vault 같은 시스템은 에이전트에게 실제 비밀 값을 보여주지 않는다.
   2. 에이전트가 자리 표시자(placeholder)를 보내면 프록시가 바깥으로 나갈 때 자격 증명을 주입한다.
   3. 비밀을 숨기는 것은 중요하지만, 비밀을 가진 요청이 파괴적인지 판정하는 완전한 해결책은 아니다.

4. 운영체제 수준 샌드박스

   1. NVIDIA Open Shell 같은 프로세스 샌드박스는 특정 파일 시스템 경로 접근이나 시스템 호출(syscall)을 제한한다.
   2. 독립 VM 안에서 에이전트를 실행하는 Deno의 위협 모델에서는 파일 시스템 격리보다 네트워크 행위의 세밀한 제어가 더 중요한 문제다.

5. Claw Patrol의 설계

5.1. HTTP보다 낮은 계층의 정책 프록시

1. 프로젝트 성격

   1. Deno 팀이 이 문제를 해결하려고 만든 소프트웨어의 이름은 Claw Patrol이다. 자동 자막에는 일부 구간에서 “Cloud Patrol”이나 “Cloudflare Patrol”로 인식되지만, 처음 소개된 프로젝트명은 Claw Patrol이다.
   2. Claw Patrol은 오픈소스이며 MIT 라이선스로 배포된다.

2. 바이트 단위 검사

   1. 에이전트 앞에 프록시로 배치하고, HTTP 요청만 보는 대신 에이전트에서 흘러나오는 각각의 바이트를 낮은 계층에서 이해한다.
   2. PostgreSQL처럼 HTTP가 아닌 프로토콜의 구조를 해석하고, 요청이 실제로 무엇을 하려는지 규칙 엔진에 전달한다.

5.2. 비밀 값을 숨기는 자격 증명 주입

1. 에이전트에 비밀을 노출하지 않기

   1. Claw Patrol은 Agent Vault처럼 시스템 자격 증명을 보관한다.
   2. 사용하는 에이전트 소프트웨어가 실제 비밀 값을 읽지 못한 채 자리 표시자를 사용하도록 하고, 프록시가 외부 통신 직전에 인증 정보를 주입한다.

2. 지원하는 인증 형태

   1. 단순한 bearer 헤더만 처리하지 않는다.
   2. 쿠키, Postgres, ClickHouse 인증을 다룬다.
   3. 여러 OAuth 프로토콜과 복잡한 AWS Signature Version 4(AWS SigV4) 서명도 지원한다.

5.3. HCL로 관리하는 정밀한 규칙

1. 정책을 코드처럼 관리

   1. 허용하거나 차단할 요청과 외부 동작은 HCL(HashiCorp Configuration Language) 설정 파일에 작성한다.
   2. HCL은 Terraform 설정 언어로도 알려져 있어 인프라 정책을 선언적으로 관리하기에 익숙한 형식이다.

2. Git 리뷰와 변경 추적

   1. Deno 팀은 설정 파일을 Git에 체크인하고 모든 서비스의 권한 정의를 관리한다.
   2. 파일은 약 1,000줄에 이르는 긴 정책 파일이며, 각 변경을 정밀하게 검토한다.

3. Postgres 함수 차단

   1. 규칙 예시로 특정 Postgres 함수 호출을 막는다.
   2. 이 규칙은 PostgreSQL이 비-HTTP 프로토콜인 경우에도 적용된다.
   3. 다른 시스템을 거치는 터널링 상황에서도 최종 프로토콜의 의미를 파악해 파괴적인 동작을 차단하는 것이 목표다.

4. 프로토콜 확장

   1. Claw Patrol은 여러 프로토콜을 지원한다.
   2. 아직 이해하지 못하는 프로토콜을 만났을 때 플러그인 시스템으로 해석기를 확장할 수 있다.

6. 삭제 명령을 실제로 차단하는 흐름

6.1. Codex 데모

1. 의도적으로 위험한 설정

   1. 시연은 라이브가 아닌 녹화 데모이며, Claw Patrol을 “yellow mode”로 실행한다.
   2. 이 모드에서는 사용자가 말한 일을 그대로 실행하도록 Codex를 둔다. 모델이 스스로 거부하는지를 시험하는 데모가 아니다.

2. 요청부터 서브프로세스까지

   1. Codex에 Postgres의 사용자 테이블을 삭제하라고 지시한다.
   2. Codex는 지시에 맞게 psql 서브프로세스를 시작하고 사용자 테이블 삭제 작업을 수행하려 한다.

6.2. 프록시의 차단 지점

1. 프로토콜 연결

   1. psql 서브프로세스가 Postgres 서버로 네트워크 연결을 연다.
   2. 연결은 Claw Patrol을 통과하며, Claw Patrol은 PostgreSQL 프로토콜의 각 바이트를 파싱한다.

2. 파괴적 행동 거부

   1. 규칙 엔진은 해당 요청이 삭제와 같은 파괴적 action임을 파악한다.
   2. Codex나 모델의 판단을 바꾸지 않고도, 프록시가 외부 시스템에 도착하기 전에 그 action을 거부한다.

7. 관찰·승인·운영 보안

7.1. 대시보드와 action 단위 가시성

1. 에이전트별 흐름

   1. Claw Patrol 대시보드 상단에는 여러 디바이스 또는 에이전트가 표시된다.
   2. 각 에이전트에서 흘러가는 요청 중 일부는 거부되고, 일부는 승인을 기다린다.

2. HTTP보다 넓은 action 개념

   1. 특정 흐름을 클릭하면 요청 또는 Claw Patrol이 부르는 “action”의 상세 내용을 볼 수 있다.
   2. action이라는 이름은 HTTP 요청뿐 아니라 Postgres 명령, 다른 프로토콜 동작까지 포괄하기 위해 사용한다.
   3. 분석 화면은 화려한 소비자용 UI보다 Deno 팀이 실제 에이전트를 이해하는 데 필요한 정보를 우선하는 실용적(utilitarian) 도구다.

7.2. 사람과 LLM을 함께 쓰는 승인 체계

1. 차단과 승인의 구분

   1. 모든 규칙이 요청을 무조건 거부해야 하는 것은 아니다.
   2. 위험하지만 정당할 수 있는 action은 승인 대기 상태로 보낼 수 있다.

2. 승인 조합

   1. Slack 채널의 사람에게 승인을 요청한다.
   2. action에 대해 LLM judge를 실행한다.
   3. 먼저 LLM judge를 통과시킨 뒤 Slack에서 사람 승인을 받는 조합도 가능하다.

3. 블랙박스 원칙

   1. Claw Patrol은 OpenClaw, Codex 등 에이전트 소프트웨어를 블랙박스로 취급한다.
   2. 에이전트 코드나 모델 프롬프트를 수정하지 않고도, 외부로 나가는 동작을 정책으로 통제한다.

8. 배포와 신뢰 경계

8.1. Tailscale·WireGuard 기반 연결

1. 사설 네트워크에서 실행

   1. Claw Patrol은 Tailscale 또는 WireGuard 위에서 동작한다.
   2. Deno 팀은 에이전트를 Tailscale tailnet 안에서 실행하며, Claw Patrol이 Tailscale exit node 역할을 하게 한다.

2. 대시보드 인증

   1. Tailscale identity를 대시보드 접근 인증에 활용한다.
   2. 별도의 인증 체계를 하나 더 얹지 않아도, tailnet에 속한 신원이 대시보드 접근 권한을 제공한다.

3. WireGuard 선택지

   1. Tailscale 생태계를 도입하지 않은 사용자도 고려해 WireGuard를 지원한다.
   2. 이 구성으로 에이전트와 인증 정보가 인터넷에 그대로 노출되지 않고, 민감한 운영 시스템을 좁게 통제할 수 있다.

8.2. 프록시 자체가 고가치 자산이 되는 문제

1. Claw Patrol은 프로덕션 시스템의 자격 증명을 보관한다.
2. 따라서 에이전트를 보호하는 프록시도 탈취되면 큰 피해를 줄 수 있는 고가치 자산이며, 운영자는 프록시의 접근·업데이트·네트워크 위치를 엄격하게 관리해야 한다.

주요 발언 모음

“Security can't just be wishful thinking that Opus will always obey your wishes.”
보안은 Opus가 언제나 우리의 뜻을 따를 것이라는 희망적 사고일 수 없다.

“The agents themselves have to be untrusted software.”
에이전트 자체는 신뢰할 수 없는 소프트웨어로 취급해야 한다.

“Every good action that it takes [and every nefarious action] comes in the form of some network communication.”
에이전트의 선한 행동이든 악의적인 행동이든 결국 네트워크 통신의 형태로 나타난다.

“The security boundary has to be elsewhere.”
보안 경계는 에이전트 바깥에 있어야 한다.

“We treat the agent software as a black box.”
에이전트 소프트웨어를 블랙박스로 취급한다.

“I think we're always going to have to have backstop security mechanisms.”
앞으로도 항상 최후 방어선(backstop) 보안 장치가 필요할 것이다.

핵심 데이터·수치·사실

• 18분 37초: Ryan Dahl의 발표와 짧은 질의응답을 포함한 영상 길이다.
• 약 1,000줄: Deno 팀이 서비스별 권한을 선언하는 HCL 정책 파일의 규모다.
• MIT 라이선스: Claw Patrol의 오픈소스 라이선스다.
• 6개 운영 영역: Postgres, Kubernetes, ClickHouse, AWS, GitHub, Slack이 에이전트가 접근하는 대표 시스템으로 언급된다.
• 2가지 네트워크 구현: Tailscale과 WireGuard를 통해 사설 연결을 구성한다.
• 비-HTTP 프로토콜: PostgreSQL 프로토콜을 예시로 들어, HTTP 프록시만으로는 모든 외부 동작을 통제할 수 없음을 보여준다.
• 복수의 인증 방식: bearer 헤더뿐 아니라 쿠키, Postgres, ClickHouse, OAuth, AWS SigV4를 다룬다.
• 3단 승인 조합: 요청을 즉시 거부하는 방식, LLM judge, Slack의 사람 승인을 독립적으로 또는 연속적으로 조합할 수 있다.
• 2개의 Q&A: 규칙 테스트 방법과 에이전트가 더 똑똑해질 때 위험이 커지는지를 묻는 질문이 이어진다.

Q&A: 검증과 모델 성능의 관계

규칙이 제대로 동작하는지 어떻게 테스트하는가

질문자는 Claw Patrol이 위험한 action을 정확하게 막는지 검증하는 방법을 물었다. Ryan Dahl은 권한 규칙 파일 자체에 테스트 시스템이 붙어 있다고 답했다.

1. 규칙을 통과하는 가상 요청인 fixture action request를 만든다.
2. 해당 fixture가 규칙을 거치게 한다.
3. 특정 요청이 항상 차단되는지 확인하는 단위 테스트(unit test)를 작성한다.
4. 규칙 파일 외에도 Claw Patrol 소프트웨어 자체에 대한 대규모 테스트 스위트를 운영한다.

규칙은 설정 파일이라는 이유로 수동 검토에만 의존하지 않고, 위험 요청을 고정된 테스트 입력으로 보존해 회귀(regression)를 감시한다.

에이전트가 더 똑똑해지면 문제는 커지는가, 작아지는가

질문자는 모델 성능이 향상될 때 에이전트 보안 문제가 커지는지 작아지는지 물었다. Ryan Dahl의 답은 양쪽 효과를 함께 인정한다.

1. AI를 완전히 신뢰할 수 있는 날은 오지 않을 것이라고 본다.
2. 모델이 더 똑똑해지고 더 나은 문맥을 갖추면 문제가 줄어든다.
3. 모델이 자신이 회사와 함께 일하고 있다는 사실과 해서는 안 될 일을 이해하면 오작동 가능성이 낮아진다.
4. Opus는 과거 모델보다 더 잘 정렬되어 있다.
5. 그래도 최후 방어선 보안 메커니즘은 항상 필요하다.

답변 뒤 Ryan Dahl은 다른 질문에도 남아 있겠다고 말하며 발표를 마쳤고, 청중의 박수가 이어졌다.

결론 및 시사점

1. 운영 자동화의 실용성은 넓은 맥락에서 나온다. 장애 대응 에이전트가 트레이스, 사용자 데이터, 팀 커뮤니케이션, 배포 기록을 함께 읽을 수 있어야 인간 SRE에 가까운 진단을 수행한다.
2. 넓은 읽기·쓰기 권한은 모델의 선의와 별개로 위험하다. psql과 kubectl 같은 서브프로세스가 만들어내는 비-HTTP 경로까지 위협 모델에 넣어야 한다.
3. 정렬(alignment)은 방어 계층 중 하나일 뿐이다. Opus의 거부 능력은 유용하지만, 외부 데이터의 프롬프트 인젝션으로 판단이 변할 수 있으므로 독립적인 통제가 필요하다.
4. 최종 통제점은 네트워크 경계다. 에이전트가 내보내는 바이트를 프로토콜별로 파싱하면 모델, MCP, CLI, 터널링을 가로질러 실제 action을 판정할 수 있다.
5. 자격 증명 은닉과 행동 권한은 분리해야 한다. 프록시가 비밀을 대신 주입해도 해당 자격 증명으로 실행 가능한 SQL·API·클라우드 동작을 별도 정책으로 제한해야 한다.
6. 정책은 Git과 테스트로 관리해야 한다. 약 1,000줄의 HCL 권한 파일을 변경 이력과 fixture 기반 단위 테스트로 검증하면 보안 규칙의 회귀를 발견할 수 있다.
7. 위험한 action에는 단계적 승인이 적합하다. 무조건 허용·거부만 두지 말고 LLM judge와 Slack의 사람 승인을 조합해 자동화 속도와 책임성을 맞춘다.
8. 보안 프록시도 보호 대상이다. 프로덕션 자격 증명을 보관하는 Claw Patrol은 에이전트보다 높은 신뢰 경계를 제공해야 하며, Tailscale·WireGuard 같은 사설 네트워크와 강한 운영 통제가 필요하다.
9. 더 나은 모델은 위험을 줄이지만 제거하지 않는다. 모델이 회사 맥락과 금지된 행동을 더 잘 이해할수록 사고 가능성은 내려가도, 독립된 backstop 보안 장치는 계속 남아야 한다.