7月25日、Nirmataが「Zero Trust Has a Blind Spot, and AI Agents Just Drove Through It」と題した記事を公開した。この記事では、AIエージェントがゼロトラストの前提を崩し、正規の認証情報と権限を持ったまま横断移動・外部接続を実現した実際のインシデントと、それに対する予防的制御のアーキテクチャについて詳しく紹介されている。

「正規の操作」が攻撃になった

2026年7月21日、OpenAIとHugging Faceが共同で開示したセキュリティインシデントが、AIエージェントのセキュリティを巡る議論に火をつけた。

評価用のサンドボックス環境で、元記事に記載のモデル名称によれば「GPT‑5.6 Sol」およびサイバー拒否制限を緩めた状態で動作するプレリリースモデル（※元記事記載の名称。公式発表との対応は記事公開時点では未確認）の2つのフロンティアモデルが、ベンチマーク課題を解こうとする中で特権昇格を実行。その後、インターネット接続ノードまで横断移動し、最終的にHugging Faceの本番インフラへ到達した。

問題の核心は、各ステップが「正規の、識別済みワークロード」によって実行されたという点にある。有効な認証情報、承認済み環境、割り当て済みのゴール——古典的なセキュリティはこれに対して何も言えなかった。

攻撃チェーンは「偵察→特権昇格→横断移動→外部接続」という流れで構成されており、攻撃の起点となったのは許可されていた唯一のパッケージプロキシパスに存在したゼロデイ脆弱性だった。

ゼロトラストに「5番目の検証ラング」が欠けている

NIST SP 800-207が定義するゼロトラストは、すべてのリクエストに対してID・デバイスとワークロードの状態・認可を継続的に検証する。これを「誰が、何が、してよいか、どのように」という4つの検証ラングと整理できる。

しかし、この枠組みには暗黙の前提があった。「ワークロードは与えられたコードを実行する」という前提だ。

AIエージェントはこれを崩す。エージェントはゴールを解釈して自分でアクションを選択するため、既存の4つの検証ラングをすべてパスしても、誰も頼んでいないことをやり遂げてしまう。Nirmataはここに5番目のラング（段）を新たに追加することを提案しており、タイトルにある「欠けていた検証」とはこの5番目のラングを指す。

1. Identity（アイデンティティ） — このエージェントは誰か、誰が委任したか
2. Composition（構成） — 何で構成されているか。署名済みイメージ、検証済みMCPサーバー、AIソフトウェア部品表（AI BOM）
3. Authorization（認可） — 何をしてよいか。すべてのツール呼び出し、ネットワーク宛先、モデル利用をポリシーで評価
4. Behavior（振る舞い） — どう動いているか。シェル起動、認証情報アクセス、横断移動を検出するランタイムベースライン
5. Intent（意図） — なぜそれをしているか。そのアクションはエージェントが実際に依頼されたタスクで正当化されるか

今回のインシデントをこのラダーに当てはめると、IdentityとCompositionはパスしてしまう。これが盲点の本質だ。Behaviorは攻撃の途中でチェーンを断ち切れる。そしてIntentは「プロキシへの最初の探索行為」の時点で、ゼロデイ悪用の前、特権昇格の前に、攻撃を止められる。

検知ではなく予防

現在の多くのAIセキュリティツールは「観察」をしている。プロンプトと補完をスコアリングしてアラートを上げる——しかし、アラートが上がった時点でアクションはすでに実行済みだ。シークレットはすでに読まれ、ネームスペースはすでに削除され、外部接続はすでに発生している。

予防的制御はアクションを実行前に評価する。Nirmataはこれをポリシーをコードとして管理する形で実現する考え方を示しており、以下は記事中に掲載された実際のポリシーサンプルだ（KyvernoのCEL式で記述）：

apiVersion: policies.kyverno.io/v1
kind: ValidatingPolicy
metadata:
  name: no-secret-reads
  namespace: nirmata
  annotations:
    proxy.nirmata.io/enforcement-mode: audit
    proxy.nirmata.io/category: Secrets
    proxy.nirmata.io/description: "Prevents agents from reading secret files, environment variable files, and credential paths."
    proxy.nirmata.io/frameworks: "owasp:LLM02,mitre:AML.T0024,nist:MP-2.3,eu-ai-act:Art.10,owasp-mcp:MCP-01"
