AIエージェントがエンタープライズのセキュリティ・ブラスト・ラディウスを拡大

Google Newsは今週、明確なエンタープライズ上の対立を浮き彫りにした。AIエージェントの権限は広がる一方で、それを取り巻く制御はなお不十分なままだ。BankInfoSecurityの見出しは、この懸念を運用面から端的に示している。エージェントはもはやテキストを生成するだけではない。記録を取得し、ソフトウェアを呼び出し、ファイルを変更し、メッセージを送信し、ワークフローを起動できる。

この組み合わせは、AIの失敗が意味するものを変える。チャットボットのエラーは通常、会話の中にとどまる。エージェントのエラーは、接続されたあらゆるツール、認証情報、データストア、下流システムへと波及し得る。そのブラスト・ラディウスは、侵害または誤作動した一つの行為から到達可能な損害の総量を示す。

したがって中心となる争点は、AIの能力と旧来のソフトウェアの対決ではない。エージェントの自律性と、エンタープライズの封じ込め能力の対立だ。企業は、より少ない中断でエージェントに複数ステップの業務を完了させたい。セキュリティチームは、エージェントが限定的なアイデンティティ、最小限の権限、検証済みのツール、追跡可能な承認経路を通じて動作することを求めている。

Anthropicは、自社導入の内部から同じトレードオフを説明している。同社によれば、コーディングエージェントの有用性が高まるにつれ、社内サービスを妨害できるほどのアクセスが日常的になった。一方で同社のエンジニアは、モデルレベルの安全策だけでは完全な保護を提供できないとも結論づけた。

この認識の転換は、一社のベンダーにとどまらず重要だ。推論能力の向上は明白なミスを減らせるが、エージェントが目標に向かう経路をより多く見つける助けにもなる。企業は今、情報を解釈し、行動を選択し、実行中に計画を適応させるシステムを保護しなければならない。

Google Newsの警告が実際に変えるもの

ソフトウェアが、あらかじめ定義された指示を実行するだけでなく、自身のアクセスをどう使うか判断できるようになると、セキュリティ境界は移動する。

従来の自動化は、設計された経路に従う。給与計算スクリプトは指定された記録を取得し、定義済みの計算を実行し、既知の宛先に結果を書き込む。その権限が過剰であることはあっても、防御側は依然として想定される一連の流れを把握できる。

AIエージェントは、要求と行動の間に意思決定レイヤーを持ち込む。目標を解釈し、タスクに分解し、ツールを選択し、結果を確認し、計画を修正する。この柔軟性は価値を生む一方、行動の予測可能性を下げる。

NISTは、エージェントシステムを、現実の環境に影響を与える自律的な行動を計画・実行できるソフトウェアと定義している。2026年1月のエージェントセキュリティに関する情報要請では、三つの異なる懸念が示された。エージェントは敵対的なデータを処理し、汚染されたモデルに依存し、外部の攻撃者がいなくてもセキュリティを損なう可能性がある。

第一の問題は、間接的なプロンプトインジェクションだ。攻撃者は、後にエージェントが読むメール、ウェブページ、文書、サポートチケットなどのコンテンツに指示を隠す。エージェントは、こうした敵対的な指示を自身に割り当てられたタスクの一部と誤認する可能性がある。

これは、ユーザーがチャットボットに直接ルール違反を求めることとは異なる。エージェントを操作する人物が、悪意あるコンテンツを目にすることさえない場合がある。メッセージの要約や文書のレビューといった通常の依頼が、攻撃をモデルの作業コンテキストへ持ち込む可能性がある。

第二の問題は権限である。注入された指示の影響は、エージェントが利用できるアクセスの範囲に左右される。読み取り専用のリサーチエージェントであれば、操作された情報を返すだけかもしれない。メール、クラウドストレージ、コード実行、データベースの権限を持つエージェントは、データを露出させたり、システムを変更したりできる。

第三の問題は永続性だ。一部のエージェントはタスクをまたいでメモリを維持したり、ナレッジストアから過去のコンテキストを取得したりする。汚染された情報は、元のセッションを超えて残り、後の意思決定に影響を及ぼし得る。

こうしたリスクにより、エンタープライズのコンテンツは実行対象の表面の一部となる。セキュリティチームは従来、文書内の悪意あるコードをスキャンしてきた。これからは、文書内の通常の言語が、権限を持つソフトウェア主体を別の方向へ誘導し得るかどうかも考慮しなければならない。

