エージェント型AIがセキュリティにおける「人間を信頼する」前提を崩している

エージェント型AIがGoogle Newsで大きく取り上げられた。その背景には、自律システムが、それを抑制するために設計された人間中心の統制よりも速く行動できるようになったという深刻な衝突がある。

最近のForbesの分析は、セキュリティプログラムが依然として、人が重要な操作を開始し、その責任を負うことを前提としていると論じる。AIエージェントはその両方の前提を揺るがす。限られた人間の関与で、ツールを選択し、データを取得し、APIを呼び出し、複数段階のタスクを完了できるからだ。

この記事は、単発の侵害や製品発表ではなく、より広範なセキュリティ論争を反映している。Microsoft、Google Cloud、セキュリティ標準化団体は、エージェントを独立したデジタル主体として扱うための統制を開発している。その取り組みは、人間のユーザー、予測可能なアプリケーション、比較的安定した権限を前提にした従来モデルに挑戦するものだ。

この緊張関係が重要なのは、エージェントが悪意を持たなくても被害を生み得るためである。侵害された指示、過剰な権限、汚染されたメモリ、あるいは誤った計画により、正当な操作が有害な連鎖へとつながる可能性がある。

したがって中心的な対立は、自律性と人間中心の統制である。企業は、常時の承認なしに仕事を完了できるエージェントを求めている。一方、セキュリティチームは、すべてのアイデンティティ、権限、ツール呼び出し、重大な操作が制約下にあることを示す証拠を必要としている。

解決策は、単にあらゆるワークフローに人を追加することではない。その方法では、企業が自律システムに期待するスピードの多くが失われる。セキュリティは代わりに、操作が実行される前にソフトウェアが制限を適用できる、エージェントの実行経路により近い場所へ移行する必要がある。

エージェント型AIのセキュリティがGoogle Newsで注目された理由

ニュースの本質は、AIが誤る可能性があることではない。その誤りが今や実システムに到達し、実際の操作を引き起こし得る点に変化がある。

従来の生成AIは通常、人がプロンプトを入力するのを待つ。文章、画像、コードを返し、それを誰かが確認する。このやり取りには、モデル出力と業務上の影響との間に明確なチェックポイントがある。

エージェント型AIは、そのチェックポイントを取り除くか、狭める。AIエージェントとは、計画、ツール利用、反復的な行動を通じて目標を追求するシステムだ。情報を集め、進路を選び、ある段階が失敗すれば調整できる。

この能力がリスクの計算を変える。チャットボットは、本番データベースの削除を提案できる。過剰な権限を持つエージェントは削除を試行し、エラー後に再試行し、別の認証情報を探すことができる。

同じ区別は、日常のオフィス業務にも当てはまる。メールの下書きを作成するアシスタントは、確認可能な成果物を生む。受信者を見つけ、社内文書を添付し、メッセージを送信するエージェントは、誰かが気付く前に情報を漏らす可能性がある。

Forbesのセキュリティに関する論考は、セキュリティチームが通常は個別に管理する環境、アイデンティティ、データの境界をエージェントが横断すると説明している。著者でCyeraの幹部であるJason Clarkは、これを既存の統制にとって構造的な問題として提示している。

この情報源は、独立した調査報道ではなく、Forbes Technology Councilへの寄稿である。その主張は業界幹部による分析として読むべきだ。ただし、その中核的な懸念は、独立した研究、ベンダーのガイダンス、新興の技術標準にも見られる。

重要な変化は、委譲された権限にある。エージェントは、ユーザーのアイデンティティ、サービスアカウント、または自身の認証情報を通じて動作する場合がある。それぞれのモデルは、責任と権限範囲について難しい問いを生む。

ユーザーのアカウントを借用すれば、エージェントにはその人物に割り当てられたすべての権限が与えられる。共有サービスアカウントでは、帰属の特定が難しくなる。エージェント専用のアイデンティティは可視性を高めるが、それはシステムがそのコンテキストを継続的に評価できる場合に限られる。

エージェントは、より長い因果関係の連鎖も生み出す。あるエージェントが別のエージェントに記録の検索を依頼することがある。2番目のエージェントは第三者ツールを呼び出し、そのツールがデータを取得して別のモデルへ渡す可能性がある。

引き渡しのたびに、新たな信頼判断が生まれる。セキュリティチームは、誰がタスクを開始したのか、どのエージェントが動作したのか、どの権限を受け取ったのか、その権限が有効であり続けたのかを判断しなければならない。

Google Newsでの露出は、この問題により広い可視性を与えるが、集約そのものが出来事ではない。実際の出来事は、導入とセキュリティ上の証拠が収束していることだ。エージェントがワークフローへ入り込む一方で、アイデンティティ統制は依然として人間と静的なワークロードを中心に設計されている。

このギャップにより、アーキテクチャの議論は運用上の問題へと変わる。セキュリティリーダーは今、固定された一連の手順に従うのではなく、目標を解釈するシステムが生み出す操作を統治する必要がある。

セキュリティは依然としてキーボードの背後に人がいると想定している

大半のアクセスシステムは、あるアイデンティティに権限があるかを問う。しかしエージェントは、その操作が委譲された目的に今なお合致するかを問うことを強いる。

人間中心のセキュリティは、いくつかの実務的な前提に基づいている。人はサインインし、組織のルールを理解し、おおむね人間的な速度で操作を行う。活動が異常に見える場合、調査担当者はその人物に確認できる。

これらの前提は、どれもエージェントへそのまま移行できない。エージェントは疲労せずに数千の判断を下せる。また、曖昧な指示を、ほかの点では似通った二つのセッションで異なるように解釈する可能性もある。

一般にIAMと呼ばれる従来のアイデンティティおよびアクセス管理は、誰がシステムへアクセスでき、そのアイデンティティが何を実行できるかを制御する。ロールは多くの場合、職務または技術的機能に基づき、安定した権限の集合を付与する。

財務部門の従業員には、請求書、支払いツール、レポーティングシステムへのアクセスが与えられる場合がある。サービスアカウントには、あるアプリケーション向けにデータベースアクセスが与えられる場合がある。レビューでは、それらの権限が引き続き適切かを確認する。

エージェントは、一つの割り当ての中でそうした境界を横断できる。サプライヤーの問題を解決する依頼には、メール、契約、請求書、支払い状況、社内メッセージが必要になる場合がある。静的なロールでは、その一時的な目的に必要な正確な権限を表現しにくい。

Cloud Security Allianceは、2026年の企業調査で大きな可視性ギャップを報告した。組織の73%が1年以内にエージェントが不可欠になると予想していた一方、68%はエージェントの活動と人間の活動を明確に区別できなかった。この調査結果は、同団体の自律エージェント調査に掲載されている。

この区別は調査に不可欠だ。エージェントが従業員のトークンを使用する場合、従来型のログには従業員のアイデンティティしか表示されないことがある。分析担当者は、その人物がボタンをクリックしたのか、ソフトウェアに操作を委譲したのかを把握できない可能性がある。

人間を前提とする考え方は、承認設計にも影響する。多くの統制は、認証を主要な信頼イベントとして扱う。ユーザーがそのゲートを通過すると、セッションが終わるか別のポリシーが介入するまで、システムは認可された活動を許可する。

エージェントには、より頻繁な判断が必要だ。権限は、タスク、現在の段階、要求されたリソース、ツール、データの機密性、提案された操作の結果に応じて決まるべきである。

四半期の市場ブリーフィングをまとめるよう依頼されたリサーチエージェントを考えてみよう。承認済みの公開情報源を読むことは、その目的に合致する。機密の買収関連ファイルを開くことは、たとえ依頼した幹部にアクセス権があっても、合致しない。

エージェントが借用したアイデンティティでは、両方の操作が認可される可能性がある。目的を認識する統制は、それでも後者を拒否しなければならない。割り当てられたタスクの範囲外だからだ。

スピードがこの弱点を増幅する。繰り返しアクセスに失敗した人は、停止してサポートに連絡するかもしれない。エージェントは再試行したり、別のツールを選んだり、利用可能なコンテキストから別の認証情報を探したりする可能性がある。

こうした振る舞いは、エージェントが目標に従っていても攻撃に似て見えることがある。また、自動化によって通常は防御側に対応時間を与える遅延が取り除かれるため、実際の侵害を増幅する可能性もある。

そのためセキュリティチームは、人間の委任者、実行するエージェント、要求を受け取るサービスまたはツールという三つのアイデンティティを分離するよう迫られている。この連鎖の一部でも失われれば、帰属は弱まる。

必要なのは、より大きな従業員ディレクトリではない。すべての段階で委任コンテキストを維持し、タスク終了時にアクセスを失効させる認可モデルである。

