delego

delego

ウェブサイト： delegohq.com · ドキュメント： delegohq.com/docs · 仕様： Delego-Dev/specification

AI エージェントの意図に基づくアクション認可。 エージェントと、ユーザーの秘密情報を保管するクレデンシャルブローカーの間に位置し、ブローカーが答えられない一つの問いに答えます。この特定のアクションは、人間が実際に依頼したことなのか？

   agent  ──propose──▶  delego  ──if allowed──▶  credential broker  ──▶  service
   (LLM)               (policy +                (Agent Vault /         (bank,
                        approval +               OneCLI /               SaaS,
                        audit)                   Browser Use…)          API)
                           │
                           └── needs_approval ──▶  human (CLI)

📜 プロトコル： delego は、オープンな delego wire specification の protocol 0.3 を実装しています。正規化、ポリシースキーマ、意図とフィンガープリントの紐付け（§4.2 のクエリ折りたたみを含む）、署名付き監査チェーンに対応しています。認可トークン（仕様 §9）はオプションのプロファイルであり、まだ実装されていません。

これが必要な理由

「エージェントに専用のスコープ付きクレデンシャルを与え、ユーザーの秘密情報を直接持たせない」というパターンは、今や競合が増え、収束しつつある分野です。Infisical の Agent Vault、OneCLI、Browser Use、Nango などは、いずれもクレデンシャルブローカー機能を提供しています。

より難しい問題は、その一段上にあります。混乱した代理人です。エージェントが 有効な クレデンシャルを持ち、プロンプトインジェクションによって動作をそらされ、そのスコープが アクションを許可している ため、ブローカーは問題なく秘密情報を注入し、アクションが実行されます。クレデンシャルは有効なので、これを検出するのに適した場所ではありません。OAuth トークンには、元の指示との結び付きがありません。

クレデンシャルだけでなく、アクションを認可することは、現在取り組みが進む分野です。決定論的なポリシーエンジン（OPA／Cedar、Permit）、人間の承認を組み込む仕組み（HumanLayer）、MCP ゲートウェイ／ファイアウォール、「アクション前認可」に関する研究などが挙げられます。delego はそのための、小規模な決定論的でローカルな Apache-2.0 のリファレンス実装です。判定プロセスに LLM は使わず、クレデンシャルも保持しません。承認はアクションの正確なフィンガープリントに紐付き、署名付きのハッシュチェーン監査証跡を備えています。既存のブローカーレイヤーと競合せず、それを活用します。

できること／できないこと

• できること： 判定と監査のレイヤーです。決定論的なポリシー、機密性の高いアクションに対する人間の承認、署名付きの追記専用監査台帳を提供します。
• できないこと： クレデンシャル保管庫やプロキシではありません。薄い BrokerAdapter インターフェースを通じて実行をブローカーに委ねます。既存のレイヤーを再構築するのではなく、それを活用できます。
• 認可は純粋な Python で行われ、LLM は介在しません。 モデルが上流で助言することはできますが、クレデンシャルの使用を許可する判定は確率的なループの外で行われるため、インジェクションによって判定を覆すことはできません。

主な特性

1. 意図の紐付け — すべてのアクションには、元の人間の指示のハッシュが含まれ、監査台帳に記録されます。解決時にも再確認されるため、承認を別の指示だと主張するものに付け替えることはできません。
2. アクションに紐付いた一度限りの承認 — 人間の「はい」は、特定のアクションフィンガープリント一つに紐付きます。アクション A の承認を得たエージェントは、それを使ってアクション B を実行することはできず（混乱した代理人への対策）、同じ承認を再利用してアクション A を二度実行することもできません。承認によってアクションが実行されるのは一度だけです。
3. 改ざんを検知できる監査 — レシートは Ed25519 署名付きのハッシュチェーンを形成します。レシートの編集、並べ替え、削除、またはフィールドの削除は検証に失敗し、台帳を信頼せずに問題を報告します。注意点（正確に）： ハッシュチェーンでは、直近のレシートが途中で切り詰められたことは 検知できません（末尾が切り詰められたプレフィックスは正常に検証されます）。また、ローカルの署名鍵ではホストの侵害を防げません。ロールバックを検知するには、ヘッドを外部に保存し、verify(expected_head=…) に渡してください。鍵の安全性には HSM／KMS を使用してください。SECURITY.md を参照してください。

