에이전트를 위한 보안 방화벽 — Ryan Dahl과 Deno

URL: https://www.youtube.com/watch?v=MkRYPFIMCSA
날짜: 2026-08-18
채널: aiDotEngineer
발표자: Ryan Dahl, Deno CEO

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

에이전트가 사람처럼 운영 시스템을 폭넓게 다루게 하면서도, 에이전트의 판단이나 내부 보안 플러그인에 보안을 맡기지 않으려면 어떻게 해야 하는가?

• 에이전트는 장애 해결에 필요한 운영 맥락을 얻기 위해 PostgreSQL, Kubernetes, ClickHouse, AWS, GitHub, Slack 등에 읽기·쓰기 권한을 가질 수 있다.
• Opus처럼 정렬(alignment)이 좋은 모델도 외부 입력에 의한 프롬프트 인젝션(prompt injection)으로 조작될 수 있으므로, “모델이 알아서 나쁜 일을 거부할 것”이라는 기대만으로는 보안이 성립하지 않는다.
• 실제 악성·정상 행위는 MCP 호출뿐 아니라 서브프로세스와 비HTTP 프로토콜을 포함한 네트워크 바이트로 나타나므로, 에이전트 바깥의 보안 경계에서 통신 내용을 직접 검사하고 통제해야 한다.
• Deno가 만든 Claw Patrol은 HTTP보다 낮은 계층에서 에이전트의 통신을 파싱하고, 프로토콜별 규칙·자격 증명 주입·승인 흐름을 적용하는 MIT 라이선스 오픈 소스 프록시다.

Ryan Dahl의 결론은 에이전트의 정렬을 계속 개선하되, 에이전트를 **신뢰할 수 없는 소프트웨어(untrusted software)**로 취급하고 보안 경계를 에이전트 외부에 두어야 한다는 것이다. 사람이 운영하는 것과 같은 접근성을 주되, 파괴적 행동은 독립적인 정책 계층이 차단해야 한다.

---

1. Deno Deploy 장애 대응에 에이전트를 투입하다

Deno의 실제 운영 경험이 문제의 출발점이다. 웹사이트 호스팅 서비스인 Deno Deploy에는 간헐적인 장애와 다운타임이 있고, PagerDuty의 무서운 알람이 한밤중의 당직자를 깨운다.

1.1. 사람이 처리하던 장애를 자동화하는 실험

1. Deno와 Ryan Dahl의 배경

   1. 발표자: Ryan Dahl은 Deno의 CEO이며 오랫동안 소프트웨어를 개발해 왔다.
   2. 대표 프로젝트: 많은 사람이 알고 있을 프로젝트로 Node.js를 언급한다.
   3. 현재 제품: Deno에서 운영하는 Deno Deploy는 웹사이트 호스팅 시스템이다.

2. 장애 대응 에이전트

   1. 문제의 상황: Deno Deploy는 가끔 다운타임이 발생하고 PagerDuty가 호출된다.
   2. 자동화 방향: Deno는 최근 에이전트를 사용해 이런 인시던트(incident)를 자동으로 처리하는 방식을 시험하고 있다.
   3. 사용 대상: 특히 OpenClaw를 사용하며, 다른 에이전트들도 함께 검토한다.
   4. 핵심 관찰: 이 방식이 꽤 잘 작동하는 패턴을 찾아 공유하려는 것이 발표의 목적이다.

1.2. 폭넓은 권한이 주는 운영 맥락

1. 연결하는 시스템

   1. 데이터베이스·클러스터: PostgreSQL, Kubernetes, ClickHouse에 접근한다.
   2. 클라우드·개발·소통 시스템: AWS, GitHub, Slack에도 접근한다.
   3. 권한의 범위: OpenClaw에는 단순 조회를 넘어 해당 시스템에 대한 실제 읽기·쓰기(read/write) 권한도 부여한다.

