エージェント向けセキュリティファイアウォール — Ryan Dahl氏、Deno

エージェントは「信頼できない」：Deno CEO Ryan Dahl 氏が語る、AI エージェントの新たなセキュリティパラダイム

AI エージェントがインシデント対応に活用される中で、モデル自体の倫理設定やプロンプト注入対策だけでは不十分であるという懸念が浮上しています。Deno の CEO、Ryan Dahl 氏は、エージェントを「信頼できないソフトウェア」と見なし、そのセキュリティ境界を内部ではなく外部、すなわち通信レベルに設けるべきだと主張します。

この考えに基づき開発されたのが、HTTP に依存せずネットワークの全バイトを解析するプロキシ「Claw Patrol」です。認証情報を隠蔽し、厳密なルールでエージェントの行動を制御することで、広範なアクセス権を与えつつも安全に運用するための新しいセキュリティパラダイムが提示されました。

エージェントは「信頼できないソフトウェア」である

Deno では現在、OpenClaw などの AI エージェントを活用して、深夜の警報（PagerDuty）への対応やインシデント解決を自動化しています。エージェントには PostgreSQL、Kubernetes、AWS、GitHub、Slack など、あらゆるシステムへの書き込み権限が与えられています。

これにより、エージェントはコンテキストを深く理解し、人間よりも迅速に問題を解決できるケースが増えています。しかし、その反面で重大なリスクも存在します。

「エージェントが悪意のある操作を行う可能性があります。例えば、psql サブプロセスを起動して users table を削除したり、prod ネームスペースを削除したりするかもしれません。」

モデル自体が「ユーザーテーブルは削除しない」というプロンプトに従うとしても、それは「願望」に過ぎません。Dahl 氏は、セキュリティをモデルの善意や倫理設定に依存させることは不十分だと断言します。

「セキュリティは、モデルが常にあなたの願いに従ってくれるという希望的観測であってはなりません。」

さらに、エージェントはサポートシステムと接続されているため、外部からのプロンプト注入（Prompt Injection）によって乗っ取られるリスクがあります。悪意のある文字列を送り込むことで、正常な状態にあるはずの AI が誤った判断を下し、破壊的な行動をとる可能性を否定できません。

そのため、Deno のスタンスは明確です。エージェント自体を信頼せず、その内部にセキュリティ機能を実装しようともしないことです。エージェントはスタンドアロンの VM で実行されファイルシステムレベルでは隔離されていますが、すべての悪意ある行為も善意の行為も、最終的にはネットワーク通信（バイト）として外部へ流出します。

従来の認証管理や HTTP プロキシでは不十分

「なぜ既存のセキュリティ対策ではダメなのか」という点について、Dahl 氏はいくつかの限界を指摘しています。

まず、ロールベースのアクセス制御（RBAC）や読み取り専用クレデンシャルの付与です。確かに、特定のデータベースに読み取り権限しか持たせないことは有効ですが、システム間の連携（コンポジション）によってセキュリティホールが生まれる可能性があります。例えば、エージェントが一度 EKS エンドポイントにアクセスできれば、そこから psql を起動して直接データベースを操作し、ユーザーテーブルを削除してしまうような迂回経路が存在します。

また、MCP（Model Context Protocol）でツールを細かく定義するアプローチも限界があります。MCP ツールは安全なインターフェースを提供しますが、エージェントが psql などのサブプロセスを直接起動して通信を開始した場合、そのセキュリティ境界はすぐに突破されてしまいます。

既存の解決策として、LLM ゲートウェイ（OpenRouter や Light LLM など）やHTTP プロキシ（HTTP Jail、CrabTrap など）が挙げられます。これらはプロンプト注入の検出や HTTP リクエストのフィルタリングに優れていますが、Dahl 氏は以下の理由で不十分だと結論付けています。

1. LLM ゲートウェイ: LLM とのプロセス間のやり取りには有効ですが、データベースとの通信など、非 LLM の領域までカバーしきれません。
2. HTTP プロキシ: HTTP レベルでのフィルタリングは強力ですが、PostgreSQL や ClickHouse といった非 HTTP プロトコルには対応できません。エージェントが psql を起動して直接接続するケースでは機能しません。
3. Agent Vault などのクレデンシャル注入プロキシ: エージェントから機密情報を隠蔽し、プロキシ側で注入する仕組みは重要ですが、通信内容の解析や制御という点では不完全です。