クイックスタート

pip install delego          # the `delego` library + CLI
# pip install "delego[mcp]" # add the `delego-mcp` server (MCP is an optional extra)
delego init               # creates ~/.delego with signing keys and an example policy
delego policy             # inspect the active policy

クローンからエンドツーエンドで一連の流れを実行できます。許可される読み取り、拒否される禁止操作、上限超過による拒否、承認フロー、差し替えられたアクションを拒否する混乱した代理人ガード、監査チェーンの改ざん検出を試せます（エージェントや稼働中のサービスは不要です）。

git clone https://github.com/Delego-Dev/delego && cd delego
pip install -e ".[dev]"
python examples/demo.py
pytest

人間側（CLI）

delego policy            # show the active policy
delego pending           # list actions awaiting approval
delego approve apr_xxxx  # release a parked action (or: delego deny apr_xxxx)
delego log -n 20         # read recent receipts
delego verify            # check the audit chain (hashes, linkage, signatures)

エージェント側（MCP）— Claude Code への接続

delego は stdio 経由で MCP サーバー（delego_mcp）を提供します。mcp エクストラを使ってインストールしてください：pip install "delego[mcp]"。MCP 設定（Claude Code の場合はプロジェクトルートの .mcp.json）に登録すると、エージェントが アクションを提案できるようになります。DELEGO_HOME を設定して、ポリシー、署名キー、台帳を プロジェクト単位の .claude/.delego に保持します。

{
  "mcpServers": {
    "delego": {
      "command": "delego-mcp",
      "env": { "DELEGO_HOME": "/abs/path/to/project/.claude/.delego" }
    }
  }
}

そのホームを初期化し、同じ場所から承認します（CLI と MCP サーバーは同じホームを 共有する必要があります）。

delego --home .claude/.delego init       # keys, example policy, and a .gitignore
delego --home .claude/.delego pending    # ...then: delego --home .claude/.delego approve apr_xxxx

DELEGO_HOME が未設定の場合、CLI はプロジェクトルートから実行されたときに ./.claude/.delego を自動的に使用し、それが存在しない場合は ~/.delego にフォールバックします。（サーバーの起動ディレクトリは保証されないため、MCP の env では絶対パスを使用してください。）

公開されるツール：

ツール	機能
delego_propose_action	アクションを送信し、allow / deny / needs_approval を返します
delego_resolve_action	承認済みのアクションを完了します（フィンガープリントの一致が必要です）
delego_pending	人間の承認を待っているアクションを一覧表示します（読み取り専用）
delego_audit_tail	最近の記録を読み取ります
delego_show_policy	有効なポリシーを表示します

承認と拒否は意図的に MCP 経由では公開されません。アクションを提案したエージェントが そのアクションを承認できてはならず、人間が別経路で判断します。

一般的な流れ：エージェントが delego_propose_action を呼び出します。approval_id を伴う needs_approval が返された場合、人間が delego approve <id> を実行し、その後 エージェントが同一のアクションで delego_resolve_action を呼び出して完了します。

ポリシー形式

ルールは method / host / path（glob）/ path_contains に基づいて一致し、 allow または needs_approval を決定し、制約を追加できます。評価順序は、禁止 （強制拒否）→ルール（最初に一致したルールを適用）→default です。一致したルールの 制約を満たさない場合は拒否されます（フェイルクローズ）。policy.example.yaml を参照してください。

rules:
  - name: place-order
    decision: needs_approval
    match: { method: POST, host: api.example.com, path: /orders }
    constraints:
      amount:     { field: amount, max: 5000, currency: USD }
      allow_list: { field: destination, in: [internal] }

サポートされる制約：amount（上限＋通貨）、allow_list （フィールドが指定セットに含まれるか）、rate_limit（分／時／日あたりの最大数。台帳から集計）。

