[한영자막] AI 에이전트에게 DB 쓰기 권한을 주면 생기는 일과 Deno의 보안 해결책 (Ryan Dahl)

한 줄 핵심

AI 에이전트가 생산 시스템을 실제로 돕게 하려면 모델의 정렬에 기대지 말고, 네트워크 바이트 수준에서 권한·자격증명·승인 흐름을 통제하는 외부 보안 경계가 필요하다.

시간별 요약

1. 0:00
   Deno Deploy와 야간 알람 Deno Deploy의 장애 대응에 OpenClaw 같은 에이전트를 활용해 보니, Postgres·Kubernetes·ClickHouse·AWS·GitHub·Slack 등 여러 시스템에 접근시켜도 실제로 많은 인시던트를 해결할 수 있었다. 다만 이런 접근은 생산 환경을 직접 건드리는 만큼 보안 설계가 핵심 문제로 떠올랐다.
2. 1:15
   에이전트에게 프로덕션 쓰기 권한 부여하기 에이전트가 프로덕션 데이터와 운영 로그를 직접 볼 수 있을 때 장애 원인 파악은 매우 강력해지지만, 동시에 users table 삭제나 namespace 삭제 같은 파괴적 행동도 가능해진다. 즉, 가시성과 실행 권한을 함께 주는 방식은 효율적이지만 위험도 함께 키운다.
3. 2:34
   Opus의 거절과 모델 정렬만으로 부족한 이유 Opus는 삭제 요청을 잘 거절할 만큼 정렬이 뛰어나지만, 그것만으로 보안을 맡길 수는 없다. 지원 시스템과 연결된 에이전트는 외부에서 prompt injection을 당할 수 있어, 모델 내부의 의지만으로 안전을 보장할 수 없다.
4. 3:15
   고객 지원 시스템을 통한 프롬프트 인젝션 위협 에이전트는 악의적인 문자열 입력에 의해 잘못된 상태로 유도될 수 있으므로, 에이전트 자체를 신뢰하는 접근은 성립하지 않는다. 보안 경계는 모델 내부가 아니라 모델 바깥에 있어야 한다.
5. 3:52
   모든 액션은 네트워크 바이트 단위로 일어난다 에이전트의 행동은 파일 조작보다 결국 네트워크 통신으로 나타나므로, 바깥으로 나가는 바이트를 정밀하게 이해하고 제어해야 한다. MCP 호출이든 sub process든, 실제 위험은 프로토콜과 바이트 흐름에서 발생한다.
6. 5:11
   난제: EKS 엔드포인트를 통한 psql 터널링 VPC 내부의 production Postgres를 EKS endpoint를 통해서만 접근할 수 있어도, 에이전트가 psql을 띄워 터널링하면 users table을 지우는 식의 우회가 가능하다. 복잡한 네트워크 토폴로지에서는 단일 ACL만으로 이런 우회 경로를 막기 어렵다.
7. 6:34
   자격증명과 ACL만으로 충분하지 않은 이유 읽기 전용 credential이나 세밀한 ACL은 필요하지만, 여러 시스템을 조합해 접근할 때 생기는 권한 구멍까지 자동으로 막아주지는 못한다. 특히 MCP 도구를 잘 나눠도 sub process 실행이 열려 있으면 경계가 쉽게 무너진다.
8. 7:13
   MCP 도구 권한의 한계와 서브프로세스 문제 LLM gateway나 HTTP proxy는 LLM이나 HTTP 요청 수준의 제어에는 유용하지만, Postgres 같은 비HTTP 프로토콜과 sub process 실행까지 포괄하지는 못한다. 따라서 에이전트가 실제로 내보내는 전체 바이트를 다루는 별도 계층이 필요하다.
9. 8:35
   기존 프록시와 샌드박스 보안 생태계 비교 HTTP Jail, Crab Trap, Agent Vault, Open Shell 같은 기존 도구들은 각각 프롬프트 필터링, HTTP 규칙, 자격증명 주입, OS 샌드박스에 강점이 있다. 하지만 standalone VM을 쓰는 환경에서는 더 낮은 레벨에서 프로토콜과 권한을 함께 통제하는 방식이 필요하다.
10. 9:56
    Claw Patrol 소개 Claw Patrol은 에이전트 앞단에 위치해 바깥으로 나가는 각 바이트를 해석하고, 자격증명을 안전하게 주입하는 오픈소스 프록시다. 핵심은 에이전트 소프트웨어를 바꾸지 않고도 외부로 나가는 행동을 세밀하게 제어하는 데 있다.