「エージェントが psql を起動して接続を試みるような、非 HTTP プロトコルを含むすべての通信バイトを解析できるソリューションが必要です。」

Claw Patrol：ネットワークレベルで全バイトを解析するファイアウォール

これらの課題に対処するために開発されたのが、Claw Patrolです。これは MIT ライセンスのオープンソースプロキシであり、HTTP レベルではなく、より低いレイヤーである「通信バイト」レベルで動作します。

技術的な特徴

• 非 HTTP プロトコルの完全対応: PostgreSQL、ClickHouse など、SQL やその他の非 HTTP プロトコルを含むすべてのネットワーク通信を解析できます。エージェントが psql サブプロセスを起動して接続を試みても、そのパケットストリームを完全に監視・制御可能です。
• 認証情報の隠蔽と注入: エージェント側には機密情報（クレデンシャル）が見えません。代わりに、Claw Patrol がプロキシとして動作し、通信経路で安全に認証情報を注入します。これにより、エージェント自体が秘密鍵やパスワードを漏洩するリスクを排除できます。
• 多様なプロトコルサポート: AWS Sigv4、Cookie、OAuth など、複雑な認証形式にも対応しており、プラグインシステムによって新しいプロトコルへの拡張も可能です。

HCL による厳密なルール制御

Claw Patrol の核心は、HCL（HashiCorp Configuration Language）を用いたルール定義にあります。Terraform で使われる言語と同じ HCL を使用することで、管理者は Git に管理された構成ファイルを通じて、エージェントの行動を極めて細かく制御できます。

例えば、特定の関数呼び出しを拒否するルールや、承認フローを定義することが可能です。

「users table の削除を試みる PostgreSQL 関数の呼び出しをブロックするルール」

このルールは、単に「許可/拒否」だけでなく、以下のような柔軟な承認フローもサポートしています。

• LLM 判定: 特定のアクションが安全かどうかを別の LLM に判断させる。
• 人間承認: Slack チャンネルなどに通知し、人間の承認を待つ。
• 組み合わせ: まず LLM でフィルタリングし、その後で人間の承認を得るなど、複数の条件を組み合わせることができます。

実運用におけるセキュリティと可視性

Claw Patrol は単なる理論上の概念ではなく、Deno の本番環境で実際に稼働しています。Dahl 氏は、このシステムがTail ScaleやWireGuard上で動作し、エージェントの通信経路を完全に制御していることを明かしました。

• ネットワーク構成: エージェントは Tail Net 内のスタンドアロンの VM で実行され、Claw Patrol が Exit Node として機能します。これにより、すべての通信が外部インターネットを経由せず、厳密に管理されたパスを通ります。
• 可視性ダッシュボード: Claw Patrol にはダッシュボードがあり、エージェントの行動をリアルタイムで監視できます。どのリクエストが許可され、どのアクションが拒否されたか、あるいは承認待ちの状態かが一目でわかります。

「私たちはエージェントソフトウェアをブラックボックスとして扱います。その内部に何らかの変更を加える必要はありません。」

このアプローチにより、開発者は「広範なアクセス権」を与えつつも、「ネットワーク層での厳密な制限」をかけるという、両立していたはずの矛盾を解消しています。

まとめ

AI エージェントが自律的に動作する本番環境において、モデルの倫理設定や従来の認証管理だけでは不十分です。Deno の Ryan Dahl 氏が提唱するのは、エージェント自体を「信頼できない」と見なし、その通信経路に独立したプロキシ（Claw Patrol）を配置してセキュリティ境界を設定するという新しいパラダイムです。

ネットワークレベルでの全バイト解析と HCL による厳密なルール制御により、開発者はエージェントに高い自由度を与えつつも、破壊的な操作を確実に防止することが可能になります。これは、AI エージェントの実用的な運用における重要な指針となるでしょう。