delego を使って構築する

利用方法は3通りあります。手軽な順に紹介します。

• MCP サーバーとして — delego init を実行し、MCP 設定に delego-mcp サーバーを追加すると、エージェントはアクションを実行する代わりに提案します。コードは不要です。
• ライブラリとして — pip install delego を実行し、ポリシーと BrokerAdapter を記述して、 ツール呼び出しの処理経路で fw.propose(...) を呼び出します。
• サービスの背後で — Firewall を HTTP API でラップすると、複数のエージェントが 1つの判断ポイントと1つの監査チェーンを共有できます。

拡張ポイントは broker だけです。認証情報を保持し、承認されたアクションを実際に実行する場所です。delego がシークレットを保持することはありません。

• NullBroker（デフォルト）— 実行をシミュレートします。デモやテスト向けです。
• HTTPProxyBroker(gateway_url) — 承認されたアクションを外部の認証情報ゲートウェイ （OneCLI / vault / proxy）に転送し、そこで上流にシークレットを注入します。
• 独自の実装 — delego/brokers.py の BrokerAdapter プロトコルに沿って execute(action) -> dict を実装します。

▶ Delego-Dev/sample-app — 公開済みパッケージを使って構築された FastAPI サービスです。提案 → 承認 → 解決の全フローと、そのままコピーして使える curl の手順を掲載しています。独自のものを構築する際の最適な出発点です。

delego の今後の予定や協力できる内容については、ROADMAP.md をご覧ください。

ステータス

• 実装済み（プロトコル 0.3）： ポリシーエンジン、インテントのハッシュ化、アクションのフィンガープリント化 （URL クエリをフィンガープリントに含める）（仕様 §4.2 — /orders?to=me と /orders?to=attacker は異なるアクションです）、Confused Deputy ガード、インテントに紐づく単回使用の人間による承認、検証機能と外部ヘッドアンカーチェック（delego verify --expected-head）を備えた署名付きハッシュチェーン監査台帳、および §9 認可トークン（オプションのプロファイル） — 分離されたブローカーが認証情報を注入する前に検証する、短命で EdDSA 署名付きの JWS（build_firewall(..., mint_tokens=True)、verify_token / require_fingerprint）。
• シングルライターのデーモン（delego daemon）：1 つの長時間稼働プロセスが台帳を管理するため、すべてのクライアントがそこを経由し、rate_limit は全クライアントで正確に適用されます。1 台のホスト上のファイルロックだけに依存しません。CLI の approve／deny／pending は、稼働中のデーモンに自動的に接続します。オプションとして、デーモンがない場合も、従来どおりすべてファイルベースで動作します。
• ブローカー： デフォルトの NullBroker は認証情報を保持せず、実際のリクエストも送信しません。デモやテスト用に、送信されるはずの内容を記録します。HTTPProxyBroker は認可されたアクションとその認可トークンを外部の認証情報ゲートウェイに転送します。または、delego/brokers.py の BrokerAdapter プロトコルに準拠する独自のブローカーを作成できます。
• 未実装： デーモンへの MCP エージェントサーフェスの自動ルーティング（現状ではファイアウォールに直接接続しています。次のステップはその接続です）、TCP／ホスト間のデーモントランスポート（現在はローカルの Unix ソケットです）、および非 MCP の HTTP サーフェス。
• 既知の制限： デーモンを使用しない場合、ファイルベースの台帳と承認ストアへの同時書き込みは OS のファイルロックで直列化されます（破損を防ぎます）。また、rate_limit が正確に適用されるのは、1 台のホスト上で同じホームディレクトリを共有するプロセス間のみです。すべてのクライアント間で正確なレート制限を適用するには、delego daemon を実行してください（ライターは 1 つです）。デーモンは一度に 1 つのアクションを直列に処理します（処理能力を高めるための予約後実行の最適化と、他のホスト向け TCP トランスポートは今後の課題です）。パスのグロブ処理は大まかです（** と * は同じように扱われます）。

ライセンス

Apache License 2.0 の下でライセンスされています。