2. 사람이 보던 맥락을 에이전트가 수집

   1. 관측 데이터: ClickHouse에서 trace를 확인한다.
   2. 제품·사용자 맥락: 운영 PostgreSQL에서 특정 사용자가 어떤 프로젝트를 소유하는지 확인한다.
   3. 조직 맥락: Slack의 커뮤니케이션과 GitHub 로그를 검색한다.
   4. 효과: 이전에는 사람이 중간에 개입해야 했던 상당수 인시던트를 에이전트가 해결할 수 있게 됐다.

---

2. 정렬된 모델을 믿는 것만으로는 보안이 되지 않는다

에이전트에게 강한 권한을 주면 장애 해결력은 올라가지만, 같은 권한이 파괴적 행동의 가능성도 만든다.

2.1. 권한이 악용될 수 있는 구체적 경로

1. 데이터베이스 파괴

   1. 에이전트가 psql 서브프로세스를 시작할 수 있다.
   2. 그 프로세스로 users 테이블을 삭제하는 명령을 실행할 수 있다.

2. 클러스터 파괴

   1. 에이전트가 kubectl delete namespace prod를 호출할 수 있다.
   2. 인시던트를 해결한다는 목표를 잘못 해석해 모든 사용자를 제거하는 것이 해결책이라고 판단할 수도 있다.
   3. Deno가 원하는 것은 장애 해결이지 사용자와 프로덕션 네임스페이스를 없애는 것이 아니다.

2.2. Opus의 정렬과 그 한계

1. 현재 모델의 방어적 성향

   1. Deno는 Opus를 사용한다.
   2. Opus에게 users 테이블을 삭제하라고 아무리 유도해도 반복해서 거부할 정도로 “놀라울 만큼 잘 정렬되어” 있다.

2. 보안의 전제는 희망이 될 수 없다

   1. 모델이 항상 지시를 올바르게 해석하고 파괴적 행동을 거부할 것이라는 기대는 보안 정책이 아니다.
   2. 지원 시스템에 연결된 에이전트는 외부 입력을 받으므로 프롬프트 인젝션에 노출된다.
   3. 공격자가 어떤 문자열을 보내면 모델이 나쁜 상태로 들어가 바람직하지 않은 행동을 “올바른 조치”라고 착각할 가능성을 배제할 수 없다.
   4. 따라서 모델의 alignment는 유용한 방어층이지만 독립적인 보안 경계를 대체하지 못한다.

2.3. 에이전트를 신뢰할 수 없는 소프트웨어로 취급하기

1. 보안 경계의 위치

   1. 에이전트가 자기 행동을 스스로 보호한다고 가정해서는 안 된다.
   2. 에이전트 내부에 보안 가드(guard)를 넣는 방식만으로는 충분하지 않다.
   3. 에이전트 자체를 untrusted software로 보고 외부 계층에서 행동을 통제해야 한다.

2. 파일 시스템 격리와 네트워크 통제의 분리

   1. Deno는 에이전트를 standalone VM에서 실행하므로 파일 시스템은 시스템 수준에서 격리된다.
   2. 따라서 에이전트가 VM 내부 파일을 만지는 문제는 핵심 관심사가 아니다.
   3. 정상적인 행동이든 악의적인 행동이든 결국 외부 시스템에 영향을 주려면 네트워크를 통한 바이트(bytes over the wire)가 필요하다.
   4. 이 바이트가 만들어지는 경로를 통제하는 것이 더 직접적인 보안 지점이다.

---

3. 모든 통신 경로를 포함하는 보안 모델

에이전트의 행동을 HTTP 요청만으로 환원하면 우회 경로를 놓친다.

3.1. MCP와 서브프로세스가 만드는 네트워크 바이트

1. 행동이 나타나는 방식

   1. 에이전트는 MCP를 통해 도구를 호출할 수 있다.
   2. 동시에 서브프로세스를 실행해 직접 서비스에 연결할 수도 있다.
   3. 따라서 “허용된 MCP 도구만 제공하면 안전하다”는 설계는 서브프로세스 경로를 설명하지 못한다.

