AI Agentは、危険を検知しただけで端末を隔離してよいのか──Trust Infrastructureによるサイバー封じ込めデモ

🎥 The YouTube version is also available:

ランサムウェア対応をAI Agentに任せる前に｜Trust Infrastructureによる安全な隔離とDecision Trace

Books: Trust Infrastructure実践ガイド: Decision Trace・Knowledge Flow・Trust EngineによるAI時代の信頼基盤設計

生成AIやAI Agentを業務へ導入するとき、セキュリティはしばしば「AI Agentをどう止めるか」という問いから始まる。

たとえば、ある端末にランサムウェアの兆候が現れたとする。不審な地域からのログイン、未知のPowerShell実行、短時間での大量ファイル変更、共有フォルダへのアクセス試行、別端末への認証試行。AIがそれらを検知したとき、直ちに端末をネットワークから隔離すべきだろうか。

隔離が遅れれば被害は広がる。一方で、誤検知なら利用者の仕事を止める。対象が会計締めや基幹業務を担うサーバーなら、隔離そのものが大きな業務影響を生む。

ここには、検知精度だけでは解けない問題がある。

AIが危険だと判断したことと、AIが実行してよいことは同じではない。

この問いを具体化するため、Chinoba PFの要であるTrust Infrastructureの応用として、AI Agentがサイバー攻撃の兆候を受けて端末を封じ込めるデモを作成した。本デモが示すのは、攻撃を見つけるAIではない。根拠、ポリシー、権限、承認、実行、復旧を一つのDecision Traceとして接続し、AIに安全に委任できる範囲を設計する仕組みである。

検知から、検証可能な行動へ

デモでは、経理部の端末 FIN-LT-042 に複数の異常が連続して現れる。

• 通常と異なる地域からの認証成功
• 未知のPowerShell実行
• ファイル暗号化・大量リネームの兆候
• 経理共有フォルダへのアクセス試行
• 同じ資格情報を用いた別端末へのログイン試行

重要なのは、これらを単に「危険度の高いアラート」として並べないことである。Identity Provider、EDR、ファイルサーバー、端末ログ、脅威インテリジェンスという異なる出所のEvidenceを、時刻と対象IDを含めて結び付ける。

すると、AI Agentは「ランサムウェア感染、または認証情報侵害の可能性が高い」という仮説を提示できる。しかし、ここで自動隔離を実行するわけではない。次に、その行動が許される条件を検証する。

Trust Envelopeが確認する六つの条件

デモの中心には、行動の可否を確認するTrust Envelopeがある。これは、AIの提案をそのまま実行するのではなく、少なくとも次の条件を束ねて確認する枠組みである。

たとえば本デモでは、SEC-IR-4.2 というポリシーにより、「高信頼度の暗号化挙動を検出し、業務重要度がCriticalではない端末」に限り、最大30分の自動隔離を許可する。

Containment Agentに委任されているのは、一般端末の限定時間のネットワーク隔離だけである。サーバー停止、アカウント削除、データ消去といった不可逆性や業務影響の大きい操作は、最初から権限外としている。

ここで重要なのは、AI Agentに「自由な自律性」を与えることではない。組織が明示した条件の内側でのみ、速く行動できるようにすることである。

三つの分岐で示す、委任の境界

デモでは、同じContainment Agentが三つの異なる判断を行う。

1. FIN-LT-042：条件内なので自動隔離する

一般的な経理端末 FIN-LT-042 では、Evidenceが十分で、端末の重要度はMedium、Agentの委任権限とポリシーの条件も満たしている。

この場合、Agentは30分間の限定的な隔離を実行できる。一般ネットワークを遮断しつつ、SOCが調査・復旧するための限定通信は維持する。実行後にはSOC担当者へ通知され、隔離時間の延長、解除、復旧確定は人が担う。

2. FIN-SRV-001：危険でも自動隔離しない

会計締めを担う重要サーバー FIN-SRV-001 で同じ程度のEvidenceがあっても、結果は変わる。

攻撃仮説を支持する根拠は強い。しかし、対象はCritical資産であり、Agentに自動隔離のAuthorityはない。そのため、システムは Human Approval Required と判定し、SOC責任者へ影響確認と承認を求める。

この場面が、Trust Infrastructureの価値を最も端的に示す。Evidenceが強いことは、実行権限を持つことを意味しない。

3. HR-LT-018：証拠不足なら隔離しない

人事部端末 HR-LT-018 では、不審なログインは観測されるが、暗号化挙動や横展開の兆候はない。

この場合、Agentは隔離を実行しない。MFA再認証、追加監視、利用者確認を提案し、Monitor Only とする。

安全な自動化とは、危険なときに動くことだけではない。根拠が不足するときに、動きすぎないことも同じように重要である。

既存のセキュリティ製品と何が違うのか

このデモは、EDR、SIEM、SOARを置き換えるものではない。むしろ、それらが持つ検知、ログ収集、相関分析、プレイブック実行の上に置かれるTrust Layerとして考えている。

既存の製品が「何が起きているかを検知し、どう対応するか」を支援するとすれば、Trust Infrastructureは「この時点で、この主体が、この操作をしてよいのか」を検証可能にする。

これは監査ログを後から保管するだけの話ではない。行動の前に、Evidence、Policy、Authority、Time、Accountabilityを照合することで、実行そのものをガードする設計である。

