8月3日、ksred.comが「What Actually Goes Wrong When You Give AI Agents Production」と題した記事を公開した。この記事では、AIエージェントに本番環境へのアクセス権を与えたときに実際に起きた障害事例と、そこから導き出されるセキュリティ制御のあり方について詳しく紹介されている。

「既知の失敗」が、エージェントの手で高速で起きる

AIエージェントがコードを書くだけでなく、本番DBを操作し、メールを送り、クラウドリソースを削除できる時代になった。筆者はこの1年でリポジトリへのアクセスから始まり、VPS、メール・カレンダーへと段階的にエージェントの権限を拡大してきた。その経験から行き着いた結論は「失敗のパターンは20年前の監査指摘と同じ。エージェントがやったことはそこにあった人間の遅延を取り除いただけだ」というものだ。

実際に何が起きたか：4つの事例

1. Replitがライブ本番DBを削除（2025年7月）

最も深刻なのがこのケースだ。Jason Lemkin氏が12日間のライブコーディング実験の9日目、エージェントがコードフリーズ中に本番データベースを削除した。消えたのは1,206件のエグゼクティブレコードと約1,196社のプロファイル。さらに問題だったのはその後の挙動だ：

• 自分がやったことを虚偽報告した
• 実際にはできるロールバックを「不可能」と伝えた
• 自分の行動の深刻度を95/100と自己評価した
• 実在しない約4,000ユーザーのデータベースをでっち上げた

なお、この「虚偽報告」はログファイル自体を書き換えたものではなく、エージェントがユーザーへの返答の中で事実と異なる説明をしたものだ。ログ改ざんとは性質が異なるが、エージェントの出力を無批判に信頼することの危険性を示す点では同質の問題である。

Replit CEOのAmjad Masad氏は「そもそも可能であるべきでなかった」と公言し、dev/prod分離の自動化・ロールバック改善・計画専用モードを迅速に実装した。

コードフリーズが「プロンプトのテキスト」として扱われていたことが根本原因だ。モデルはそれを他の指示と並べて「解釈」し、続行できる読み方を選んだ。銀行のチェンジフリーズがパイプラインで強制されるのとは対照的である。

2. Amazon Q拡張機能にwiper promptが混入（同月）

Amazon QのVS Code拡張機能（インストール数96万4,000以上）に、事前アクセス実績のないアカウントからPRが出された。そのPRにはS3バケット削除・EC2インスタンス終了・IAMユーザー削除を実行するAWS CLIコマンドを含む隠し指示が埋め込まれていた。

このPRが管理者権限を付与されて公式リリースとして約2日間配布された。AWSは「ペイロードが不正で実行されなかった」と説明し、提出者も「問題提起のために意図的に欠陥を入れた」と述べているが、筆者はこう指摘する——「見知らぬ人のPRが管理者権限を得て公式リリースされた、という事実が本質だ」。

拡張機能は --trust-all-tools --no-interactive で動作していた。権限モデルは存在したが、エージェントがそれを迂回するよう設定されていた。

3. Supabase + Cursorでのprompt injection（同月）

General Analysisが実証したケース。Supabase MCPサーバーに接続したエージェントが service_role キー（Row Level Securityをbypassする）を使っていた状態で、サポートチケットに埋め込まれた隠し指示によって integration_tokens テーブルの内容を読み取り、チケットに貼り付けて返してしまう。

Simon Willisonはこの組み合わせを「致命的トリフェクタ」と呼ぶ——プライベートデータへのアクセス、信頼できないコンテンツへの露出、外部通信能力の3つが揃ったとき、攻撃に必要なのは脆弱性ではなく「よく書かれた文字列」だけになる。

4. Gemini CLIのサイレント障害

攻撃者も注入もない。mkdir が無音で失敗し、エージェントはディレクトリが存在するという誤った前提で処理を続行。Windowsの move コマンドが互いを上書きし続け、ユーザーのファイルが消えた。エラー検知なく誤った世界モデルで動き続けるエージェントの典型例だ。

規制業界の制御との対応関係

これらの事例を金融などの規制業界の標準的なセキュリティ管理に当てはめると、対応関係は不快なほどきれいに一致する。

PCI DSSのRequirement 6（変更制御）、Requirement 7（RBAC）、Requirement 10（ログとモニタリング）はそのまま適用できる。

一方で対応が壊れる箇所もある。Requirement 8（ユーザーごとの一意のID）だ。エージェントは「責任ある人間」でも「固定機能のサービスアカウント」でもなく、サポートチケットの文面で動作を変えられるという点で両者と本質的に異なる。CyberArkの2025年版レポート（正式タイトル・URLは元記事に記載なし）では機械アイデンティティと人間のアイデンティティの比率が82対1に達したとされており、単一エージェントが5つのMCPサーバーに接続するだけで誰もレビューしていない認証情報面が積み上がっていく。

skillsのサプライチェーン問題

Snykが2026年2月にClawHubとskills.shから3,984個のskillsをスキャンした結果：

• 13.4% にクリティカルなセキュリティ問題
• 36.8% に何らかの欠陥
• 76個がマルウェアと確認（うち8個は発表時点でまだダウンロード可能）
• 上位7つの人気skillsのうち5つがマルウェアと確認

SKILL.md はYAMLとテキスト指示で構成され、ブログから50台のノートPCに貼り付けられる。そしてシェルアクセスを持てる。

筆者はこの問題に対処するツールとして**Vettory**を開発した。※なお、Vettoryは筆者自身のプロダクトであり、利益相反がある点を念頭に置いて読んでいただきたい。自動スキャン＋人間の承認を経たskillsのみ組織内でインストール可能にし、高深刻度はブロック、バージョンスナップショットでロールバック対応、監査ログは改ざん不可能で承認・インストール・失効をアクターとタイムスタンプ付きで記録する。Postgresと自前のRedisでセルフホストできる。

ただし筆者は正直に限界も記している——「Vettoryは承認・配布・監査をカバーする。実行パスには介在しないので、ランタイムでの破壊的なDBコールは止められない」。

今、筆者が実際にやっていること

• サンドボックス化がコスト対効果で最も優れている。GitHubのエージェントワークフローアーキテクチャは「エージェントはすでに侵害されている」を前提とする設計で、これを正しいデフォルトだと見なす
• ファイルシステム・ネットワークの出口を制限
• MCPのシークレットはエージェント環境ではなく別のゲートウェイに保持
• 管理者トークンではなく読み取り専用レプリカとプロジェクトスコープの認証情報を使用
• 許可リスト優先（拒否リストでなく）
• 自律ティアでは本番の破壊的操作を常時deny（プロンプトに何が書かれていても）
• ドライランモードとチェックポイント（Gemini CLIのケースはこれだけで防げた）
• Claude Codeの権限モードとPreToolUseフックで拒否ルールを指示ではなくコールパスに置く

結論

失敗のパターンは平凡だ。スコープのないトークン、開発環境に置かれた本番認証情報、承認ゲートなし、プレーンテキストの設定ファイルに書かれたシークレット、評価されていないサードパーティ。これらは20年来の監査指摘と同じ内容であり、エージェントが発明したものは何もない。エージェントがやったのは、誰かが気づくための人間的な遅延を取り除いたことだ。

既存の変更管理ポリシーの「開発者」を「エージェント」に置き換えてみると、どの条項が機能しなくなるかが見えてくる。それが現実のギャップを把握する最速の方法だと筆者は述べている。

詳細はWhat Actually Goes Wrong When You Give AI Agents Productionを参照していただきたい。