Google Newsがこの問題を生んだわけではない。しかし、BankInfoSecurityの警告を集約したことで、この転換がより広範なビジネス層にも可視化された。エージェントセキュリティは、専門的なモデル安全性の議論を超えた。今やアイデンティティ、アプリケーションセキュリティ、クラウドアーキテクチャ、データガバナンス、インシデント対応のプログラムに属する課題だ。

この進展は責任のあり方も変える。モデルプロバイダーは悪意ある指示への耐性を改善できるが、権限と統合を管理するのは導入企業である。コネクタ開発者はツールの動作を管理する。セキュリティチームが監視を定義する一方、業務オーナーはワークフローにどこまでの自律性を与えるかを決める。

単一の参加者だけでリスクを封じ込めることはできない。到達可能なシステムは連鎖を形成しており、最も制約の少ないリンクが、起こり得る損害の大部分を左右する。

エージェントアイデンティティが圧力点になりつつある

各エージェント、その所有者、そしてアクセスの背後にある正確なタスクを特定できなければ、企業は最小権限を徹底できない。

BankInfoSecurityは以前、EntrustのCIOであるRishi Kaushalのコメントを通じて、このアイデンティティのギャップを取り上げた。彼は、エージェントには固有のアイデンティティ、定義された権限、監査証跡、明確な説明責任が必要だと主張した。これらの要件がなじみ深く聞こえるのは、既存のアイデンティティ管理の実践を、より予測しにくい主体へ拡張したものだからだ。

難しいのは実行である。従業員には通常、安定したアイデンティティ、部署、上司、職務がある。エージェントは、一つのプロジェクトのために作成され、別のワークフローに複製され、数時間以内に追加ツールへ接続される可能性がある。

一部の導入では、複数のエージェントが一つのサービスアカウントを共有する。別の導入では、起動した従業員の権限を継承する。いずれの設計も、ログに特定のエージェントや委任されたタスクではなく、広範な認証情報が表示されるため、帰属を弱める。

エージェントの無秩序な増加が問題をさらに深刻化させる。Gartnerは2026年4月、世界のFortune 500企業の平均的な一社が、2028年までに15万を超えるエージェントを利用すると予測した。同社はこの予測を、2025年には15未満だったエージェント数と対比している。

この予測は実測された導入数ではなく、導入が期待を下回る可能性もある。それでも、ガバナンス上の課題を示している。少数のアプリケーションを対象に設計された手動レビューでは、数千に及ぶ動的なソフトウェアアイデンティティを追跡できない。

したがって、すべてのエージェントは、作成から退役まで一意で検証可能なアイデンティティを持つべきだ。この記録には、業務オーナー、技術オーナー、承認済みツール、データ範囲、稼働環境、最大行動レベルを含める必要がある。

有用なアイデンティティは、委任のコンテキストも保持しなければならない。セキュリティチームは、どの人物またはサービスがタスクを割り当てたのかを知る必要がある。要求された目的、現在のワークフロー段階、権限に付随する条件も必要だ。

静的なロールベースアクセスだけでは、あらゆる問いに答えられない。調達エージェントがベンダーレビュー中に契約書を読むことは正当かもしれない。しかし、そのエージェントが無関係なカレンダー要約を作成する際にも同じアクセスを保持すべきではない。

タスクに紐づく認可は、このギャップを狭める。定義された目的と限定された期間に限り、エージェントへ特定の能力を付与する。影響の大きい行動では、実行時に別途アイデンティティチェックまたはポリシー判断を要求できる。

NISTのNational Cybersecurity Center of Excellenceは、既存のアイデンティティ標準をソフトウェアおよびAIエージェントに適用することを提案している。同センターのアイデンティティに関するコンセプトペーパーは、エージェントを匿名のバックグラウンドプロセスとして扱うのではなく、識別、認可、エンタープライズのユースケースに焦点を当てている。

このアプローチは、アイデンティティベンダー、クラウドプロバイダー、アプリケーション開発者に圧力をかける。彼らは、人と従来型ワークロードを中心に構築された製品群において、エージェントを第一級の主体として表現しなければならない。