Decision Traceは、復旧まで続く

インシデント対応は隔離で終わらない。デモでは、検知から復旧までを次の連鎖として記録する。

1. 異常の検知
2. Evidenceの統合と攻撃仮説
3. Policy・Authorityの検証
4. 限定的な隔離の実行、または人へのエスカレーション
5. SOCによるEvidence確認
6. 資格情報リセット、端末再イメージ、再スキャン
7. 復旧承認とネットワーク復帰

それぞれに、誰が関与したか、何を根拠としたか、どのポリシー版が適用されたか、どの操作が実行されたかを記録する。デモでは、前の記録を含むハッシュチェーンも用い、TraceのIntegrityを視覚的に表現している。

こうして初めて、インシデント後に「誰が、何を根拠に、どの権限と条件のもとで判断・行動したのか」を再構成できる。また、成功した封じ込め手順も、業務影響を生んだ判断も、次のポリシーや委任条件の改善に生かせる。

デモを作って見えた課題

今回のデモは、Trust Infrastructureの価値を可視化する第一歩である。同時に、実運用へ進むために解くべき課題も明確になった。

1. Evidenceの信頼度を、誰がどのように決めるのか

デモではEvidence Confidenceを扱えるようにした。しかし現実には、ログの欠損、時刻ずれ、センサーやエージェントの健全性、脅威情報の鮮度、AIモデルの不確実性がある。

次の段階では、Evidenceそのものの来歴・完全性・鮮度・品質を明示し、単一の総合スコアへ安易に圧縮しない設計が必要になる。

2. Authorityを、静的なロールから状況依存の委任へ拡張する必要がある

「一般端末は自動隔離可、重要サーバーは不可」というルールは分かりやすい。しかし実際には、時間帯、進行中の業務、代替環境の有無、顧客影響、担当者の待機状況によって許容できる行動は変わる。

必要なのは、固定的なRBACだけではない。資産の重要度、業務文脈、時間、影響範囲、実行の可逆性を組み合わせる、より細かなDelegation Policyである。

3. 人へのエスカレーションを、単なる停止にしない

Human Approval Required は安全だが、承認者が何を見て、どの選択肢を比較し、どの理由で判断したかが残らなければ、単にボトルネックを人へ移しただけになる。

今後は、AIがEvidenceを要約するだけでなく、隔離・限定隔離・監視継続など複数案の業務影響を提示し、人が判断した理由を軽量に記録できるDecision Workspaceが必要になる。

4. Guarded Executionを、既存の運用基盤とどう接続するか

デモではGuarded Executorを概念的に表現している。実運用では、EDR、IdP、ネットワーク制御、チケット管理、CMDB、資産台帳といった既存製品・既存プロセスへの安全な接続が必要になる。

ここで重要なのは、Agentに広い管理者権限を渡さないことである。承認済みのアクションを、対象・時間・ネットワーク範囲を限定した短期トークンやCapabilityとして実行する方式を検討したい。

5. 例外と復旧の設計を、封じ込め以上に重視する

自動隔離の成否だけでは不十分である。誤検知だった場合の素早い解除、長時間の隔離が必要な場合の延長、証拠保全、再イメージ、資格情報の失効、復旧確認までを一貫して扱わなければならない。

Trust Infrastructureは、止めるための基盤ではない。事業を安全に止めず、必要なときだけ限定的に止め、確実に復旧するための基盤でもある。

6. Decision Traceの共有範囲と機密性

インシデントのTraceには、利用者、端末、ネットワーク、脅威情報、対応手順など機微な情報が含まれる。すべての関係者に同じTraceを見せることはできない。

そのため、Trace自体にもIdentityとAuthorityが必要になる。SOC、情報システム部門、監査、経営、外部のフォレンジック事業者が、それぞれ必要な範囲だけを参照できるようにする。検証可能性と機密性を両立させることが次の課題である。

次のステップ

次の実装では、今回のデモを単なるシナリオ表示から進め、以下を検討したい。

• Evidenceごとの来歴、鮮度、完全性、信頼度を扱うEvidence Contract
• Policy as Codeと、時点を固定したポリシー評価
• 資産・業務影響・可逆性に応じた動的なDelegation Policy
• 承認者が代替案と影響範囲を比較できるDecision Workspace
• 短期CapabilityによるGuarded Execution
• EDR、SIEM、IdP、CMDB、チケット管理との接続モデル
• 機密性を保ちながら監査・説明に耐えるDecision Traceの共有設計

この方向へ進めば、Trust Infrastructureはセキュリティ運用だけに閉じない。製造の安全停止、調達の自動発注、金融の審査、医療・介護の支援、公共手続など、AIが人や既存システムと協働して判断・実行する領域へ展開できる。

結論──AIに任せるために、任せる条件を実装する

AI Agentの価値は、回答を生成することだけではない。組織の判断と実行に参加し、人だけでは追いつかない速度と規模で仕事を進めることにある。

しかし、そのためには、AIが何を根拠に、誰の権限で、どの条件のもとで行動できるかを、実行前から実装しておかなければならない。

今回のサイバー封じ込めデモは、その考え方を一つの場面で可視化した。

AI is not prediction. It is decision.

Trust Infrastructureは、AIの判断を記録するだけの仕組みではない。AI、人、機器、組織が安全に協働し、検証可能な形で委任を広げるための実装基盤である。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance