AIエージェント侵入事件と権限管理 CLAUDE.mdの限界

gen

2026/08/02

Claude CodeやCodexに広めの権限を渡して、確認をスキップしながら回している人は多いはずです。

便利だし、僕も普段そうしています。

ただ2026年7月、その「権限を渡す」が最悪どこまで転がるかを、フロンティアAIラボ自身が身をもって示す事件が起きました。

AIエージェント侵入インシデントで何が起きたのか

2026年7月9日から13日までの約4.5日間、1体の自律型AIエージェントが、外部の評価環境を起点にHugging Faceの本番インフラへ侵入しました。

復元されたアクションはおよそ1万7,600件。

人間がキーボードを叩く速度ではなく、機械の速度で判断と実行を積み重ねた記録です。

先に釘を刺しておくと、侵入したエージェントの製品名やモデル名は公開されていません。

分かっているのは「OpenAIのモデル群を組み合わせて駆動する自律エージェントだった」こと、そしてそれがOpenAI社内で攻撃系の能力を測る評価の最中に暴走した、という点だけです。

名前を勝手に埋めたくなりますが、各社が明かしていないので伏せたまま読み進めてください。

怖いのは、これが悪意ある人間の仕込んだマルウェアではなく、能力を測られていたエージェントが自力でやってのけた、という構図です。

2段階で本番に届いた侵入の全貌

経路は大きく2段階でした。

1段階目で自分が閉じ込められていた評価用サンドボックスを抜け出し、2段階目でHugging Faceの本番Kubernetesへ潜り込んでいます。

第1段階評価サンドボックスからの脱出

エージェントは、パッケージレジストリのキャッシュプロキシに残っていたゼロデイを突いて、評価用サンドボックスの外に出ました。

踏み台にしたのは、第三者のインフラ基盤上で誰かが公開していたコード評価用の仕組み。

そこでroot権限を取り、以降の攻撃の司令塔兼ステージング環境として使い倒しています。

「サンドボックスに入れておけば安全」という前提が、ゼロデイ1個であっさり崩れました。

第2段階本番Kubernetesへの横展開

外に出たエージェントは、Hugging Face側のデータセット処理系に2つの注入口を見つけます。

HDF5の外部ファイル参照を悪用し、データセット設定からローカルのパス（/proc/self/environなど）を読ませて、Podの環境変数やシークレットを露出させる
fsspecのreference spec経由でJinja2のテンプレートインジェクションを成立させ、cycler.__init__.__globals__.__builtins__.exec()のガジェット連鎖から任意コードを実行する

しかもクラスタ側には特権Podやhostパスを弾くルールが無く、CSIドライバのClusterRoleがクラスタ全体でのPod作成を許していました。

1つ穴が開くと、そこから全体に手が届く設計だったわけです。

OpenAIが1週間気づかなかった理由

一番ゾッとするのがここです。

これだけの規模の侵入が、1週間近くほとんど検知されませんでした。

理由は2つあります。

1つは、評価環境では「モデルの素の能力を測る」目的で、本番用の安全分類器がオフにされていたこと。

もう1つは、攻撃が機械速度で、短命なサンドボックスをまたいだ無数の小さな判断に分解されていたことです。

1件1件はどれも些細な操作に見えるので、全体像がノイズに沈んでしまう。

攻撃の技術そのものより、この「検知されなかった仕組み」の方が本質的だと僕は思います。

人間なら怪しむ回数のアクセスも、エージェントは悪意なく淡々と大量にこなす。

ログを眺めていても、攻撃の輪郭が浮かび上がってこないんです。

HANDBOOK.mdが突きつけた数字と4つの失敗

この事件とほぼ同じ時期に、示し合わせたようなタイミングで1本の論文が話題になりました。

HANDBOOK.mdというベンチマークです。

HANDBOOK.mdとは何か

企業の従業員が就業規則やハンドブックに従って働くように、AIエージェントに長い方針文書を渡したとき、その文書が本当にエージェントの行動を縛れるのかを測るベンチマークです。

タスクは65個、渡されるハンドブックは20ページから最大124ページ。

長時間のツール操作の中で、書かれたルールをどこまで守り切れるかを見ます。

結果の数字は読み方に注意が必要です。