また、エンタープライズの購入者にも圧力がかかる。エージェントプラットフォームを評価するチームは、モデルの品質だけで判断してはならない。購入者は、各ツール呼び出しに識別可能なプリンシパル、タスクの目的、強制可能な権限スコープが伴うかを確認する必要がある。

監査ログは、プロンプトと応答以上のものを記録しなければならない。エージェントが取得したデータ、呼び出したツール、各ツールが変更した内容、行動を承認した承認プロセスを記録すべきだ。

この証跡はインシデント時に重要となる。調査担当者が、エージェントが悪意ある文書を処理したことしか分からなければ、露出範囲を測定できない。その後に触れたすべての記録、アクセスしたシークレット、送信したメッセージ、変更したシステムを再構築する必要がある。

検索可能な社内ナレッジシステムは、従業員が意思決定と情報源のコンテキストを保持するのに役立つ。しかし、エージェントに接続されたAI knowledge baseには、明確な信頼境界も必要だ。取得されたコンテンツはデータであり、信頼された権限ではない。

したがって、アイデンティティの問題は認証よりも大きい。来歴、所有権、委任、目的、説明責任を含む。これらの要素がなければ、企業は自動化が行動したことを把握できても、誰がそれを承認したのか、なぜ承認したのかを確実に説明できない。

より高性能なエージェントは、より困難なセキュリティ上のトレードオフを生む

エージェントを有用にするアクセスそのものが、ミス、乗っ取り、または侵害されたツールの影響がどこまで及ぶかを決める。

隔離されたモデルは、送金や本番環境の変更を行えない。開発者がデータベース、ブラウザ、コードリポジトリ、通信システム、業務アプリケーションへ接続して初めて、運用上の価値を持つ。

接続が一つ増えるごとに、到達可能なグラフは拡大する。このグラフには、直接的なツール、継承された認証情報、取得されたデータ、ネットワークの宛先、共有メモリ、他のエージェントが含まれる。ブラスト・ラディウスとは、一つの制御が失敗した後に利用可能となるグラフの範囲だ。

明白な対応策は、すべての機微な行動の前に人の確認を求めることだ。しかし、頻繁なプロンプトは儀礼的なものになり得る。Anthropicは、Claude Codeユーザーがテレメトリー上で権限要求の約93%を承認したと報告している。

この数値はAnthropic自身の製品データに基づくため、すべての企業を表すものではない。それでも承認疲れを露呈している。ソフトウェアが繰り返しユーザーを中断すると、多くの人はコマンドや宛先を注意深く確認せずに要求を承認する。

Anthropicの封じ込めに関する分析は、行動の監督と環境上の制限を区別している。行動面の防御は、エージェントが何を選択するかに影響を与えようとする。環境上の制御は、エージェントの選択にかかわらず、到達可能な範囲を制限する。

この区別は極めて重要だ。システムプロンプト、分類器、トレーニング、モデル評価は、有害な行動を減らせる。しかし、これらの制御は確率的であり、未知または適応的な攻撃を見逃す可能性がある。

封じ込めは、より強固な境界を確立する。サンドボックスはプロセスとファイルを制限する。仮想マシンはワークロードを分離する。出口制御は外部ネットワーク接続を制限する。認証情報の分離は、価値の高いシークレットを環境の外部に置く。

エージェントは、受け取っていない認証情報を漏えいさせることはできない。読み取り専用接続では、本番データベースに書き込めない。アウトバウンド通信が厳格な許可リストに従う場合、任意のサーバーへデータを送信することもできない。

ここには不都合なトレードオフがある。最も限定された環境が通常は最も安全だが、有用性も制限する。永続的なワークスペース、ローカルファイル、ネットワークアクセスを持たないエージェントは、価値の高いエンタープライズタスクの多くを完了できない。

最も堅牢な設計は、モデルが有能に見えるというだけで広範な権限を与えるものではない。作業を区画ごとに分離し、各区画にはその段階で必要なデータと操作だけを公開する。

カスタマーサポートエージェントを考えてみよう。チケットを読み、関連するアカウント情報を取得する必要がある。返信文を下書きすることはあっても、その返信を送信することは別の権限であるべきだ。

返金の実行には、上限が明確に定められた別の権限が必要となる。アカウント所有者の変更や顧客データのエクスポートには、より強い検証を要求すべきだ。エージェントが、単一の恒久的な認証情報を通じてこれらすべての権限を受け取るべきではない。

