curiositech/windags-skills

Agentic Zero-Trust Security（エージェンティックゼロトラストセキュリティ）

自律型AIエージェントシステムのための暗号化セキュリティアーキテクチャ。このスキルは、従来のセキュリティエンジニアリングと、信頼境界を越えて計画、永続化、委任、実行するエージェントのユニークな課題の交点をカバーします。

核となる原則: 決して信頼せず、常に検証する — これはすべてのエージェント間メッセージ、読み込まれるすべてのスキル、呼び出されるすべてのツール、返されるすべての結果に適用されます。

判断ポイント

1. 脅威レベル → 検証戦略

脅威レベル評価:
├── PUBLIC（インターネット上のエージェント、未知のスキル）
│   ├── アクション: 完全なmTLS + JWS + ケイパビリティトークン + WASMサンドボックス
│   ├── 監査: すべてのアクションをマークルプルーフ付きでログ記録
│   └── TTL: 最大5分のケイパビリティ有効期間
├── INTERNAL（信頼されたエージェントクラスタ）
│   ├── アクション: mTLS + JWS + ケイパビリティ（より長いTTL）
│   ├── 監査: 日次ルート公開による集約ログ出力
│   └── TTL: 最大1時間のケイパビリティ有効期間
└── DEV/TEST（ローカルホスト、開発環境）
    ├── アクション: オプションのmTLS + 基本的なケイパビリティ
    ├── 監査: ローカルファイルログ（マークルツリーなし）
    └── TTL: 最大24時間のケイパビリティ有効期間

2. エージェントリクエスト → ケイパビリティチェック → 許可/拒否ロジック

受信エージェントリクエスト処理:
├── 1. mTLS証明書チェーンの検証
│   ├── 有効なCA署名？ → 続行
│   └── 無効または期限切れ？ → 即座にREJECT
├── 2. JWSメッセージエンベロープの解析
│   ├── 署名が有効で期限切れでない？ → 続行
│   ├── リプレイ検出（jtiキャッシュ）？ → REJECT
│   └── 署名が無効？ → REJECT + セキュリティイベントをログ
├── 3. 必要なケイパビリティの確認
│   ├── エージェントが正確なケイパビリティを保持？ → GRANT
│   ├── エージェントがより広範なケイパビリティを保持？ → ATTENUATE + GRANT
│   ├── ケイパビリティの期限切れ？ → REJECT + 強制リフレッシュ
│   └── 一致するケイパビリティなし？ → REJECT + 最小権限付与を提案
└── 4. サンドボックス制約付きで実行
    ├── WASMスキル: CPU/メモリ制限を適用
    ├── ファイル操作: ケイパビリティに対するパス検証
    └── ネットワーク呼び出し: ケイパビリティに対する宛先検証

3. 委任チェーン → 信頼深度の決定

ケイパビリティ委任リクエスト:
├── 親ケイパビリティのdelegatable=true？
│   ├── はい → 残りの深度を確認
│   │   ├── 深度 > 0 → 深度を1減らして許可
│   │   └── 深度 = 0 → REJECT（最大委任深度に達しました）
│   └── いいえ → REJECT（委任不可）
├── 要求されたアクション ⊆ 親アクション？
│   ├── はい → サブセットを許可
│   └── いいえ → REJECT（権限を昇格できません）
└── 信頼境界を越えたか？
    ├── 同じオーケストレータドメイン → 許可
    └── 異なるドメイン → 明示的なクロスドメインケイパビリティが必要

障害モード

1. アンビエント権限の漏洩

検出: grep -r "process.env" agent_code/ がケイパビリティチェックなしの環境変数アクセスを示す 症状: エージェントが権限を持つべきでないリソースにアクセスする 修正: 必要なリソースに正確にスコープされた明示的なケイパビリティトークンに置き換える

2. メッセージリプレイ攻撃

検出: 同一の jti（メッセージID）またはリプレイウィンドウ内のタイムスタンプを持つ複数の監査ログエントリ 症状: エージェントが同じコマンドを複数回受信して処理する 修正: メッセージの有効期限に一致するTTLを持つjti重複排除キャッシュを実装する

3. 委任によるケイパビリティ昇格

検出: 子ケイパビリティが親よりも多くのアクションを持っている、または委任深度が設定された最大値を超えている 症状: サブエージェントが親委任者の意図よりも多くの権限を取得する 修正: 委任時に減衰不変条件を適用する: 子ケイパビリティ ⊆ 親ケイパビリティ