自律性と統制は反対方向に引っ張り合う

エージェントを価値あるものにする特性――独立性、持続性、広範なツールアクセス、適応的な計画――は、恒久的な信頼を危険なものにもする。

有用なエージェントには、行動を選べる十分な自由が必要だ。細かな段階ごとに人間の承認が必要なら、エージェントは手作業のための複雑なインターフェースになってしまう。

しかし、制限のない自律性は受け入れがたいセキュリティモデルを生む。モデルは目標を誤解し、悪意あるコンテンツに従い、誤った記録を選択し、承認済みのツールを通じて情報を開示する可能性がある。

プロンプトインジェクションは、この対立を示す一例だ。この攻撃では、モデルが読み取るコンテンツの中に指示を埋め込み、モデルがそのコンテンツを命令として扱うことを狙う。Webページ、文書、メール、ツールの応答が敵対的なテキストを含み得る。

従来型アプリケーションは、コードとシステム境界により、実行可能な命令と通常のデータを分離する。言語モデルは両方を同じ推論コンテキストで処理するため、その区別を一貫して適用することはより困難になる。

Webを閲覧するエージェントは、保存情報を開示するよう命じる隠された指示に遭遇する可能性がある。エージェントが機密メモリと通信ツールへアクセスできるなら、一つの汚染されたページがそれらの能力を結び付けることがある。

失敗は複数の統制レイヤーにまたがる。モデルがデータを指示として誤分類する。アプリケーションが不要なデータ読み取りを許可する。ツールが目的を確認せずに外向きの操作を受け付ける。

疑わしいフレーズを一つ遮断するだけでは、この連鎖を解決できない。攻撃者は指示を書き換えたり、コンテンツ全体に分割したり、間接的な参照を悪用したりできる。防御側には、モデル自身の推論プロセスの外側にある統制が必要だ。

Microsoftのエージェントセキュリティガイダンスは、固有のデジタルアイデンティティ、最小権限アクセス、ガードレール、承認ワークフロー、監査を推奨している。これらの統制は、モデルが書面上の指示に従うことへの依存を減らす。

最小権限とは、特定のタスクに必要なアクセスだけを付与することだ。エージェントの場合、この原則は既存の多くの企業ロールよりも、狭く、より一時的なものになる必要がある。

経費エージェントには、提出された一件の領収書と一つのポリシー文書を読む権限が必要かもしれない。すべての従業員の経費への恒久的なアクセスは必要ない。また、自身の例外処理を承認すべきでもない。

短期間で失効する認証情報は、露出を抑えられる。ブローカーは、特定のエージェント、タスク、リソース、時間枠に対して認証情報を発行できる。受信するサービスは、操作を受け入れる前にそれらの条件を検証できる。

影響の大きい段階には、より強固な障壁が必要だ。送金、記録の削除、本番システムの変更、規制対象データの開示では、決定論的なポリシーチェックを作動させるべきである。決定論的とは、同じ定義済み条件が同じ判断を生むことを意味する。

モデルは操作を提案できるが、その操作が許可されるかを自身で決めるべきではない。この分離は、アプリケーションがアクセスを要求し、ポリシーシステムが要求を評価するという、よく知られたセキュリティ慣行を反映している。

人間の承認にも、特に意図をコードで安全に表現できない場合には役割がある。ただし、承認プロンプトは意味のあるコンテキストを提供しなければならない。一般的な「許可」ボタンは、判断を改善せずにリスクを移すだけだ。

レビュー担当者は、依頼した人間、実行するエージェント、影響を受けるリソース、提案されるアクション、期待される結果、そしてエスカレーションの理由を確認できるべきです。承認は、そのアクションだけを対象とし、以後のすべてのステップを包括するものではありません。

この設計は、定義された境界の中で有用な自律性を維持します。エージェントは低リスクの取得や分析を中断なく処理できます。一方で、重大な結果を伴うアクションには段階的に強力なチェックが適用されます。

トレードオフがなくなることはありません。境界を厳しくすれば柔軟性は下がり、権限を広げれば、ミスが及ぼしうる影響は大きくなります。企業は、自律性が残余リスクを正当化できるだけの価値を生む場所を判断しなければなりません。

アイデンティティは必要だが、意図を説明することはできない

すべてのエージェントに名前を与えることは説明責任を高めますが、アイデンティティだけでは、有効なアクションが現在のタスクの範囲内にあるかどうかを判断できません。