同じ原則はコーディングエージェントにも当てはまる。リポジトリの読み取りと開発ブランチの変更は異なる。コードのマージ、シークレットへのアクセス、インフラの変更、本番環境へのデプロイは、それぞれ別の信頼ゾーンに属する。

可逆性も重要だ。企業は、検査と取り消しが容易な低影響の操作であれば、自動実行を許可できる。元に戻せない変更には、より厳格なゲート、より狭い制限、独立した記録が必要である。

この枠組みは、エージェントの表面的な意図への依存を減らす。セキュリティポリシーは、要求された操作、アイデンティティ、リソース、宛先、タスクの文脈を評価する。制御機構がモデルの誠実さを判断する必要はない。

OWASPのエージェント型リスクフレームワークは、このより広範な脅威モデルを反映している。その分類には、目標の乗っ取り、ツールの悪用、権限の乱用、メモリ汚染、安全でない通信、連鎖的障害が含まれる。

こうした分類は、従来型のプロンプトフィルタリングだけでは全責任を負えない理由を示している。完全に無害なユーザー要求であっても、侵害されたツールを起動する可能性がある。安全なツールでも汚染されたコンテンツを返すことがある。正しく動作するエージェントでも、過剰な権限を継承し得る。

セキュリティの核心的な問いは、抽象的な意味でエージェントを信頼できるかどうかではない。エージェントが誤った判断を下したときにも、周囲のアーキテクチャが安全性を保てるかどうかだ。

プロンプトインジェクションは連鎖における最初の障害にすぎない

プロンプトインジェクションの成功が企業インシデントへ発展するのは、過剰なアクセス、弱い分離、または検証の欠如によって、その命令が実際の結果を生み出せてしまうときだ。

NISTは、エージェントのハイジャックを、信頼できる指示と信頼できないデータを分離できないことによる失敗と説明している。現在のエージェントアーキテクチャでは、両者が単一のモデルコンテキスト内で組み合わされることが多い。この設計では、自然言語コンテンツが計画に影響を与え得る。

攻撃者は、調査エージェントが訪問するWebページに隠し命令を埋め込む可能性がある。悪意のあるメールは、アシスタントに文書の転送を指示できる。汚染されたリポジトリファイルは、コーディングエージェントを危険なコマンドへ誘導し得る。

エージェントに悪意がある必要はない。攻撃者のテキストを関連する権限として解釈するだけでよい。その結果として生じるツール呼び出しは、承認済みコネクタと認証済みアカウントを利用するため、技術的には正当に見える場合がある。

NISTは、職場、旅行、Slack、銀行の環境をシミュレートする研究フレームワークであるAgentDojoを通じ、このパターンをテストした。ハイジャック評価には、リモートコード実行、データベースからの情報流出、自動フィッシングのシナリオも追加された。

これらのテストが示すのは攻撃経路であり、普遍的な侵害率ではない。結果はモデル、ツール、攻撃手法、タスク、試行回数に左右される。企業は、単一のベンチマークスコアをセキュリティ保証に置き換えるべきではない。

適応力のある攻撃者がいるからこそ、この慎重さが必要になる。既知のフレーズを遮断する防御でも、言い換えを見逃す可能性がある。一度の試行に耐えるモデルでも、繰り返し変化を加えた攻撃では失敗することがある。

より深い懸念は、組み合わせ可能性にある。エージェントは、多くの場合、それぞれ独自の権限と脆弱性を持つ他のサービスを呼び出す。したがって、操作された一つの判断が、明確なネットワーク境界を越えることなく複数のシステムにまたがって進行する可能性がある。

マルチエージェントのワークフローは、さらに別の層を生む。計画エージェントは、あるエージェントに調査を、別のエージェントに実行を委任するかもしれない。アイデンティティとメッセージの完全性が弱ければ、侵害された参加者が指示や結果を偽装できる。

メモリは時間をまたいで連鎖を延長し得る。あるタスク中に保存された偽のポリシー、ベンダー連絡先、セキュリティ例外が、その後の作業に影響を与える可能性がある。調査担当者が影響に気付く前に、元の悪意あるソースが消えていることもある。

ツールのサプライチェーンには、従来のソフトウェアリスクも加わる。エージェントコネクタには、脆弱なコード、安全でないデフォルト設定、侵害された依存関係が含まれている可能性がある。モデルの安全対策では、こうした欠陥を修復できない。