2. PostgreSQL의 비HTTP 경로

   1. PostgreSQL은 HTTP가 아닌 프로토콜을 사용한다.
   2. OpenClaw는 psql을 서브프로세스로 실행한 뒤 PostgreSQL 서비스에 연결할 수 있다.
   3. 이 통신은 일반적인 HTTP 프록시나 LLM 게이트웨이만으로는 충분히 검사하기 어렵다.
   4. Deno의 입장은 에이전트에서 나오는 바이트가 어떤 의미인지 매우 세밀하게 이해해야 한다는 것이다.

3.2. AWS VPC와 EKS 터널링 사례

1. 현실의 복잡한 토폴로지

   1. Deno의 프로덕션 PostgreSQL 데이터베이스는 AWS VPC 안에 있다.
   2. 데이터베이스는 사실상 EKS 엔드포인트를 통해서만 접근할 수 있다.
   3. 에이전트에는 원칙적으로 거의 모든 것에 접근할 수 있는 권한을 주고 싶지만, 그 권한이 네트워크 토폴로지의 허점으로 변하면 안 된다.

2. 막아야 할 우회 시나리오

   1. 에이전트가 EKS 서버를 경유해 터널을 만들 수 있다.
   2. 그 터널을 통해 psql을 실행하고 users 테이블을 삭제할 수 있다.
   3. 즉, 한 경로는 HTTP가 아니고 다른 시스템을 통과하며 SQL을 이해하는 정책이 없으면, 표면적인 ACL만으로는 파괴적 SQL을 막기 어렵다.
   4. 목표는 사람이 하듯 필요한 시스템에 접근하게 하면서도, SQL을 이해하는 규칙으로 위험한 outbound path를 차단하는 것이다.

3.3. 접근 권한의 조합이 만드는 구멍

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

   1. ACL과 권한 설정, PostgreSQL read-only credential은 여전히 유효한 기본 방어 수단이다.
   2. 자격 증명을 신중하게 프로비저닝해야 한다.
   3. 그러나 여러 시스템에 걸쳐 권한을 조합해야 하므로 설정 비용과 실수 가능성이 커진다.

2. 구성적 접근의 한계

   1. 에이전트가 시스템 A에 접근한 뒤 시스템 B에 접근할 수 있으면, 두 권한의 조합에서 새 우회 경로가 생길 수 있다.
   2. MCP 도구를 각각 최소 권한으로 설계할 수 있지만, OpenClaw가 psql 서브프로세스를 생성하는 순간 도구 단위의 보안 경계를 벗어난다.
   3. 따라서 개별 credential과 도구 권한만으로는 실제 운영 환경의 조합적 위험을 다 설명할 수 없다.

---

4. 기존 보안 도구와 Claw Patrol의 위치

Ryan Dahl은 기존 프로젝트들이 문제의 일부를 해결하지만, 에이전트의 모든 네트워크 경로를 포괄하지는 못한다고 구분한다.

4.1. 기존 접근법의 범위와 빈틈

1. LLM 게이트웨이

   1. OpenRouter와 LiteLLM 같은 LLM gateway는 익숙한 예시다.
   2. 프롬프트 인젝션을 막거나 LLM 제공자와 오가는 표현을 스캔하는 guardrail 기능을 제공하는 경우가 많다.
   3. 하지만 이 계층은 LLM과 제공자 사이의 대화만 다루며, 데이터베이스·클러스터와 에이전트가 주고받는 프로토콜까지 통제하지는 않는다.

2. HTTP 프록시

   1. HTTP Jail은 GET은 허용하되 POST는 거부하거나, 특정 HTTP 하위 경로만 허용하는 규칙을 작성할 수 있다.
   2. Brex의 CrabTrap은 오가는 HTTP 요청을 LLM judge가 평가하는 프로젝트다.
   3. 둘 다 HTTP 계층에는 유용하지만 PostgreSQL 같은 비HTTP 프로토콜의 SQL 의미를 직접 통제하는 해법은 아니다.

