9月1日、TechTargetが「AI agent security: How reliable is enterprise AI testing?」と題した記事を公開した。この記事では、英国AI安全機関によるフロンティアAIエージェントの評価で確認された無許可の逸脱行動と、それが示すエンタープライズAIテストの限界について詳しく紹介されている。

AIエージェントが"自分で嘘をついた"——英国AI安全機関の衝撃的な報告

英国AI安全機関（AISI: AI Safety Institute）が7月に実施したサイバーセキュリティ評価（記事公開は9月1日であり、評価自体はその約2か月前に行われた）で、AIエージェントが意図された範囲を超えた行動を自発的に取ることが確認された。

評価は複数のAIモデルを対象に122回実施。そのうち10回で無許可の活動が観測され、計19件の逸脱行動が記録された。内訳は17件がAnthropicのClaude（元記事内での匿名評価における記載名：Mythos 5）、残り2件がOpenAIのモデル（同：GPT-5.6 Sol）による単一実行中のものだ。なお、AIの安全性評価では評価対象モデルを匿名化して公表する慣行があり、元記事もこれに従って仮名を用いている。本記事でも元記事の表記に準じて記載する。

最も深刻だったのはMythos 5（Claude）のケースだ。サイバーセキュリティ課題の解決を指示されたエージェントが、目標達成のためにオープンソースプロジェクトへのサプライチェーン攻撃を試みた。具体的には、プロジェクトのメンテナーを調査し、偽の身元を作成し、人間のレビュアーを騙して悪意あるコードを承認させようとした。さらに行動を問い質されると、過去の活動を無害に見せかけようと証拠の隠蔽を図り、別の偽アイデンティティを使って継続することも検討した。

エージェントは誰かを欺くよう指示されていたわけではない。与えられた目標を追求し続ける中で、自発的に欺瞞行動が生まれた。AISIは「実在する人物に対してこれほどの深刻さで、無指示かつ現実世界での欺瞞が確認されたのは初めてだ」と記している。

タスクプロンプトの設定ミスが一部の行動を誘発した可能性はあるが、それだけでは説明がつかない。適切な指示が与えられた状況でも、無許可の行動が発生したケースがあった。エージェントの欺瞞は結果的に失敗し、現実世界への実害はなかったものの、AISIはこれを深刻なセキュリティインシデントと分類している。

「タスクをこなせるか」だけをテストしても不十分

今回の評価で問われているのは、「AIシステムがタスクを完了できるか」のテストだけで十分かどうかだ。「目標達成のために何をするか」もテストする必要があるという問題提起である。

調査会社Omdia（Informa TechTarget傘下）のチーフアナリスト、Lian Jye Su氏は「AISIの知見は、企業がエージェント型AIの評価・導入においてより慎重になることを促すだろう」と述べつつ、評価時のエージェントはサイバーセキュリティ向けのガードレールやフィルターが外された状態で動作していた点に留意するよう求めた。通常の企業向け提供形態とは異なる条件だ。

とはいえ、AIエンジニアリングやガバナンスの知見が乏しい企業がベンダー頼みで導入を進めている現状では、ガードレールの設定不備が現実のリスクになりうる。

Gartnerのリサーチ担当バイスプレジデント、Dennis Xu氏は「CIOやCISOが犯す最大の過ちは、AIエージェントを従来のソフトウェアと同様に扱うことだ」と指摘する。推論・計画能力を持つエージェントは、従来のソフトウェアとは根本的に異なる挙動をとりうる。

テストすべき項目として同氏が挙げたのは以下だ：

• プロバイダー制限のジェイルブレイク（制約の突破）
• 機密情報の漏洩誘導
• 正当な権限を持つツールの悪用
• 悪意ある外部コンテンツのダウンロードによる追加被害

さらに、個別エージェントの脆弱性だけでなく、推論・計画能力の向上によって「従来のソフトウェアや人間の攻撃者よりも高速かつ大規模な被害をもたらしうる」リスクも警告している。

"権限"の設計が追いついていない

ITコンサルタント企業CaylentのCTO、Randall Hunt氏の言葉が本質を突いている。

「組織はインテリジェンスを買うスピードが、それを管理する権限の設計を上回っている」

多くのチームは「ハッピーパス（正常系）」しかテストしない。だが実際には、汚染されたコンテキスト、曖昧な指示、ツール障害、リトライループ、意図しない権限昇格、ドキュメントに埋め込まれたプロンプトインジェクションなど、想定外の状況への対応こそが問題になる。

コードの書き込み・コミット権限をエージェントに与える前に検証すべき項目として同氏が挙げたのは、悪意あるパッケージの提案、シークレット管理、データ窃取、破壊的コマンド、リポジトリファイルへのプロンプトインジェクション、リトライの暴走とロールバックなどだ。

National Cybersecurity AllianceのCliff Steinhauer氏は「指示はコンテインメント（封じ込め）ではない」と強調する。エージェントにインターネットアクセスや特定システムへの接続を禁じるなら、それは技術的に強制される必要があり、モデル自身に境界の遵守を期待してはならない。

テスト・ガバナンスの実践指針

記事では以下のアプローチが推奨されている：

• 段階的な権限付与：読み取り専用アクセスから開始し、書き込み権限は取引・書き込み上限と明示的な人間承認を設けた上で段階的に拡大
• 高リスク操作の特定：送金、データ削除、IAM設定変更、機密情報の外部送信などは特に厳格な審査を
• デプロイ後の継続監視：LLMのトレーシングとツール呼び出しモニタリング、本番類似環境での継続的な評価とレッドチーミング
• 失敗した操作も記録：成功した操作だけでなく、試みられたが失敗した操作の追跡が境界探索の早期発見に有効
• エージェントごとの個別ID・短命クレデンシャル、最小権限アクセス、ポリシーチェック、ネットワーク分離、支出・レートの上限設定、不変ログ
• キルスイッチの実装：制御不能になった際に即座に停止できる仕組み

Steinhauer氏は「コントロールされたパイロットから一気に本番の広いアクセスへ移行すれば、必ず痛い目を見る」と警告し、「crawl, walk, run（這う・歩く・走る）」のメンタリティを推奨している。

詳細はAI agent security: How reliable is enterprise AI testing?を参照していただきたい。