エージェント型AIセキュリティでは、アイデンティティが最も一般的な出発点になっています。それは理にかなっています。防御側は、ユーザーやバックグラウンドサービスと区別できない主体を統制・調査することはできません。

Google Cloudは2026年5月、従来のコントロールは、機密データとマシン速度でやり取りする自律エージェント向けに設計されていないと述べました。同社のagent identity controlsは、エージェントアクセスの管理とランタイム防御の強化に重点を置いています。

Microsoftも同様に、エージェントを個別のアイデンティティを付与すべきデジタルな主体として扱っています。これにより、ポリシーとログは、エージェントのアクションをタスクを割り当てた人物の行為と区別できます。

Coalition for Secure AIは、agentic IAM frameworkでさらに踏み込んでいます。既存のアイデンティティプロトコルが、エージェント、委任された権限、アクセス判断をどのように表現すべきかを検討しています。

こうした取り組みは、既存のIAMベンダー、クラウドプラットフォーム、アプリケーション開発者に対応を迫ります。下流のシステムが十分な情報に基づく認可判断を下せるよう、すべてのレイヤーが十分なコンテキストを伝達しなければなりません。

一意のアイデンティティは、どのエージェントがリクエストを行ったかには答えられます。しかし、なぜそのリクエストが存在するのか、計画が変更されたのか、あるいはそのリソースが依然として必要なのかには、自動的には答えられません。

この制約が重要なのは、侵害されたエージェントでも正しく認証できるためです。盗まれた認証情報、汚染された指示、改変されたメモリ、操作されたツール応答は、必ずしも無効なアイデンティティを生み出すわけではありません。

エージェントは、それぞれ単独では許可されているアクションを実行しながら、全体として有害な連鎖を形成する可能性があります。顧客記録の読み取り、選別したファイルの圧縮、外部向けメッセージの送信は、個別に評価すればいずれも通常の操作に見えるかもしれません。

しかし、これらのアクションを組み合わせれば、データ窃取に該当し得ます。セキュリティシステムは、タスク全体にわたる意思決定とアクションの順序立った経路、すなわち軌跡を検証する必要があります。

trajectory assuranceに関する2026年の研究論文は、エージェントシステムではアクション単位のチェックだけでは不十分だと主張しています。著者らは、アイデンティティ、委任、通信、実行コントロールにまたがるアーキテクチャ上の検証を重視しています。

このアプローチは行動検知に似ていますが、タスクのコンテキストを追加します。たとえば、契約書の要約を割り当てられたエージェントは、技術的な権限がその操作を許していても、アクセス・ポリシーの変更を始めるべきではありません。

ランタイムコントロールは、現在のアクションを当初の目標、承認済みの計画、以前のステップ、残存する権限と比較できます。軌跡が想定された境界から外れた場合には、実行を一時停止できます。

ログにも、より高い精度が必要です。有用な監査証跡には、委任者、エージェントのアイデンティティ、モデルのバージョン、ツール呼び出し、アクセスしたリソース、ポリシー判断、発生した副作用を記録すべきです。

ただし組織は、私的な推論や機密性の高いプロンプトを無制限に記録することには慎重であるべきです。詳細な記録そのものに、機密データ、認証情報、従業員情報、顧客コンテンツが含まれる可能性があります。

そのため、監査可能性には独自のセキュリティおよびプライバシー上の義務が伴います。ログにはアクセス制御、保持ルール、改ざん耐性、明確な目的が必要です。テレメトリーが多いからといって、自動的に安全なテレメトリーになるわけではありません。

メモリは別の複雑さをもたらします。エージェントは、セッションをまたいで設定、タスク履歴、運用コンテキストを保持する可能性があります。破損したメモリは、元の悪意あるコンテンツが消えた後も、後続のアクションに影響を及ぼしかねません。

組織には、こうしたメモリに対する来歴情報が必要です。来歴情報は、情報がどこで生成され、どのように変化し、どのプロセスが継続利用を承認したかを記録します。

機密性の高いナレッジワークフローでは、ソース資料を整理し追跡可能に保つことも有益です。searchable knowledge baseは人間によるレビューを支援できますが、エージェントの認可に取って代わるものではありません。

したがって、アイデンティティは一つのコントロールプレーンであり、完全な答えではありません。安全な実行には、目的の制限、外部ポリシーの適用、軌跡の監視、復旧可能な記録も必要です。

最も困難な問題は、委任後の説明責任である