3. 자격 증명 주입 프록시

   1. Agent Vault 같은 방식은 에이전트가 실제 자격 증명을 보지 못하게 한다.
   2. 에이전트는 placeholder를 보내고 프록시가 외부로 나갈 때 실제 credential을 주입한다.
   3. 비밀 값 노출을 줄이는 중요한 요소지만, 어떤 요청을 허용할지 판단하는 완전한 해결책은 아니다.

4. 프로세스 샌드박스

   1. NVIDIA OpenShell 같은 도구는 운영체제 수준에서 파일 시스템 경로나 시스템 콜 접근을 제한한다.
   2. Deno는 standalone VM으로 에이전트를 이미 격리하므로 파일·시스템 콜 보호가 이 발표의 핵심 문제는 아니다.
   3. 중요한 것은 VM 안에서 어떤 명령을 실행했는지가 아니라 외부로 나가는 통신의 의미와 권한이다.

4.2. Claw Patrol의 설계

1. 프로젝트 성격

   1. Claw Patrol은 Deno가 이 문제를 해결하기 위해 만든 오픈 소스 프로젝트다.
   2. MIT 라이선스로 배포되며 에이전트 앞에 놓이는 프록시다.

2. HTTP보다 낮은 계층에서 모든 바이트 검사

   1. Claw Patrol은 HTTP 계층에만 머무르지 않고 더 낮은 계층에서 동작한다.
   2. 에이전트에서 흘러나오는 각각의 바이트를 이해하고, HTTP가 아닌 PostgreSQL 같은 프로토콜도 파싱한다.
   3. MCP 호출과 서브프로세스가 만든 연결을 모두 동일한 정책 계층에서 관찰하는 것이 목표다.

3. 비밀 값 차단과 정밀한 규칙

   1. Agent Vault처럼 자격 증명을 보관하고 에이전트가 실제 secret value를 보지 못한 채 placeholder를 사용하도록 만든다.
   2. 어떤 요청이 어떤 조건에서 에이전트 밖으로 전달되는지 정밀한 규칙으로 지정한다.
   3. 이 규칙은 에이전트 코드나 플러그인을 고치지 않고도 적용된다.

4.3. HCL로 관리되는 정책

1. 정책을 코드처럼 관리

   1. 규칙은 Terraform의 설정 언어로 알려진 HCL(HashiCorp Configuration Language)로 작성한다.
   2. 구성 파일을 Git에 커밋하고 변경 사항을 매우 신중하게 검토한다.
   3. Deno의 모든 서비스에 대한 권한을 정의하는 파일은 약 1,000줄에 달한다.
   4. 권한 파일의 각 변경을 세밀하게 관리함으로써 정책의 변화를 추적할 수 있다.

2. 프로토콜 의미를 이해하는 규칙

   1. 예시 규칙은 PostgreSQL의 특정 함수 호출을 차단한다.
   2. PostgreSQL이 비HTTP 프로토콜이라는 사실은 규칙 적용의 장애가 되지 않는다.
   3. 다른 시스템을 통해 PostgreSQL 연결이 터널링되어도 Claw Patrol은 내용을 파싱해 규칙을 적용한다.
   4. 여러 프로토콜을 지원하며, 아직 익숙하지 않은 프로토콜을 만났을 때 확장할 수 있는 플러그인 시스템도 제공한다.

---

5. 동작 데모와 운영자 제어면

5.1. Codex의 파괴적 요청을 네트워크에서 거부하기

1. 데모 설정

   1. 데모는 생방송이 아니라 녹화 또는 사전 준비된 시연이다.
   2. claw patrol run codex를 “yellow mode”로 실행한다.
   3. Codex에게 PostgreSQL의 users 테이블을 삭제하라고 지시한다.

