テック技報最新号へ →

AIコーディング

Claw Patrol: エージェントと本番の間に「プロトコルを読むファイアウォール」を置く

Deno 製の OSS（MIT、alpha）。エージェントの通信をゲートウェイに通し、HTTP・SQL・Kubernetes・SSH の中身を解析してルールで許可／拒否／人の承認を決める。本物の認証情報はゲートウェイが持ち、エージェントには渡さない。

@deno_land · 投稿 2026-05-21

#ai-coding#セキュリティ#エージェント#本番運用#承認

どんな時に使う？

運用エージェントに本番 DB や k8s の読み取りをさせたいが、DROP TABLE や kubectl delete は絶対させたくない
エージェントの環境に API キーを平文で置きたくない

仕組みと手順

エージェントの通信を WireGuard／Tailscale でゲートウェイへ。ゲートウェイが TLS を終端し、プロトコルを解析、資格情報を付けて転送

bash

clawpatrol gateway config.hcl   # ゲートウェイ起動
clawpatrol run claude           # 1つのエージェントのプロセスだけを通す
clawpatrol join <gateway-url>   # ホスト全体を通す

ルールは HCL＋CEL 式
hcl
```
rule "k8s-no-secrets" {
  endpoint  = k8s-prod
  condition = "k8s.resource == 'secrets'"
  verdict   = "deny"
}
```
SQL は sql.verb / sql.tables、HTTP は http.method / http.path / http.body_json、SSH は ssh.verb（pty / exec など）で条件を書ける
verdict は allow / deny のほか、LLM による方針チェック→Slack で人が承認、のような承認チェーンも組める
clawpatrol test で記録した操作を新しいポリシーに再生し、判定のずれを回帰テストできる

注意点

alpha 段階。まず読み取り専用のエンドポイントから
エージェント側を改造せずに効く反面、ゲートウェイ自体が重要資産になる。置き場所とアクセス管理を厳しく
関連: エージェントを隔離して動かす選択肢（nono / Docker Sandboxes / agentos / VPS）

出典

@deno_land · 2026-05-21
Tailscale での構成例: @undefined_void · 2026-05-22
公式: deno.com/blog/clawpatrol ／ github.com

X の元の投稿を開く