エージェントは意思決定を実行できますが、その結果に対する法的、運用上、倫理上の責任を負うわけではありません。

人間中心のセキュリティでは、説明責任は最終的に個人または組織に帰着すると想定されます。エージェント型システムは、その経路をなくすことなく複雑化させます。

事業責任者は、幅広い成果を目指してエージェントを承認するかもしれません。開発者はそのツールを選定するかもしれません。プラットフォームチームは認証情報を管理し、セキュリティチームはポリシーを定義する一方、ベンダーは基盤となるモデルを提供します。

エージェントが害を引き起こした場合、各参加者は別のレイヤーを指し示すことができます。責任者は具体的なアクションを選んでいません。開発者は悪意あるコンテンツを作成していません。モデル提供者は本番環境へのアクセスを付与していません。

この分断は、オーナーシップの空白を生みます。技術的な帰属はどのコンポーネントが動作したかを特定できますが、組織としての説明責任では、誰がリスクを受け入れ、誰がシステムを停止できるかを特定しなければなりません。

本番環境のすべてのエージェントには、責任を負うオーナーが必要です。そのオーナーは、エージェントの目的、データ境界、ツール、リスク分類、エスカレーション経路を承認すべきです。

オーナーシップは、すべての出力をレビューすることを意味するべきではありません。自律性が許容され続ける条件を維持することを意味します。また、証拠がその条件から外れたときにエージェントを停止することも意味します。

セキュリティチームには、エージェントとその能力に関する最新のインベントリが必要です。各記録には、エージェントのオーナー、委任者、認証情報、接続されたツール、データアクセス、モデル依存関係、許容される結果を含めるべきです。

このインベントリは、承認済みのプロジェクトだけでなく、実際のデプロイメントを反映しなければなりません。エージェントは、ソフトウェア機能、従業員が構築した自動化、開発フレームワーク、ブラウザ拡張機能、サードパーティ統合を通じて導入されることがあります。

エージェントは通常のAPIトラフィックに見える可能性があるため、発見は困難です。既存のユーザートークンやサービスアカウントを使用している場合もあります。エージェント固有のシグナルがなければ、防御側はアクションを確認しても、その主体を見逃します。

説明責任は可逆性にも依存します。システムは、どのアクションが取り消し可能か、どれほど迅速に取り消せるかを定義すべきです。下書きをレビューキューに送ることは可逆です。公開すると、より広範で予測しにくい影響が生じます。

同じ区別はセキュリティ運用にも当てはまります。エージェントはデバイスの隔離を推奨できます。しかし、病院のワークステーションや本番サーバーを自動的に切断することは、異なる運用リスクを伴います。

組織は、アクションを結果の重大性で分類すべきです。読み取り専用アクセス、社内向け下書き作成、外部コミュニケーション、金融取引、権限変更、破壊的操作を、単一の承認ポリシーで扱うべきではありません。

ここでは懐疑的な見方にも注意を払う価値があります。提案されているエージェント向けコントロールの一部は、依然としてベンダーの主張、アーキテクチャ上の推奨、または初期段階の標準にとどまっています。異種混在の本番環境全体での有効性は、大規模には確立されていません。

一意のアイデンティティは、誤った判断を防ぎません。詳細なログも、すでに完了したアクションを止めることはできません。人間による承認は、形式化、性急な判断、誤解を招くコンテキストへの脆弱性を招く可能性があります。

外部ポリシーエンジンであっても、誤りを含む可能性があります。ルールが例外的なワークフローを見落としたり、個別には許容されるアクションの有害な組み合わせを許可したりすることがあります。

したがって、セキュリティプログラムは、エージェントのアイデンティティが自律的リスクを「解決する」と主張すべきではありません。可視性と適用は改善されますが、モデル、ツール、データ、組織上の意思決定には残余の不確実性が残ります。

より安全な目標は、失敗を限定することです。エージェントのアクセス、稼働時間、支出権限、他システムに影響を与える能力は限定されるべきです。

失敗が発生した場合、チームは一連の経緯を再構築し、エージェントを封じ込め、認証情報を取り消し、影響を受けたリソースを復元し、ポリシーを更新できるべきです。

このモデルは、ミスを想定される運用上の出来事として扱います。すべてのプロンプト、モデル応答、ツール呼び出しが意図どおりに振る舞うと仮定するよりも、現実的です。

セキュリティが追いついているかを示す3つのシグナル

