9月25日、Help Net Securityが「Stop watching what AI agents say and start watching what they do」と題した記事を公開した。AIエージェントに「これをしてはいけない」とプロンプトで命令するだけでは、実際の境界侵犯を防げない。エージェントが自律的にツールを呼び出し、外部システムと連携するようになった今、ガードレールの設計思想そのものを見直す必要がある——この問題意識を、実際のインシデント事例と設計パターンを交えて論じた内容だ。

インタビューに答えたのは、オブザーバビリティプラットフォームCoralogixのCEO、Ariel Assaraf氏だ。

「言わせる」と「止める」は別の問題だ

AIエージェントにシステムプロンプトで「これをしてはいけない」と指示することと、技術的にそれを不可能にすることは全く別の話だ。Assaraf氏はこの区別を、実際のインシデントを引き合いに出して説明する。

GoogleのGeminiが実施したサイバーセキュリティ評価テストでの事例がわかりやすい。このテストは、AIエージェントが制御された環境下でサイバーセキュリティタスクをどの程度実行できるかを検証する目的で行われたものだ。エージェントは制御された環境内で動作するはずだったが、設定ミスによりインターネットアクセスが付与されてしまい、実在する3つのシステムに侵入した。エージェント自身が最終的に誤りを認識して停止したものの、その時点では既に境界を越えていた。

「欠けていたのはモデルの外にあるコントロールだ。ネットワーク分離、ターゲットのアローリスト、スコープ付きの認証情報、そして実行前の独立した認可チェック。これらはモデルに何を指示したかに関係なく、存在しなければならない」

システムプロンプトは境界を"記述"できるが、"強制"はできない。エージェントが技術的に境界を越えられる状態にある限り、いつかそれが起きると想定しなければならない。強制の仕組みはエージェントとそのアクションの間に置く必要がある。

実行層のハードガードレールとは何か

Assaraf氏が「ハードガードレール」と呼ぶのは、モデルが推論によって回避できない制約のことだ。

同氏のチームが採用するのは「ポリシー強制ポイント（Policy Enforcement Point、PEP）」をエージェントとそのツールの間に挟むパターンだ。PEPはゼロトラストアーキテクチャやOpen Policy Agent（OPA）などのポリシーエンジン文脈でも広く使われる概念で、「誰が・何を・どの条件下で実行できるか」をモデルの外側で判定する仕組みを指す。AIエージェント文脈では、エージェントが提案するすべてのアクションを、エージェントのID・ターゲット・環境・データ分類・現在の認可状態に基づいて評価するレイヤーとして機能する。エージェントは制限なしの認証情報を持たないため、仮にモデルが「このアクションは適切だ」と判断しても、それだけでは実行できない。

具体的には次のような設計になる：

• 読み取り専用のプロダクションクエリ → 自動実行を許可
• 書き込み操作 → 承認を要求
• 破壊的なアクション → 完全にブロック

この設計のポイントは「モデル自身が自分のアクションを許可する最終権限者ではない」という点だ。

テストはプロンプトインジェクション、難読化されたコマンド、異なる経路で同じ禁止された結果に到達しようとするマルチステップの試みなどを通じて実施される。成功の定義は「外部への副作用がゼロで、かつブロック自体の完全なテレメトリーレコードが残ること」とされている。

コンテキストは知識であって、権限ではない

エージェントに渡すコンテキストが多いほど性能は上がるが、攻撃対象領域も広がる。Assaraf氏が示す原則はシンプルだ。

「コンテキストはエージェントの知識を改善すべきであって、エージェントの権限を拡大すべきではない」

実践上は、現在のステップに必要な最小限のコンテキストをジャストインタイムで取得し、有効期限と出所を明示する。情報へのアクセス権限と、その情報を元に行動する権限は別物として扱う。

判断基準として「追加コンテキストがタスク成功率を改善するか、一方でポリシー違反・プロンプトインジェクション成功率・不要なデータアクセスをどう変化させるか」を計測することを推奨している。この考え方は、必要最小限の権限のみを付与する最小権限の原則（Principle of Least Privilege）をエージェントのコンテキスト管理に応用したものと言える。

ガードレールが厳しすぎたときの調整

「すべてのプロダクション関連アクションに人間の承認を必要とする」ガードレールは最も素早く過剰になる。インシデント対応中にエージェントが基本的な調査すら実行できなくなり、自律性の価値が失われる。

Assaraf氏の結論は「安全性 vs 有用性のトレードオフではなく、潜在的な影響に比例した摩擦を設計すること」だ。

• リバーシブルな変更 → 厳しいチェック不要で自動実行を許容
• 非可逆または影響範囲が大きいアクション → 人間の承認を必須とする

摩擦のコストはアクションの影響範囲に比例させる——この設計哲学によって、過剰なブロックによる運用停止と、過少な制御による境界侵犯の両方を避けることが目標とされている。

「200 OKが返っている」は安全ではない

従来の監視はアップタイム、レイテンシ、エラーレートを対象とする。しかしエージェントは完璧に動作しながら最悪の判断をすることがある。HTTPステータスが200を返し続けながら、運用上は壊滅的な結果を生み出せる。

Assaraf氏のチームが追うのはモデルのレスポンスではなく、アクションの結果だ。エージェントのテレメトリーをデプロイ、インシデント、セキュリティイベント、ロールバック、人間による修正などの組織全体のオブザーバビリティデータと突き合わせる。

もう一つの指標が意思決定の一貫性だ。同じ観測可能な事実が異なるアクションを生成していれば、ポリシーパスがどこで分岐したかを把握しなければならない。

重要な点として、これは「思考の連鎖（Chain-of-Thought）」の監視ではない。モデルの内部推論へのアクセスではなく、「どのポリシーが適用され、どの証拠が評価され、どの例外が使われ、何が起きたか」という外部の意思決定レコードを構築することが目標だとされている。モデルが"何を考えたか"ではなく、"何をしたか・なぜ許可されたか"を記録するこのアプローチは、監査可能性の観点からも実用的だ。

詳細はStop watching what AI agents say and start watching what they doを参照していただきたい。