11. 10:37
    HCL 언어로 보안 규칙 작성하기 보안 정책은 HCL 설정 파일로 관리되며, Deno 내부 서비스 전체의 권한을 정의하는 큰 규칙 집합으로 운영된다. Postgres 함수 차단처럼 프로토콜 수준의 세부 규칙도 여기에 포함되고, 다른 시스템을 경유한 터널링에도 적용된다.
12. 11:54
    프로토콜 플러그인 확장 구조 Claw Patrol은 여러 프로토콜을 기본 지원하고, 아직 모르는 프로토콜은 plug-in으로 확장할 수 있다. 이어지는 데모에서는 codex가 psql sub process를 통해 users table을 삭제하려 해도, 네트워크 바이트 해석과 규칙 적용으로 차단된다.
13. 12:39
    데모: 유저 테이블 삭제 쿼리 즉시 차단 Postgres 프로토콜을 이해하는 상태에서 요청 바이트를 읽고 규칙을 적용하면, 파괴적인 action을 즉시 거절할 수 있다. 단순한 프롬프트 차단이 아니라 실제 실행 경로를 중간에서 막는 방식이라는 점이 중요하다.
14. 13:21
    Claw Patrol 대시보드와 활동 모니터링 대시보드에서는 여러 에이전트의 요청 흐름과 거부·승인 상태를 확인할 수 있고, 각 action의 세부 내용과 analytics도 볼 수 있다. 운영자가 에이전트 행동을 이해하고 추적하는 관측성 도구로도 작동한다.
15. 14:01
    LLM Judge 및 Slack 사람 승인 워크플로우 규칙은 단순 거절뿐 아니라 LLM judge나 Slack 사람 승인으로 이어지게 할 수 있어, 위험한 요청에 단계적 검증을 붙일 수 있다. 이를 통해 에이전트 소프트웨어 자체를 수정하지 않고도 정교한 승인 흐름을 구성한다.
16. 14:45
    자격증명 안전 주입 (AWS SigV4, OAuth, 쿠키) 자격증명은 bearer header만이 아니라 쿠키, Postgres, ClickHouse, OAuth, AWS SigV4처럼 다양한 형태로 존재하므로, 프록시는 이를 폭넓게 처리해야 한다. 에이전트가 secret value를 직접 보지 않게 하면서도 실제 시스템과 안전하게 연결하는 것이 목표다.
17. 15:25
    Tailscale 및 WireGuard 연동 아키텍처 시스템은 Tailscale 또는 WireGuard 위에서 동작하며, Claw Patrol은 Tailscale exit node처럼 배치되고 대시보드 인증도 Tailscale identity로 처리한다. production credential을 쥔 컴포넌트를 인터넷 밖에 두는 구조가 보안의 전제가 된다.
18. 16:45
    에이전트는 스스로를 통제할 수 없다 에이전트 보안은 에이전트 내부의 alignment나 플러그인에 기대지 말고, 더 높은 수준의 외부 경계에서 통제해야 한다. 더 똑똑한 모델은 도움이 되지만, backstop security mechanism은 여전히 필요하다.
19. 17:29
    Q&A: 룰 파일 테스트 및 검증 방법 룰 파일은 fixture request를 넣어 unit test처럼 검증할 수 있고, 특정 요청이 항상 차단되거나 승인되도록 자동화할 수 있다. Claw Patrol 자체도 별도의 대규모 테스트 스위트로 검증한다.
20. 18:09
    Q&A: 모델이 더 똑똑해지면 이 문제가 줄어들까? 모델이 더 똑똑해지고 맥락을 더 잘 이해할수록 문제는 줄어들 수 있지만, AI를 완전히 신뢰하는 단계에는 도달하기 어렵다. 따라서 모델 성능 향상과 별개로 보안 차단 장치는 계속 유지해야 한다.

실무 인사이트

• 에이전트 보안은 프롬프트 필터링보다 네트워크·프로토콜·자격증명 경계에서 설계해야 실효성이 높다.
• 생산 환경에서 에이전트를 쓰려면 읽기 권한과 쓰기 권한을 분리하는 것만으로는 부족하고, sub process와 터널링 경로까지 포함해 검증해야 한다.
• 실무에서는 전면 허용/전면 차단보다, 규칙 차단·사람 승인·LLM judge를 단계적으로 조합한 통제 전략이 더 현실적이다.