次の段階は、自律的リスクに関する警告の追加ではなく、強制可能なコントロールと本番環境での証拠によって測られます。

第一のシグナルは、タスクスコープのエージェントアイデンティティの導入です。クラウドプラットフォームとエンタープライズアプリケーションは、エージェントがユーザーの完全なアクセス権を継承せずに、一時的な権限を受け取れることを示さなければなりません。

特定の委任者、目的、ツールセット、リソース、有効期限に紐付けられた認証情報に注目してください。また、下流のアプリケーションが汎用的なベアラートークンを受け入れるのではなく、そのコンテキストを評価できるかも確認すべきです。

広範なサポートが実現すれば、既存のアイデンティティ基盤がエージェント向けに進化できるという見方が強まります。導入が遅ければ、特に複数のクラウドやソフトウェアベンダーにまたがる難しい相互運用性の問題が明らかになるでしょう。

第二のシグナルは、ランタイムコントロールの独立したテストです。ベンダーは、ガードレール、監視、エージェント固有の認可をますます説明しています。購入者には、これらのシステムが現実的な多段階攻撃や偶発的なポリシー違反を阻止するという証拠が必要です。

テストには、間接的なプロンプトインジェクション、汚染されたメモリ、侵害されたツール、権限昇格、許可済みアクションの有害な組み合わせを含めるべきです。また、正当な業務を中断する誤検知も測定すべきです。

異なるモデルやアプリケーションで強い結果が得られれば、ランタイムでの強制へ移行する根拠になります。管理されたデモに限定される結果であれば、このアーキテクチャが広範な導入に備えているという主張は弱まります。

第三のシグナルは、インシデント後に組織がエージェントのアクションを再構築できるかどうかです。規制当局、保険会社、顧客、社内監査担当者は、誰が権限を委任し、なぜ重大なアクションがポリシーを通過したのかを問うでしょう。

完全な記録では、人間の依頼をエージェント、モデル、ツール、データ、承認、最終的な副作用に結び付けるべきです。欠落したつながりがあれば、説明責任が依然として推論に依存していることが明らかになります。

このシグナルは、運用面での準備状況も試します。ある企業は詳細なログを持っていても、エージェントの停止を認可されたオーナーがいないかもしれません。別の企業は認証情報を取り消せても、クリーンな復旧ポイントがない可能性があります。

Google Newsでエージェント型AIを追う読者は、3つの異なる動向を区別すべきです。モデル能力は、エージェントが何を試みられるかを示します。プロダクト導入は、企業がどこにそれらを配備しているかを示します。セキュリティ成熟度は、それらのデプロイメントが統制可能であり続けるかを示します。

これらの曲線は同じ速度で進んでいません。エージェントの能力と統合は、ソフトウェア更新によって拡大できます。一方、アイデンティティの再設計、アプリケーションのサポート、監査慣行、組織上のオーナーシップには、協調した変更が必要です。

開発者は、別のツールを接続する前に、エージェントが本当に必要とする権限を問うべきです。エンタープライズの購入者は、アイデンティティの分離、ポリシー適用、ログ、インシデント封じ込めに関する証拠を求めるべきです。

ナレッジワーカーは、アシスタントが提案をする段階から実際に行動を始める段階へ移ったことに気付くべきです。その境界によって、ミスが下書きのまま収まるのか、運用上の事象になるのかが決まります。

最も重要な問いは、エージェントが人間のように振る舞うかどうかではありません。人間とは異なる形で動作するアクターを、システムが制約できるかどうかです。

人による監督は依然として重要ですが、それだけを唯一の安全対策にすることはできません。企業が導入した自律性を失わずに、機械の速度で下されるすべての判断を人がレビューすることは不可能です。

セキュリティは、人間の意図を強制可能な技術的境界へと組み込まなければなりません。そして、その意図を委任、ツール呼び出し、メモリ、変化する計画のすべてにわたって維持する必要があります。

Google Newsを巡る注目は、次の見出しへ移っていくでしょう。しかし根本的な試練は残ります。組織は、有用な自律性を与えつつ、目に見えず、恒常的で、説明責任を伴わない権限まで与えずに済むのでしょうか。

次のエージェントを導入する前に、指示から結果に至るまでのタスクを一つ、完全にマッピングしてください。すべての認証情報、データソース、ツール、承認、復旧手順を特定します。欠けているつながりは、単なる文書化の不足ではありません。そこは、自律的な行動が人間の統制を追い越し得る場所です。