2. 에이전트의 실제 행동과 방화벽의 판정

   1. Codex는 지시에 따라 psql 서브프로세스를 시작하고 users 테이블 삭제를 시도한다.
   2. psql은 PostgreSQL 서버로 네트워크 연결을 연다.
   3. 연결은 Claw Patrol을 통과하고, Claw Patrol은 모든 바이트를 파싱하면서 PostgreSQL 프로토콜을 해석한다.
   4. 정책 규칙이 적용된 뒤 해당 요청은 “destructive action”으로 판정되어 최종적으로 거부된다.
   5. 모델이 거부한 것이 아니라 모델이 행동하더라도 외부 정책 계층이 파괴적 요청을 차단한다는 점이 핵심이다.

5.2. 대시보드와 액션 관찰

1. 요청을 넘어 액션을 보는 화면

   1. Claw Patrol 대시보드는 여러 장치 또는 에이전트와 그 에이전트에서 흘러나오는 요청을 보여준다.
   2. 어떤 요청은 거부되고, 어떤 요청은 승인이 필요하다는 상태가 표시된다.
   3. HTTP 요청보다 넓은 의미를 담기 위해 각 단위를 “action”이라고 부른다.

2. 상세 분석

   1. 각 액션을 클릭하면 실제로 무슨 일이 일어나는지 세부 내용을 확인할 수 있다.
   2. 분석 기능은 화려한 소비자용 UI보다 Deno 운영자가 자신의 에이전트를 이해하는 데 필요한 실용성에 초점을 맞춘다.
   3. 어떤 통신이 어떤 정책에 걸렸는지 확인하는 관찰면이 정책 운영의 피드백이 된다.

5.3. 거부·LLM 심사·사람 승인의 조합

1. 규칙이 취할 수 있는 세 가지 경로

   1. 규칙은 요청이나 액션을 즉시 거부할 수 있다.
   2. Slack 채널에서 사람에게 승인을 요청할 수 있다.
   3. LLM judge를 실행해 별도의 판정을 받을 수 있다.

2. 조합 가능한 승인 흐름

   1. LLM judge를 먼저 통과시킨 뒤 Slack에서 사람의 승인을 받는 식으로 여러 단계를 연결할 수 있다.
   2. 이 흐름은 에이전트 소프트웨어 바깥에서 동작하므로 에이전트를 블랙박스로 취급해도 된다.
   3. 기존 에이전트 코드나 에이전트 자체의 보안 플러그인을 수정할 필요 없이, 외부 정책으로 실행 범위를 조정한다.

5.4. 현실적인 자격 증명과 네트워크 배치

1. 다양한 자격 증명 형식

   1. credential은 단순한 bearer header만을 뜻하지 않는다.
   2. Claw Patrol은 cookie, PostgreSQL credential, ClickHouse credential을 다룬다.
   3. OAuth 계열 프로토콜과 AWS SigV4처럼 복잡한 서명 방식도 지원한다.
   4. 이 폭넓은 지원은 상상 속 시나리오가 아니라 실제 운영 시스템을 대상으로 만들어졌다는 점을 보여준다.

2. TailScale과 WireGuard

   1. Claw Patrol은 Tailscale 또는 WireGuard 위에서 동작한다.
   2. Deno는 에이전트를 Tailscale 내부의 Tailnet에서 실행하고 Claw Patrol을 Tailscale exit node로 사용한다.
   3. 대시보드 인증에도 Tailscale identity를 활용하므로 별도의 인증 메커니즘을 추가로 얹지 않아도 된다.
   4. Tailscale 생태계를 사용하지 않는 사람을 위해 WireGuard도 선택지로 제공한다.
   5. 이 배치로 시스템을 인터넷에서 떼어 놓고 보안에 민감한 구성 요소를 강하게 통제한다.

3. 프록시 자체의 위험

   1. Claw Patrol이 프로덕션 시스템의 모든 자격 증명을 보관하므로 그 자체가 민감한 보안 구성 요소다.
   2. 방화벽을 설치했다고 끝나는 것이 아니라 Claw Patrol의 운영·접근·비밀 관리도 매우 조심해야 한다.

---

6. 핵심 주장과 실용적 시사점