4. リソース枯渇によるサンドボックスエスケープ

検出: エージェントCPU使用率が30秒以上95%超、またはメモリ使用量がサンドボックス制限に近づいている 症状: エージェントが無限ループまたは過剰なメモリアロケーションを試みて制約から抜け出そうとする 修正: リソース制限でエージェントプロセスをハードキルし、燃料ベースの実行メータリングを実装する

5. TOFU（初回使用時信頼）証明書受け入れ

検出: エージェントが最初の接続時にCA検証なしで証明書を受け入れる 症状: 中間者攻撃が任意の証明書を提示することで成功する 修正: すべてのエージェント証明書を事前プロビジョニングし、明示的なトラストストアを維持し、未知のCAを拒否する

実践例

例1: マルチエージェントメッセージ署名パイプライン

シナリオ: リサーチエージェントが分析をコード生成エージェントに渡し、さらにレビューエージェントに渡す必要がある。

セットアップフェーズ:

// オーケストレータがケイパビリティを発行
const researchCap = mint.mint('fs:/tmp/research/**', ['read','write'], 'agent-research-001');
const codegenCap = mint.mint('fs:/workspace/src/**', ['read','write'], 'agent-codegen-001'); 
const reviewCap = mint.mint('fs:/workspace/**', ['read'], 'agent-review-001');

メッセージフロー:

1. Research → Codegen: リサーチエージェントがJWS署名メッセージを作成:

   Header: {alg: 'EdDSA', kid: 'agent-research-001/v1'}
   Payload: {
     iss: 'agent-research-001',
     sub: 'agent-codegen-001', 
     dag_id: 'proj-alpha-v1',
     action: 'task',
     body: {analysis: "API needs OAuth2 flow", output_path: "/tmp/research/api_analysis.json"}
   }
   

2. Codegenによる検証: Codegenエージェントがメッセージを受信:

   • リサーチエージェントの公開鍵に対してJWS署名を検証
   • メッセージTTLをチェック（期限切れでないこと）
   • jtiがリプレイキャッシュにないことを確認
   • dag_idが現在の実行コンテキストと一致することを確認
   • エキスパートの着眼点: リサーチエージェントがoutput_pathに対するケイパビリティを持っていたことを検証

3. Codegen → Review: Codegenが署名付き結果を作成:

   {
     "iss": "agent-codegen-001",
     "sub": "agent-review-001",
     "action": "result", 
     "body": {"generated_files": ["/workspace/src/auth.ts"], "confidence": 0.87}
   }
   

初心者の見落とし: jtiリプレイ保護をスキップし、重複処理を許可してしまう。 エキスパートの洞察: 監査証跡は、暗号化された保管証明付きの完全なメッセージチェーンを示す。

例2: 減衰を伴うケイパビリティトークン発行

シナリオ: メインエージェントがファイル分析を専門のサブエージェントに委任する必要があるが、機密ディレクトリへのアクセスを制限する必要がある。

初期付与:

// オーケストレータが広範なファイルシステムアクセスを付与
const mainCap = mint.mint('fs:/project/**', ['read','write','execute'], 'agent-main', {
  delegatable: true,
  maxDepth: 2,
  ttlSeconds: 3600
});

減衰判断ツリー:

メインエージェントが委任リクエストを評価:
├── サブエージェントリクエスト: fs:/project/src/** [read]
│   ├── /project/src/** ⊂ /project/** ? YES
│   ├── [read] ⊂ [read,write,execute] ? YES  
│   ├── 委任深度 2 > 0 ? YES
│   └── GRANT: 減衰されたケイパビリティを作成
├── サブエージェントリクエスト: fs:/project/secrets/** [read]  
│   ├── パスに "secrets" が含まれる → セキュリティポリシー違反
│   └── REJECT: 機密パス除外
└── サブエージェントリクエスト: fs:/etc/passwd [read]
    ├── /etc/passwd ⊂ /project/** ? NO
    └── REJECT: 許可された範囲外

生成された減衰ケイパビリティ:

const subCap = mint.attenuate(mainCap, 'agent-analyzer-001', ['read']);
// 結果: fs:/project/src/** [read] delegatable=true maxDepth=1 ttl=3600s

初心者の見落とし: 制限なしで完全な親ケイパビリティを付与してしまう。 エキスパートの洞察: 減衰は、暗号レベルで「決して権限を昇格しない」ことを強制する。

例3: トレードオフ分析を伴うサンドボックスポリシー違反検出

シナリオ: コード生成エージェントが実行中にネットワークアクセスを試み、サンドボックスポリシーに違反する。

サンドボックス設定:

const codegenSandbox = {
  fileRead: ['/workspace/src/**', '/workspace/package.json'],
  fileWrite: ['/workspace/src/**'], 
  netConnect: false,  // ネットワークアクセス不可
  maxExecutionMs: 300000,
  maxMemoryMb: 512
};

違反検出フロー:

1. エージェントアクション: Codegenが fetch('https://api.github.com/repos/...') を試行

2. サンドボックスインターセプト: WASMランタイムがネットワークソケットのシステムコールをキャッチ

3. ポリシーチェック: netConnect: false → 違反を検出

4. トレードオフ分析:

   セキュリティ対機能性のトレードオフ:
   ├── STRICT（現在）: ネットワークをブロック、エージェントを終了
   │   ├── 利点: ネットワーク攻撃面がゼロ
   │   ├── 欠点: 外部依存関係/ドキュメントを取得できない
   │   └── 決定: 強制（セキュリティ最優先環境）
   ├── MODERATE: 特定のホワイトリストドメインを許可
   │   ├── 利点: 既知の優良APIに対して機能
   │   ├── 欠点: DNSポイズニング、サブドメイン乗っ取りのリスク
   │   └── 決定: 開発環境のみ検討
   └── PERMISSIVE: ログは取るが許可
       ├── 利点: 完全な機能性を維持
       ├── 欠点: エージェントがデータを外部送信、マルウェアをダウンロード可能
       └── 決定: REJECT（ゼロトラストモデルに違反）
   

5. 応答: エージェントを終了し、セキュリティイベントをログ:

   {
     "event": "sandbox_violation",
     "agent_id": "agent-codegen-001", 
     "violation_type": "unauthorized_network_access",
     "attempted_url": "api.github.com",
     "policy_matched": "netConnect: false",
     "action_taken": "terminate_agent"
   }
   

初心者の見落とし: 「今回だけ」ネットワークアクセスを許可したり、違反を検出しなかったりする。 エキスパートの洞察: サンドボックス違反は、潜在的な侵害やモデルのドリフトを示す — 常に厳格に強制する。

品質ゲート

• すべてのエージェントが一意の暗号化アイデンティティ（Ed25519キーペア + 証明書）を持つ
• すべてのエージェント間チャネルが、証明書検証付きの相互TLSを使用する
• すべてのメッセージが5分未満のTTLとjtiリプレイ保護付きのJWS署名を持つ
• ケイパビリティトークンがocapモデルに従う（どこにもアンビエント権限なし）
• ケイパビリティ委任が減衰不変条件を維持する（子 ⊆ 親の権限）
• 監査証跡が公開されたルートを持つ追加専用マークルツリーを使用する
• すべてのスキル実行がWASMまたはコンテナサンドボックス内で行われる
• リソース制限が適用される（CPU、メモリ、実行時間、ネットワーク）
• スキルパッケージがコンテンツアドレス指定され、作成者署名されている
• どのエージェントも署名なしまたは未検証のスキル/入力を許可しない
• 証明書のローテーションが自動化され、24時間未満の証明書有効期間
• リプレイ検出キャッシュがメッセージの有効期限と一致するTTLで動作している
• すべてのセキュリティ違反が、タイムスタンプ + エージェントID + 実行されたアクションとともにログに記録される

NOT-FOR 境界

このスキルを以下の用途に使用しないでください:

• アプリケーションレベルの脆弱性スキャン → security-auditor を使用
• ネットワークファイアウォール/WAFの設定 → infrastructure-engineer を使用
• SOC2/HIPAAコンプライアンス文書 → 組織のコンプライアンスプロセスを使用
• プロンプトインジェクション対策 → prompt-engineer スキルを使用
• レート制限またはDDoS対策 → APIゲートウェイ設定を使用
• コンテナオーケストレーションのセキュリティ → devops-automator スキルを使用

委任境界:

• コードレベルのセキュリティ問題 → security-auditor
• インフラストラクチャの堅牢化 → infrastructure-engineer
• セキュアコーディングプラクティス → software-engineer
• インシデント対応 → security-incident-response