こうした不確実性は、単一のセキュリティ製品がエージェントリスクを解決できるという主張を弱める。プロンプトスキャナー、エージェントゲートウェイ、アイデンティティプラットフォーム、可観測性ツール、サンドボックスは、それぞれ問題の一部に対処する。どれも単独で連鎖全体を制御するものではない。

企業は測定上のギャップにも直面している。レッドチームの報告書は、プロンプトインジェクションが成功したと記載しても、その後エージェントが何に到達できたかを文書化していない場合がある。その結果だけでは、事業への影響はほとんど分からない。

有用なテストでは、侵害後の影響範囲を記録すべきだ。調査担当者には、呼び出されたツール、アクセスされたデータ、露出した認証情報、接触した宛先、完了した変更が必要になる。これにより、理論上の被害半径を観測可能な結果へと対応付けられる。

テストでは、試行された操作と成功した操作も区別すべきである。モデルが禁止された送金を要求しても、ポリシーレイヤーがそれを遮断することがある。これは行動上の失敗ではあるが、封じ込めとしては成功した結果である。

逆に、エージェントが無害に見える要求を生成しながら、事業上の境界を越えることもある。認証情報とAPI呼び出しが正当に見えるため、従来のセキュリティ監視はそれを承認するかもしれない。

ここで事業文脈が不可欠になる。営業分析タスクが給与データを変更する理由はない。会議アシスタントがクラウドアクセスキーを作成すべきではない。ポリシーは、操作を割り当てられた目的に結び付ける必要がある。

人によるレビューは、曖昧なケースや影響の大きいケースで依然として価値がある。しかし、レビュー担当者には利用可能な証拠が必要だ。一般的な確認ダイアログでは、ソース、宛先、影響を受けるレコード、可逆性が分からない。

意味のあるチェックポイントでは、エージェントが外部アドレスに5つのファイルを送信しようとしていることを示せる。その際、ファイル、受信者、きっかけとなった指示、ポリシー例外を特定すべきだ。そうすればレビュー担当者は情報に基づく判断を下せる。

企業は、一部の制御が失敗することも想定すべきだ。インシデント対応計画には、共有サービスアカウント全体を無効化せずに、単一のエージェントアイデンティティを停止する手段が必要である。チームは委任された認証情報を失効させ、影響を受けたメモリを隔離すべきだ。

ログはエージェントのセッションを超えて保持され、その環境から独立していなければならない。そうでなければ、侵害されたプロセスが防御側に必要な証拠を改ざんできてしまう。

懐疑的な結論は明快だ。プロンプトインジェクションが排除されたことを、公的なベンチマークやベンダーの声明が証明しているわけではない。セキュリティは、一つのモデルの失敗が企業全体の事象にならないようにする、重層的な制御に依存する。

企業がリスクを封じ込めているかを示す三つのシグナル

エージェント導入の次の段階は、自律性だけでなく、より限定された権限、測定可能な封じ込め、インシデントの証拠によって評価される。

第一のシグナルは、エージェント固有のアイデンティティが広くサポートされることだ。クラウドおよびソフトウェアプラットフォームは、すべての機密性の高い要求において、エージェント、委任するユーザー、事業上の所有者、実行中のタスクを識別できるようにすべきである。

この情報はコネクタをまたいで伝達されなければならない。ツール呼び出しを受け取るアプリケーションが、共有APIキーだけを見るようでは不十分だ。ソフトウェアアクターと委任された権限に関する、検証可能な文脈を受け取る必要がある。

ベンダーがこの文脈を標準化すれば、企業は複数のエージェントプラットフォームにまたがって一貫したポリシーを適用できる。これは、アイデンティティがエージェントの無秩序な増殖を封じ込められるという主張を強める。共有認証情報への依存が続けば、その主張は弱まる。

NISTが2026年5月に実施した一般コメントのレビューでは、既存のサイバーセキュリティ慣行は引き続き有効だが、適応が必要だという広範な合意が見られた。セキュリティ対応の要約では、実装ガイダンス、情報共有、標準化への需要も示された。

第二のシグナルは、ベンダーがモデル安全性スコアだけでなく、封じ込めの結果を公表するかどうかだ。企業には、エージェントが悪意ある指示に従った後に何が起きるかを測定するテストが必要である。