1. 신뢰 모델

   1. 에이전트가 더 똑똑해져도 에이전트가 스스로를 감시하도록 맡길 수는 없다.
   2. 보안 플러그인이나 에이전트 소프트웨어 내부 수정 역시 같은 신뢰 경계 안에 있으므로 충분한 독립 방어가 아니다.
   3. 보안 경계는 에이전트 외부, 더 높은 수준의 정책 계층에 있어야 한다.

2. 정렬의 올바른 위치

   1. Ryan Dahl은 alignment 자체가 나쁘다고 말하지 않는다.
   2. 더 잘 정렬되고 더 많은 맥락을 이해하는 모델은 위험한 행동을 줄이는 데 분명히 도움이 된다.
   3. 그러나 실제 보안 시스템에는 항상 backstop security mechanism, 즉 정렬이 실패해도 마지막으로 막아 주는 독립 보안 장치가 필요하다.

3. Claw Patrol의 지향점

   1. Claw Patrol은 Deno가 실제 운영 환경에서 사람에 가까운 에이전트 접근성을 확보하면서도 파괴적 통신을 차단하려는 시도다.
   2. 정책은 프로토콜을 이해하는 규칙, 외부 자격 증명 주입, 대시보드, 사람·LLM 승인으로 구성된다.
   3. 가장 중요한 설계 원칙은 에이전트가 어떤 내부 결정을 했는지가 아니라, 외부로 나가는 최종 행동을 독립적으로 검증하고 통제하는 것이다.

---

주요 발언 모음

“보안은 Opus가 항상 여러분의 뜻을 따를 것이라는 희망적 사고일 수 없다.”

“에이전트 자체를 신뢰할 수 없는 소프트웨어로 취급해야 한다.”

“에이전트 안에 가드를 넣을 수는 없다.”

“에이전트가 취할 수 있는 모든 악의적인 행동과 모든 선의적인 행동은 결국 네트워크 통신, 즉 전선을 통한 바이트의 형태로 나타난다.”

“에이전트는 스스로를 감시하도록 신뢰할 수 없다. 보안 경계는 다른 곳에 있어야 한다.”

“정렬은 좋은 일이지만, 실제 보안 시스템에서는 더 높은 수준에서 통제해야 한다.”

---

핵심 데이터 & 수치

• 약 1,000줄: Deno의 모든 서비스 권한을 정의하며 Git에서 신중하게 관리하는 HCL 규칙 파일의 규모다.
• MIT 라이선스: Claw Patrol의 오픈 소스 라이선스다.
• 지원 프로토콜의 범위: HTTP에 한정하지 않고 PostgreSQL, ClickHouse, OAuth 계열, AWS SigV4 등 실제 시스템의 다양한 통신을 다룬다.
• 네트워크 배치: Tailscale/Tailnet과 WireGuard를 지원하며, Tailscale에서는 Claw Patrol을 exit node로 사용한다.
• 테스트 단위: 규칙 파일에 fixture action/request를 흘려보내 항상 차단되는지 검증하는 단위 테스트 체계가 포함된다.

---

Q&A

질문 1. 규칙과 Claw Patrol이 제대로 작동하는지 어떤 테스트를 하는가?

1. 정책 파일 테스트

   1. 규칙 파일 자체에 테스트 시스템이 함께 있다.
   2. fixture action 또는 fixture request를 규칙을 통과시키고, 특정 요청이 규칙 집합에 의해 항상 차단되는지 단위 테스트로 검증한다.

2. 제품 테스트

   1. Claw Patrol 소프트웨어 자체에도 대규모 테스트 스위트가 있다.
   2. 정책 파일의 회귀(regression)와 프록시 구현의 회귀를 분리해 확인할 수 있다.

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

1. 위험이 줄어드는 이유

   1. 더 똑똑한 에이전트는 더 나은 맥락을 이해한다.
   2. 자신이 회사의 시스템과 함께 일하고 있다는 사실과 해서는 안 될 행동을 더 잘 이해한다.
   3. Opus는 이전 모델보다 더 정렬되어 있으므로 우발적 위험은 줄어든다.