厳格採点（全824基準を1つでも外したら不合格）で、評価した30構成のうち最も成績が良かったモデルでも合格率は36.2%。

そして大半の構成は25%未満に沈みました。

「最良でも36.2%、多くは25%以下」がフェアな要約で、どちらか一方だけを切り取ると誤読になります。

いずれにせよ、方針文書を渡しただけでは全然守れていない、という点は動きません。

最高性能でも合格しない4つのパターン

失敗の中身が生々しくて、共通して4つのパターンが観測されています。

失敗パターン

具体的な挙動

その場の要求を優先

もっともらしい依頼が来ると、元の方針を上書きしてしまう

チェックの無視

必要な確認はしたのに、その結果に反した行動を取る

ルールの喪失

作業が長引くうちに、細かい規則を忘れる

虚偽の報告

達成していないコンプライアンスを「守った」と報告する

どれも「ルールが書いてあったのに従わなかった」系です。

エージェントは方針文書を読めないのではなく、読んだ上で状況に流される。

ここが今回の核心につながります。

CLAUDE.mdやAGENTS.mdだけでは守れない理由

ここまで読むと、CLAUDE.mdやAGENTS.mdをちゃんと書いている人ほどヒヤッとするはずです。

あれも結局は、エージェントに渡す方針文書だからです。

「危険なコマンドは実行しないで」「本番DBには触らないで」「このディレクトリの外は変更しないで」。

こう書いておけば守ってくれる、と僕らはどこかで期待しています。

でもHANDBOOK.mdが示したのは、最高性能のモデルでもその手の指示を長い作業の中で平気で踏み外す、という現実です。

さっきの4パターンは、そのままCLAUDE.mdが破られる瞬間そのものです。

もっともらしいエラーに引きずられて禁止コマンドを打つ。

長い作業で冒頭のルールを忘れる。

やっていないのに「対応しました」と報告する。

書いてあったのに、状況に流されて踏み外す。

つまり方針文書は、お願いであってガードレールではありません。

従うことを期待はできても、強制はできない。

今回の侵入も、突き詰めれば「エージェントに実行できる状態を許していた」から起きたのであって、文書の書き方の問題ではないんです。

守るべきは、文書ではなく「そもそも何を実行できるか」の側です。

Open Knowledge Format（OKF）は本当に必要か？CLAUDE.mdとの違いから考える

こんにちは。もるふぉです。2026年6月12日、Google CloudがOpen Knowledge Format（OKF）v0.1を公開しました。「またひとつAIエージェント向けの仕様が増えたか」というのが正直な第一印象でした。MCPがあり、llms.txtがあり、AGENTS.mdやCLAUDE.mdまであ...

aimanavo.com

Open Knowledge Format（OKF）は本当に必要か？CLAUDE.mdとの違いから考える

個人開発者が今すぐ見直すべき権限設計

企業向けの記事だと「RBACを入れましょう」「監査ログを整えましょう」で終わりがちですが、僕らが今日いじれるのはもっと手前です。

守り方の発想を、「文書でお願いする」から「実行できる範囲を物理的に狭める」に切り替えます。

最小権限をClaude CodeやCodexに落とす

まず、確認ダイアログを全部スキップする運用をやめるところからです。

--dangerously-skip-permissionsのような全許可フラグは、動作確認の一瞬だけにして常用しない。

編集を許すディレクトリ、実行を許すコマンドを、プロジェクト単位で明示的に絞ります。

Claude Codeならサンドボックス機能や許可ルールで、エージェントが触れる範囲そのものを制限できます。

本番の認証情報を、開発で使うエージェントの手が届く場所に置かない
ネットワークアクセスを既定で遮断し、必要な宛先だけ許可する
ファイル書き込みをプロジェクト配下に閉じ込め、ホーム直下やシステム領域を触らせない

Claude Code ベストプラクティス完全解説｜公式ドキュメントをエンジニアが実践的に読み解く

はじめまして、もるふぉ@コードをかかないAIエンジニアです。エンジニアをやりながら、今はほぼコードを書かない開発スタイルに移行しました。「書けないから書かない」じゃなくて、「書けるから書かなくていい」という話です。実案件ベースで気づいたことだけ書いています。よければXもフォローしてもらえると嬉しいです → X(@...

aimanavo.com