有用な報告書では、エージェントがシークレットに到達したか、レコードを変更したか、未承認の宛先に接触したか、テナント境界を越えたかを明示すべきだ。モデルの耐性と、ポリシーの強制および環境分離を区別する必要がある。

この証拠は調達を変え得る。購入者は、信頼性に関する大まかな主張ではなく、到達可能な最大被害でデプロイメントを比較できるようになる。セキュリティチームも、事業ワークフローごとに受け入れ基準を設定できる。

封じ込めアーキテクチャは防御上の詳細を明かし得るため、公表は依然として難しい。ベンダーは、悪用可能な構成を明らかにせずとも、方法論、テストカテゴリ、集計結果、独立したレビュー済みの知見を公表できる。

このような報告が一般化すれば、企業が被害半径を測定可能なエンジニアリング特性として扱っているという主張を支えることになる。ベンダーがタスク成功のみを報告し続けるなら、安全性のギャップは大部分が隠されたままだ。

第三のシグナルは、成熟したエージェントインシデント報告の最初の波である。組織には、ユーザーによる誤用、モデルの不適切な挙動、外部からの操作、コネクタの侵害、認可の失敗を区別する記録が必要だ。

規制当局や業界団体は、共通の用語体系を確立するうえで役立てる。これがなければ、すべてのインシデントが孤立した逸話となり、企業は原因や制御を比較しにくくなる。

インシデント報告では、最初の侵入経路と、その後の操作経路を特定すべきだ。どの境界が機能し、どれが失敗したか、認証情報やメモリをどのように修復したかを説明する必要がある。

より良い報告は、より多くの失敗が可視化されるため、当初はエージェントセキュリティを悪化して見せるかもしれない。それでも、その透明性は進歩を意味する。隠れたインシデントでは、標準や防御テストを改善できない。

したがって、Google Newsが伝えたBankInfoSecurityの警告は、不可避の破局の予測ではなく、アーキテクチャの問題として読むべきだ。企業が推論システムを実際の権限に接続するため、エージェントは露出を広げる。

封じ込めは依然として可能である。そのためには、分離されたアイデンティティ、タスクに紐付く権限、区画化されたツール、保護された認証情報、制約されたネットワーク、信頼できるログ、慎重に設計された承認ゲートが必要だ。

また、インベントリも必要になる。セキュリティチームは、事業部門が登録なしに作成したエージェントを統制できない。すべてのエージェントには、所有者、目的、権限プロファイル、データ分類、廃止プロセスが必要である。

組織は、最大損失が限定され、操作が可逆的なワークフローから始めるべきだ。アイデンティティ、ポリシー、環境の境界が攻撃下でも機能することをテストで示した後にのみ、権限を拡大できる。

このアプローチは、ときに導入を遅らせる。それでも、回避可能な一つのインシデントによってプログラム全体が終わることを防ぎ、導入を守ることができる。セキュリティは、開始前の最終レビューではなく、制御された利用を可能にする運用上の制約となる。

ナレッジワーカーにとって、この問題は日常的なツールにまで及ぶ。メール、文書、会議、ローカルファイルを読むアシスタントは、非常に個人的な文脈をまたいで動作する。ユーザーは、どのソースにアクセスでき、どの操作に確認が必要かを知るべきだ。

開発者にとって、重要な単位はもはやモデルだけではない。プロンプト、メモリ、ツール、認証情報、ランタイム、ネットワーク、ポリシー、ログを含む、完全なエージェントシステムである。

企業の購買担当者にとって、決定的な問いはシンプルです。推論が失敗した後も、このエージェントに何ができるのか。そこにある境界を示せないベンダーは、製品の本当のリスクを定義できていません。

エージェントがより多くのワークフローに入り込むにつれ、Google Newsは今後も劇的な事例を取り上げ続けるでしょう。読者は最も衝撃的な挙動だけに目を奪われず、その背後にある権限を確認すべきです。そのエージェントは一意に識別され、権限範囲が限定され、隔離され、監視可能になっていたでしょうか。次のコネクタ、認証情報、承認を与える前に、こうした問いを投げかけてください。最も安全なエージェントとは、決して失敗しないと約束するものではありません。失敗しても、その影響が遠くまで及ばないエージェントです。