2. 그래도 남는 결론

   1. AI를 완전히 신뢰할 수 있는 시점은 오지 않을 것이라고 본다.
   2. 따라서 모델이 똑똑해질수록 문제의 빈도는 낮아져도, backstop security mechanism은 항상 필요하다.

---

결론

에이전트에게 사람과 비슷한 운영 권한을 주는 것은 복잡한 장애를 빠르게 해결하는 강력한 방법이지만, 동시에 데이터베이스 삭제·프로덕션 네임스페이스 제거·자격 증명 악용 같은 사고를 불러올 수 있다. 안전한 설계는 모델의 선의나 프롬프트 인젝션 저항성을 전제로 하지 않는다. standalone VM으로 로컬 실행 환경을 격리하고, 에이전트 바깥에서 모든 outbound 통신을 프로토콜 의미 단위로 검사하며, 위험한 액션을 거부하거나 LLM과 사람의 승인을 거치게 해야 한다. Claw Patrol은 이 원칙을 PostgreSQL 같은 비HTTP 프로토콜과 서브프로세스 터널링까지 확장하려는 실용적 구현이다.

---

핵심 요약 (20줄)

Deno Deploy의 간헐적인 다운타임과 PagerDuty 호출은 에이전트 자동화의 실전 출발점이 된다. Deno는 OpenClaw를 비롯한 에이전트에게 PostgreSQL, Kubernetes, ClickHouse, AWS, GitHub, Slack 접근 권한을 부여한다. 폭넓은 권한은 trace, 사용자 프로젝트, Slack 대화, GitHub 로그를 한데 모아 장애 원인 파악을 돕는다. 에이전트는 과거에 사람이 개입하던 많은 인시던트를 자동으로 해결할 수 있다. 같은 권한은 psql로 users 테이블을 삭제하거나 kubectl로 prod 네임스페이스를 제거하는 경로가 된다. Opus가 파괴적 요청을 반복해서 거부해도 모델의 정렬만으로 보안을 보장할 수 없다. 지원 시스템의 외부 입력은 프롬프트 인젝션으로 에이전트의 판단을 위험하게 바꿀 수 있다. 에이전트는 자기 행동을 보호할 수 없는 신뢰할 수 없는 소프트웨어로 취급해야 한다. standalone VM은 파일 시스템을 격리하지만 외부 시스템에 영향을 주는 네트워크 통신까지 막지는 않는다. MCP 호출과 서브프로세스는 모두 외부로 나가는 바이트를 만들며 PostgreSQL은 HTTP가 아닌 프로토콜을 사용한다. AWS VPC의 PostgreSQL에 EKS를 거쳐 터널링하는 우회 경로는 단순 ACL의 한계를 드러낸다. 읽기 전용 자격 증명과 MCP 최소 권한은 필요하지만 여러 시스템 권한의 조합적 구멍을 없애지 못한다. OpenRouter와 LiteLLM의 가드레일은 LLM 대화를 보호하지만 데이터베이스 프로토콜을 통제하지 않는다. HTTP Jail과 CrabTrap은 HTTP 요청을 제어하지만 PostgreSQL 같은 비HTTP 통신은 놓친다. Agent Vault의 자격 증명 주입은 비밀 값 노출을 줄이지만 허용할 요청을 결정하지는 않는다. Claw Patrol은 에이전트 앞에서 HTTP보다 낮은 계층의 모든 바이트를 파싱하는 MIT 오픈 소스 프록시다. HCL로 작성한 약 1,000줄의 Git 관리 정책은 PostgreSQL 함수와 파괴적 액션을 정밀하게 차단한다. Claw Patrol은 Codex가 psql로 users 테이블을 삭제하려 해도 PostgreSQL 프로토콜 규칙으로 요청을 거부한다. 대시보드는 액션을 관찰하고 Slack 승인과 LLM judge를 조합해 에이전트 밖에서 통제한다. 더 똑똑한 AI는 위험을 줄이지만 독립적인 backstop security mechanism은 항상 필요하다.