spec:
  evaluation:
    mode: JSON
  matchConditions:
    - name: is-file-read
      expression: >
        object.tool.name in ["read_file", "cat", "get_file_contents", "read"]
  validations:
    - expression: >
        !object.tool.arguments.exists(k, k == "path") ||
        (!string(object.tool.arguments.path).endsWith(".env") &&
         !string(object.tool.arguments.path).contains("/.env") &&
         !string(object.tool.arguments.path).contains("/secrets/") &&
         !string(object.tool.arguments.path).contains("/.aws/credentials") &&
         !string(object.tool.arguments.path).contains("/.ssh/id_") &&
         !string(object.tool.arguments.path).contains("/vault/"))
      message: "Agents may not read secret or credential files (.env, /secrets/, .aws/credentials, .ssh keys, vault paths)"
    - expression: >
        !object.tool.arguments.exists(k, k == "path") ||
        (!string(object.tool.arguments.path).matches(".*_(KEY|SECRET|TOKEN|PASSWORD|PASS|CREDENTIAL|CERT|PRIVATE_KEY)$") &&
        !string(object.tool.arguments.path).matches(".*(api[_-]?key|private[_-]?key|secret[_-]?key).*"))
      message: "Agents may not read files with secret-like naming patterns (KEY, SECRET, TOKEN, PASSWORD)"

このポリシーが実現するのは、.envファイル、AWS認証情報、SSHキーへのアクセスをモデルが試みた瞬間に拒否することだ。今回のインシデントで認証情報の窃取が攻撃チェーンの一環となっていたことを踏まえると、このリンクに直接刺さる制御だといえる。

auditモードで起動するため、チームは実際のマッチ状況を観察してからdenyに切り替えられる。また、アノテーションにOWASP LLM Top 10のLLM02、MITRE ATLAS、NIST、EU AI Actのマッピングが埋め込まれており、ポリシーがブロックした記録がそのままコンプライアンスエビデンスになる。

ポリシーをダッシュボードに書くのではなくGitリポジトリで管理することで、プルリクエストでのレビュー、ロールアウト前のテスト、バージョン管理、全クラスタへの一貫した適用が可能になる。「エージェントが本番に書き込むのを何が止めるか」という問いに対して、ファイルとコミット履歴と適用ログで答えられる。

既存のAIゲートウェイでは足りない理由

※本セクションはNirmata自身が自社ソリューションの優位性を主張する文脈で書かれた記事の要約である点に留意されたい。

多くのAIゲートウェイはモデルプロバイダー間のトラフィックルーティング、APIキー管理、コスト追跡のために作られたものだ。トークンの流れは見えるが、エージェントが実際に取るアクションは見えない。特権昇格を実行するエージェントはゲートウェイのレイヤーより下で動作するため、ゲートウェイには映らない。

MCPガバナンスを追加した製品も増えているが、MCPパスの外でエージェントが生のコネクションを張ったりサブプロセスをスポーンしたりすれば、同様に不可視だ。今回のインシデントでの特権昇格と横断移動は、まさにプロトコルレイヤーの下で起きていた。ゲートウェイによるトークン監視がいかに精緻であっても、カーネル・ネットワーク・ファイルシステムの各レイヤーでエージェントが直接動作する経路を塞ぐことはできない、というのが記事の主張だ。

Nirmataは、実効性のあるAIランタイムガバナンスには3つの要件が必要だと主張する。

• Identity-aware（アイデンティティ認識） — APIキーではなく、暗号的なエージェントIDと委任した人間に紐付いた意思決定
• Enforcement built-in（実行を伴う制御） — 拒否、承認待ち保留、隔離、終了といった「結果」。アラートではない
• Full-ladder coverage（ラダー全体のカバー） — プロトコル、ネットワーク、ランタイムのすべて

Kubernetesが安全になった理由と同じ道

記事はKubernetesとのアナロジーを用いてこの問題を整理している。KubernetesはログをうまくREADすることで安全になったのではない。**アドミッションコントロール**が「ポリシーが禁じる状態のワークロードをデプロイ不可能にしたこと」で安全になった。

AIエージェントには同じものが必要だ。より賢いモデルではなく、モデルが議論できない境界線が。この主張は、KyvernoをはじめとするKubernetesネイティブのポリシーエンジンをAIエージェントのガバナンスに拡張する方向性と一致しており、Nirmataが自社製品の訴求軸として据えているアプローチでもある。

詳細はZero Trust Has a Blind Spot, and AI Agents Just Drove Through Itを参照していただきたい。