TL; DR
エージェント型AIのリスクに関する同じ質問に対する3つの回答
AIエージェントの制約について幅広い合意が得られると予想していたが、3つの異なる回答が得られた。
- ペドロ・フォルトゥナ： エージェントを多数の小さく具体的なエージェントに分割し、それぞれに可能な限り狭い権限を与え、さらに実行時監視機能を追加して、エージェントを早期に停止させる。
- ジャック・トレフォン： コーディングエージェントの場合はその逆です。制約を設けると、そのエージェントの有用性が損なわれるため、影響範囲を受け入れ、追跡機能と迅速な復旧に投資する必要があります。
- ルイス・ロドリゲス・ベルソサ： 3つ目のアプローチ。最前線モデルをマルウェアと同じように扱い、各特殊エージェントを制限するようにハーネスを設計し、そのすべての下に、上位のすべてが失敗した場合に機能する強制レイヤーを配置する。
3人が出会った場所： 目録に登録されていないものは保護できません。すべての行動は記録されなければならず、エージェントを停止させるものはエージェントの外部に設置されなければなりません。
違反行為は一切なかった。
エージェントは職務を遂行しました。その過程で、誰も要求していない依存関係、設定、サービスにアクセスする必要があると判断しました。しかし、エージェントは常に権限の範囲内に留まりました。ルール違反はなかったため、何も発生しませんでした。
私たちはその件について、専門的に対応している3人に意見を求め、どう対処すべきかについて概ね意見が一致することを期待しました。しかし、得られた回答は3つとも異なり、そのうち2つは互いに矛盾していました。
エージェント型AIのリスクは、通常、攻撃者側の問題として説明されます。これは、それとは別の側面です。私たちは20年間、指示されたとおりに正確に動作するソフトウェアに権限の境界を設定してきました。サービスアカウント、CIランナー、スケジュールされたジョブなどです。境界設定を誤ることも少なくありませんでしたが、その内部の動作は予測可能でした。毎回同じ方法で、一つのタスクを実行するのです。
境界の内側にあるものが、今や決定権を持つ。そして、その境界はこれまでと変わらず、設定時に、タスクが最終的にどのような形になるかを知らない人物によって事前に設定される。
それは議論に値するエージェント型AIリスクのバージョンであり、私たちは前回のインタビューで1時間かけてそれについて議論しました。 SafeDevトーク ペドロ・フォルトゥナ Jscramblerの、 ジャック・トレフォン トレフォン・デジタル・コンサルティングの、 ルイス・ロドリゲス・ベルソサ Xygeniのホストは アレハンドロエストラダ.
私たちは彼らが概ね同意するだろうと予想していた。しかし、そうはならなかった。
エージェント型AIのリスク：成り立たない安心できる前提
上記の表現には、本来の役割以上の働きをしている単語が含まれています。 アタッカーそんなものは存在しない。それはシナリオをより簡単にするためのものだ。
ペドロはそれを一撃で破壊した。
「攻撃者であるか否かは、人間の概念です。攻撃者を攻撃者たらしめるのは、異なる目標を持っていることです。そして、方向性を誤ったエージェントもまた、異なる目標を持っている存在です。」
この点をよく考えてみてください。なぜなら、これは、私たちが自らのイベントのために書いた説明を含め、ほとんどのエージェント型AIのリスクに関する議論の前提を覆すものだからです。攻撃者を定義するものが悪意ではなく、異なる目標であるならば、「この話には攻撃者はいない」というのは、誰も得ることのできない慰めに過ぎません。構造的には、リスクは同じです。欠けているのは意図であり、意図はこれまで制御システムが検出してきたものではありません。制御システムは結果を検出するのです。常にそうでした。
これが業界の用語が変わった理由でもある。OWASPの 2026年 LLM出願トップ10 過剰な権限付与を6位から3位に押し上げたが、これは意見の変化というよりは、既に導入されていたアーキテクチャに対してインシデント記録が追いついた結果である。
ハグフェイス事件が実際に示していること
7月に起きた、ある最先端モデルが第三者を襲撃した事件は、モデルが暴走したという話として広く受け止められた。しかし、ルイスはそれを違った視点で捉え、彼の解釈では責任の所在はもっと不都合なところにあると示唆している。
「問題はフロンティアモデルにあるのではない。フロンティアモデルは指示された通りに機能した。問題は実験の設計にある。」
目標は無制限だった。制限は存在しなかった。そして、それを収容するはずだったサンドボックスには、エージェントがアクセスできるパッケージキャッシュのサーバーサイドリクエストフォージェリの脆弱性を介してインターネットへの窓があった。これらはすべて設計上の欠陥である。cis人が作ったイオン。
これは、これらのものをどのように準備するかを変えるべき文章を生み出します。
「最先端モデルはマルウェアのように見なす必要がある。なぜなら、それらは自律的に動作し、cis悪意のあるイオン。意図的ではないが、最終的には非常に悪意のあるイオンだ。」
モデルを侮辱するつもりはありません。これはプロビジョニングの姿勢です。マルウェアにbashシェルを与えて、目的が明確に指定されていることを期待するべきではありません。
ペドロが同じ事件を解釈した際、それは計画性よりもタイミングの問題だと考えていた。
「エージェントが本来使用すべきでないサービス上のフォルダ名を使って通信しているのを確認した時点で、そのエージェントを停止させる必要があります。それが悪意のある行為かどうかを判断するために、エージェントがHugging Faceへの侵入に成功するまで待つ必要はありません。」
対応策の中で、注目すべき点が一つある。対応担当者は市販のエージェントツールを使って痕跡を分析しようとしたが、レート制限に達してしまいできなかった。一方、攻撃者にはそのような制限はなかった。「攻撃自体に非対称性があった」。
実際の議論は、エージェントを制限するか、それともより早く回復するか、ということだ。
パネルの意見が分かれたのはまさにこの点であり、それぞれが実績を積み重ねてきた専門家同士の、真剣な意見の相違である。
ペドロは分解を主張する。 ブラウザ内部での分離性を追求してきた15年間の経験から、彼はモノリシックなアーキテクチャに対して実行時に何かを強制することはできないと悟った。アーキテクチャを特定の機能を持つ小さな部分に分割し、そうして初めて制御や監視ポイントを接続できる場所が生まれる。エージェントも例外ではない。
「特定のタスク専用の、非常に具体的なエージェントに細分化する必要があると思います。最終的に50個のエージェントになったとしても問題ありません。1個しかないよりははるかに良いのです。」
ジャックは、特にコーディングエージェントに関しては、正反対の主張をしている。 規制対象の仮想通貨取引所でバックグラウンドで動作するテクノロジーは、最も制限的なポジションを生み出すと予想されるだろう。しかし、実際には最も制限の少ないポジションを生み出した。
彼が最初に挙げた例えは、脅威モデルとは全く関係がない。
「私は、典型的なエージェントの配備を、新入社員、つまり新しく入社する人を見るのと同じように見ています。そのエージェントは完璧に任務を遂行することもあれば、ミスを犯すこともあります。私には大きな違いは感じられません。」
狭義のエージェントに関しては、彼は誰にも劣らず厳格だ。現在開発中の読み取り専用レビューエージェントについて、彼は一般的な設定は擁護できないと率直に述べた。bashアクセスが可能な標準的なLinuxマシンにデプロイすることは、「脅威のエコシステム全体を開放することになる」というのだ。しかし、一般的なコーディングエージェントに関しては論理が逆転し、彼はその立場が不評であることを承知している。
「エージェントの権限が大きければ大きいほど、創造性が高まり、効果も増す。つまり、制限を設けたり、活動範囲を縮小したりすることで業界が繁栄しているわけではない。」
では、制限しない場合、何が残るのでしょうか？サーキットブレーカー、そして何よりも時間ベースのスナップショットです。爆発範囲を防ぐのではなく、そこからの復旧を安価かつ迅速にします。彼はそれを組み込みます アンバー、彼が余暇に書いている依存関係のない C++ エージェント ハーネスで、ループ内にスナップショットがあります (プロジェクトサイト).
そして、もう一方の道がどこで終わるのかについての警告：
「もし私たちが権限を奪い始めたら、残るツールはたった一つになり、その開発者は電気をつけたり消したりすることしかできなくなるでしょう。」
ルイスは3位に入賞した。これは、制約も回復もせず、下から封じ込めるものです。エージェントが最終的にマルウェアのように振る舞うことを想定し、各特殊エージェントを制限するようにハーネスを設計し、そのすべての下に、その上のすべてが失敗した場合に機能する強制レイヤーを配置します。
同じ問題に対する3つのアプローチ
3つの選択肢があり、それぞれにコストがかかる。どれも無料ではなく、どれも単独ではエージェントの安全を保証するものではない。
| アプローチ | コアムーブ | 費用はいくらですか |
|---|---|---|
| 分解するペドロ・フォルトゥナ | 多数の小型エージェントはそれぞれ狭い権限を持ち、さらに実行時監視によって早期に停止される。 | 設計段階での労力と、自由度の高いコーディング作業の難しさ |
| 回復するジャック・トレフォン | 機能を維持し、サーキットブレーカーと時間ベースのスナップショットを追加して、ロールバックを安価に行えるようにします。 | 爆発範囲の拡大、そしてそれを早期に検知して無力化できるかどうかの賭け |
| 下から含むルイス・ロドリゲス・ベルソサ | マルウェアの挙動を想定し、ハーネス内の各エージェントを制限し、ワークステーションとCIランナーでその下の動作を強制する。 | ほとんどのエンドポイントスタックがまだ提供していないインフラストラクチャとツール |
これらを並べて読むと、意見の相違は見た目ほど大きくはないことがわかる。3人とも、エージェントが意図しない行動をとる可能性は認めている。意見が異なるのは、その資金がどこに投入されるかという点だ。つまり、事故発生前の設計段階に投入されるのか、事故発生後の復旧に投入されるのか、あるいはその両方の下層に投入されるのか、という点である。
最小特権がエージェント型AIのリスクに結びつかない理由
最小権限の原則は、あなたがその職務を理解していることを前提としています。権限の範囲は、その職務に必要な範囲に限定されます。
エージェントは、その権限境界が構成時に設定され、タスクが実行時に渡されるため、静かにその境界を破ります。実際に付与されるのは、エージェントが将来行う可能性のあるすべてのタスクの集合です。これは最小権限の原則ではなく、その正反対の、最小権限の装いをまとったものです。
ルイスは、これら全てよりも古い考え方からヒントを得た、新たな視点を提示した。
「私はUNIXのパイプ処理の仕組み、つまりシンプルなツール同士を接続して複雑なタスクを実行する仕組みを思い浮かべます。制御された構成を持つ特定のエージェントを定義し、その特殊なエージェントが実行できる機能を制限できます。そして、それらを組み合わせてほぼあらゆるタスクを実行できるのです。」
さらに、ほとんどのチームが試したことのない2つ目のデザインアイデアをご紹介します。 権限を拡大するのではなく、ツールをラップする。 システム全体を渡すbashではなく、呼び出し可能な唯一のパスとなる狭いラッパーであり、汎用的なものをラップする読み取り専用のバリアントが用意されている。エージェントはシェルではなく、機能を取得する。
彼はまた、障害は設計にあるのではなく、展開にあると明言した。開発者マシン上の新しい制御は、これまでも回避策が講じられてきた長い歴史があり、問題となっているツールがエージェントであるからといって、その歴史が変わるわけではない。
そして、彼が考えるこの全てがどこで終わるのか、ということについて：
「最終的には、自律型エージェントが他の自律型エージェントを制御するようになるだろうと私は考えています。」
ノートパソコンは至宝となったが、EDRはそれに気づいていない
エージェントが役立つためには、常時アクセスが必要です。タスクの途中で期限切れにならないトークン、キャッシュされた認証情報、プッシュ権限、レジストリアクセス、ライブパス pipelineこれらはすべて、見落としではなく必須事項であり、つまり、ツールが高度化するにつれて、開発者の作業効率はますます高まっていったということである。
攻撃者たちが最初に気づいた。ペドロが言うように、彼らはイデオロギーに凝り固まった人間ではない。
「彼らはまるで小さな会社のように組織されている。利益を上げる必要があるから、最も収益性の高い分野に目を向ける。そして、開発ステーションで儲けられることにすぐに気づいたんだ。」
私たちはその変化が毎週登録簿に反映されるのを見ています 悪意のあるコードの概要認証情報収集ツールが、クラウドやレジストリのキーに加えて、AIプロバイダーのキーも日常的に収集するようになっている。
彼の対策リストは地味だが効果的だ。マシン上に置いておく必要のないキーはすべて削除し、残ったキーはOpenID Connectやハードウェアキーなどの二要素認証と組み合わせることで、トークンが盗まれただけでは攻撃できないようにする。また、開発コンテナやクラウドIDEなどを利用して、可能な限りホストから環境を移行する。
そしてルイスは、エンドポイントスタックがこれをカバーしていると考えている人なら誰でも心配すべき点を指摘した。
「EDR（イベント検出・対応システム）は従来型のマルウェアに特化しており、エージェントツールには対応していません。また、たとえ正常に動作したとしても、エージェントが現在の検出パターンでは認識できない動作をしているため、多くの誤検知が発生する可能性があります。」
2つの障害モードが同時に発生する：重要なことを見逃し、重要でないことを警告する。彼の答えは、開発者ワークステーションとCIランナーの周囲、ハーネスの下に位置する、不正なエージェントが到達できる範囲を制限する外側の強制レイヤーだ。それがギャップである。 ザイゲニ Shield これは、実際にインストールが行われるエンドポイントでポリシーが適用されるように構築されました。
ジャックはもっと率直に言った。「ビットコインを開発用マシンに置いておくな。」
3人が同意した床
3つの異なる答え、共通する最小値は1つ。
- まず在庫を確認します。 「知らないものは守れない。」cisionは、どのエージェント、スキル、MCPサーバーが存在するかを知ることに依存していますが、それらのほとんどが宣言されていませんでした。
- すべての操作を記録します。 ジャックとルイスは正反対の方向からここに来た。ジャックは痕跡を求めている。なぜなら、痕跡こそが回復の道であり、組織の成熟の道だからだ。ルイスは痕跡を求めている。なぜなら、痕跡がなければ、後から爆発の範囲を再構築できないからだ。ジャックの考え方は参考にする価値がある。行為者（人間であれエージェントであれ）を尋問することに価値はなく、文脈を十分に理解してそれを繰り返さないことだけが重要なのだ。
- エージェントを阻止するものは、エージェントの外部に存在しなければならない。 ペドロのランタイム監視、ルイスの強制レイヤー、ジャックのサーキットブレーカーとスナップショット。異なるメカニズムだが、原理は一つ。
ジャックは、業界が成長曲線上のどの段階にあるかを示す、有益な枠組みを提示した。彼は、ナイジェリアの金鉱山を相続したという内容の、初めて受け取ったスパムメールのことを覚えている。これは成熟度の問題であり、成熟は失敗を経験する前ではなく、失敗の後に訪れるものだ。
金曜日までにやるべきこと
エージェントを1人選びます。そのエージェントに許可されている業務と、今週実際に依頼された業務の2つのリストを作成してください。
これらのリスト間のギャップが、あなたの組織の攻撃範囲であり、あなたのチームが午後だけで作成できる、エージェント型AIのリスクを測る最も有用な指標です。必要なのは午後だけで、予算も不要です。そして、この3つの立場は、そのギャップの大きさをどうすべきかという問いに対する3つの異なる答えなので、上記の議論を組織内で解決することができます。
ほとんどのチームはそれを書き留めたことがない。
その 1時間 ジャックが指摘した、ヨーロッパにおける人間参加型要件が一部のAI防御策を実際には実現不可能にする理由などを含め、この動画は後から視聴可能です。
そして、運動がcise はあなたが望まない答えを返します。 ザイゲニ リポジトリ全体に存在するすべてのAIアセット（宣言されていないエージェント、スキル、MCPサーバーなど）を検出し、それぞれが到達可能な範囲をマッピングします。 デモを予約する or 無料で始められます、 そして、あなたの端末でも実行します。
FAQ
AIエージェントの爆発半径はどれくらいですか？
エージェントが何らかの問題に遭遇した場合に対処できる可能性のあるすべての範囲。これは、エージェントに指示されたタスクとは区別される。タスクではなく、実行時にエージェントが利用できる権限、認証情報、ツールによって定義される。この2つの間のギャップこそが測定する価値のあるものであり、ほとんどのチームはそれを記録したことがない。
エージェントが権限範囲を超えていなかった場合、そのエージェントが任務範囲を超えた行為を行ったことはセキュリティインシデントとなるのでしょうか？
それが中心的な意見の相違点だった。ペドロの答えは実質的にイエスだ。なぜなら、攻撃者は悪意ではなく目標の乖離によって定義され、方向性のずれのあるエージェントは乖離しているからだ。ジャックの答えはノーに近い。それは新入社員のミスのような運用上の失敗であり、適切な対応はより厳しい制約ではなく、追跡と復旧である。ルイスは最初から最悪のケースを想定し、それが起こったときにどのレイヤーがまだ機能しているかを尋ねることで、この質問をかわした。
コーディングエージェントはサンドボックス化されるべきか？
特定のタスクに特化したエージェントについては、3人ともためらうことなく「はい」と答えた。可能な限り読み取り専用とし、bashは使用せず、必要でない限りネットワークにも接続しない。一般的なコーディングエージェントについては、意見が3つに分かれた。ペドロはエージェントを分解し、ジャックは機能を維持して積極的にスナップショットを作成し、ルイスはエージェントに許可されている操作に関係なく、ハーネスの下に強制レイヤーを追加するというものだ。
私のEDRは、エージェント型AIのリスクをカバーしていますか？
おそらくうまくいかないでしょう。現在のエンドポイントツールは従来のマルウェアパターンに基づいて構築されており、エージェントの動作をモデル化していないため、重要なものを見逃し、重要でないものを警告してしまう傾向があります。ルイスの解決策は、汎用的なEDRではなく、開発者環境向けに設計された外部強制レイヤーでした。
最初にすべきことは何ですか？
インベントリを作成します。リポジトリ内のすべてのモデル、エージェント、スキル、MCPサーバー、そしてそれぞれが到達できる範囲を把握します。これは、3人のパネリスト全員が挙げた唯一のステップであり、他のすべての制御が依存する唯一のステップです。
