Abnormal AI AgentCoreメールセキュリティ、エージェントの到達範囲を制限して拡張
Abnormal AIは、毎日数十億通のメールメッセージを処理する検知システム内にAmazon Bedrock AgentCore Code Interpreterを導入した。Abnormal AI AgentCoreメールセキュリティの設計では、自律エージェントに一時的なコンピューティング環境を与える一方、その環境に無制限のインターネットアクセスは許可しない。この制約は些細な設定ではなく、設計の中核となる考え方だ。
エージェントが扱うのは、パイプラインにおける最も難しい日次ケースのうち数万件にとどまる。まず軽量な分類器が数十億通のメッセージを処理し、より大規模な機械学習モデルが数百万件の不確実な判定を精査する。Abnormalは、前段階で確信を持って分類できないケースに限って、エージェント主導の分析を割り当てている。
このアーキテクチャは、利用可能な最大規模のモデルへすべてのメッセージを送ることが、より優れたメールセキュリティにつながるという単純な考え方に異議を唱える。また、人間によるレビューのためにフィッシング分類を説明できるMicrosoft Security Copilotのようなアナリスト中心のシステムとも異なる。Abnormalはエージェントをインラインの検知パイプラインに直接配置しており、そこではレイテンシー、隔離、予測可能な障害境界が即座に重要になる。
この導入が重要なのは、エージェントが行動ベースの脅威データを分析しながらスクリプトを書き、実行できるためだ。この能力は固定分類器よりも柔軟性をもたらす一方で、新たな攻撃対象領域も生み出す。メールは証拠であると同時に、潜在的に敵対的な入力でもある。したがって、これを調べるエージェントは安全でない判断を下す可能性があるものとして扱わなければならない。
Abnormalの答えは、選択的なエスカレーションと制約付き実行を中心に構築された多層システムだ。モデルには、一時的なサンドボックス内で計算、集約、検証を行う余地が与えられる。周辺アーキテクチャが、何を取り込み、何を外部へ出せるか、どの操作を利用不可にするかを決定する。
Abnormal AI AgentCoreメールセキュリティは最も難しいケースを対象にする
主な変化は、AbnormalがAIエージェントを追加したことではない。コードを書けるエージェントをライブの検知パイプラインへ組み込みながら、全ワークロードを任せていないことだ。
導入事例によると、Abnormalは3つの処理階層を使用している。第1階層では、小規模モデル、ヒューリスティックルール、ロジスティック回帰分類器を用い、毎日数十億通のメッセージを処理する。これらの手法は、高コストな分析を必要としないケースを扱う。
不確実性が残るメッセージは第2階層へ渡される。ディープラーニングなどの機械学習モデルが、より広範な行動シグナルを用いて毎日数百万通のメッセージを検査する。未解決の中でも最も難しいケースだけが第3階層に到達する。
最終階層では、インラインエージェントとCode Interpreterを使って、毎日数万通のメッセージを処理する。エージェントは脅威インテリジェンスデータを受け取り、動的にスクリプトを書き、各ケースがAbnormalの行動モデルにどのように適合するかを分析する。その後、メールが受信トレイに届く前に、検知判断へ寄与する。
このファネルは、経済性と信頼性の両面で重要だ。すべてのメッセージで汎用エージェントを動かせば、多くの場合に追加価値が最も少ない箇所へ最も多くの計算資源を投入することになる。また、本番パイプラインのより大きな部分を非決定的な挙動にさらすことにもなる。
選択的なエスカレーションにより、エージェントは例外処理担当となる。前段階が予測可能なボリュームを吸収し、エージェントは従来なら人間のアナリストに割り当てられていたケースを調査する。この設計では、製品上の位置付けではなく、不確実性に応じてモデルの複雑さを使い分ける。
このアーキテクチャは、エージェント障害の運用上の影響も抑える。第3階層でのエラーも重要ではあるが、エージェントが通常のすべてのメッセージの分類を支配するわけではない。別のシステムが誤分類を処理し、より広範な検知システムの改善に活用する。
Abnormalによれば、監視システムもライブパイプラインを検証している。AWSの事例では、独立した精度、偽陽性率、レイテンシーの測定値は公開されていない。したがって、これは運用アーキテクチャを示すものであり、エージェントがあらゆる従来型検知手法を上回ることの比較的な証明ではない。
同社は、インラインパスの外側でもアナリストエージェントを稼働させている。このバッチシステムは、誤分類とチューニングシグナルを取り込み、より大規模なメッセージ集合にわたるパターンを探索する。第1階層向けの候補ヒューリスティックを作成し、第2階層の改善にも寄与する。
AWSによると、このアナリストエージェントは週に約100件のバッチジョブを実行する。個々のジョブは30分超にわたって稼働する場合がある。モデル学習はCode Interpreterセッションの外で行われるため、一部のワークフローは丸1日に及ぶ。
このフィードバックループにより、エージェントには第2の役割が与えられる。難しいメッセージを判定するだけではない。難しい結果から、後でより低コストな分類器が適用できるルールも抽出する。
その結果、実務的な役割分担が生まれる。固定ルールはスループットを担い、学習済みモデルはより広いパターン認識を提供し、エージェントは柔軟な調査を担う。最も高コストな推論は、その柔軟性に明確な目的があるケースに限定される。
スクラッチパッドは追加のモデルコンテキストではなく計算環境
Code Interpreterが重要なのは、言語生成を計算として扱うのではなく、エージェントが計算し、主張を検証できるようにするためだ。
大規模言語モデルは、計算を説明しながら誤った結果を出す可能性がある。また、有用なスクリプトを提案しても、そのスクリプトが正しく実行されるかは分からない。Abnormalのエージェントには、生成したコードを許可されたデータに対して実行できるワークスペースが必要だ。
Amazon Bedrock AgentCore Code Interpreterは、APIを通じてそのワークスペースを提供する。このサービスは、コマンド実行、ファイルアップロード、結果返却のための隔離環境をエージェントに提供する。特定の推論ループやエージェントフレームワークを強制するものではない。
AWSは、この機能を完全管理型かつサーバーレスの実行ランタイムとして説明している。セッションは、一時的なMicroVM内で実行される。MicroVMは、計算、メモリ、ファイルシステムが隔離された軽量仮想マシンだ。セッションはデフォルトで15分間続き、最大8時間まで設定できる。
この環境には、一般的なデータ処理、統計、可視化ライブラリを備えたPythonおよびNode.jsランタイムが含まれる。最大100 MBのファイルはAPIを介して直接受け渡せる。より大きなデータセットには、Amazon S3または顧客管理のファイルシステム設定を利用できる。
コンテキストと計算の区別は重要だ。脅威インテリジェンスをモデルのプロンプトに加えると、モデルが解釈する材料は増える。Code Interpreterを与えることで、エージェントはその材料をプログラムで変換、集計、比較、検証できるようになる。
Abnormal AIのエグゼクティブであるShrivu Shankarは、この環境を、ほぼあらゆるエージェントに必要な計算用スクラッチパッドと表現している。この捉え方は、コード実行をソフトウェア開発支援の枠を超えるものへと広げる。セキュリティエージェントは、集約、行動比較、データ検証、再現可能なスコアリングのためにスクリプトを使える。
エージェントはプログラムによる検証器も実行できる。テスト、リンター、統合チェックは、出力が別の本番コンポーネントに到達する前に、機械可読なフィードバックを提供する。正しさを保証するものではないが、エージェント自身が生成した説明を超える証拠を与える。
このアプローチは、エージェント設計におけるより広いパターンに似ている。開発者は、作業を提案するモデルと、それを実行するランタイムを分離する動きを強めている。モデルは確率的なままであり、実行環境は特定の操作に対して決定的な結果を提供する。
AWSは、エージェント生成コードを安全に実行するためのインフラとしてCode Interpreterを最初に導入した。Abnormalのパイプラインにおける価値は、この分離から生まれる。Abnormalは既存のエージェントハーネスを維持しながら、隔離された計算を外部サービスとして扱える。
軽量なハーネスは、エージェントに柔軟性も与える。Abnormalによれば、厳格なステップバイステップのワークフローは、汎用ツールと組み合わせた高水準の原則よりも性能が低くなる可能性がある。エージェントは手法を選べるが、周辺システムが定めた境界内で動作しなければならない。
このバランスは難しい。自由度が低すぎれば、エージェントは高価な固定ワークフローに成り下がる。自由度が高すぎれば、信頼できない入力がコード、ネットワークリクエスト、ファイル、認証情報に影響を及ぼせるようになる。
スクラッチパッドモデルは、その中間地点を見いだす。エージェントにはスクリプトや一時的な成果物を作成するローカルな自由を与える。一方で、そのワークスペースを取り巻く本番環境に対する権限を自動的に与えるわけではない。
構築者にとって、この設計は、別のモデルやより大きなコンテキストウィンドウを追加する前に明確な問いを示す。エージェントに必要なのは、より多くの知識か。それとも、制御された計算場所か。この2つの問題には異なるインフラが必要となる。
社内エージェントを構築するチームには、モデルのプロンプトの外側に永続的な記録も必要だ。検索可能なナレッジベースは、仕様や運用上の知見を保持できる。実行サンドボックスは一時的なものにとどめ、承認済みの知識はガバナンスされたシステムを通じて永続化すべきだ。
外部送信不可のサンドボックスはエージェントリスクを限定可能な問題に変える
Abnormalの最も強力な設計判断は、エージェントが予期しない挙動を示した場合でも、分析サンドボックスに無制限のネットワークアクセスを許可しないことだ。
メールセキュリティエージェントは、外部者が作成したコンテンツを処理する。攻撃者は、そのコンテンツ内に指示、リンク、エンコードされた素材、敵対的なテキストを含められる。モデルはこれらの要素を証拠として解釈するかもしれないが、指示として扱ってしまう可能性もある。
この問題は、信頼できないコンテンツがエージェントを本来のタスクから逸脱させようとするプロンプトインジェクションとして知られる。モデルレベルの防御は一部の攻撃を認識できる。しかし、あらゆる操作に対して決定的な保証を提供することはできない。
そのためAbnormalは、Code Interpreterのサンドボックスネットワーク設定を選択した。その実装では、実行環境にパブリックインターネットへの外部送信経路はない。脅威インテリジェンスは分析のために取り込めるが、生成されたコードがその情報を外部エンドポイントへ自由に送信することはできない。
この制約には2つの目的がある。第1に、外部のWebサイトやサービスが実行中にセッションの挙動を変えられないため、再現性が向上する。第2に、モデルが悪意ある指示に従ったり、安全でないコードを生成したりした場合でも、データ流出を抑制できる。
これが本記事の中心的な緊張関係、すなわちエージェントの柔軟性と実行の境界設定だ。システムは、計算方法の選択とスクリプト作成の自由をモデルに与える。インフラは、それらのスクリプトが到達できる場所を制限する。
AWSは、Code Interpreter向けに複数のネットワークモードをサポートしている。Sandboxモードは、サポートされるAmazon S3操作を含む、制限された外部アクセスを提供する。Publicモードはインターネットリソースを許可し、VPCモードは環境を承認済みのプライベートリソースへ接続する。
これらの選択肢を、互換可能な利便性設定として扱うべきではない。Publicアクセスはエージェントができることを広げる一方、データ流出や依存関係のリスクも広げる。VPCアクセスは価値の高い内部システムへ到達できるため、実行ロールとネットワークポリシーが重要になる。
Abnormalは、既存のネットワーク分離ハーネスに管理型サンドボックスを追加している。この多層防御のアプローチは、単一の分離境界だけで十分だと見なさない。同社は、Code Interpreterに入るデータと、エージェントが実行できる書き込み操作も制御している。
このアーキテクチャは、エージェント開発の他分野で広がりつつあるセキュリティ指針とも整合する。Anthropicは、エージェントの封じ込めにはファイルシステムとネットワークの両方に境界が必要だと主張している。外部送信の制限がなければ、侵害されたプロセスがアクセス可能な秘密情報を外部へ送信できてしまう。
Anthropicの後続の封じ込め分析は、その根本的な論点をより直接的に示している。確率的な監督は、アクセス可能なリソースに対する厳格な境界の代わりにはならない。モデルが誤った判断をしても、封じ込めは影響範囲を制限する。
AWSのドキュメントは、もう一つ重要な留保を加えている。各AgentCoreセッションには、分離されたCPU、メモリ、ファイルシステムのリソースが割り当てられ、その後MicroVMは終了する。ただし、権限、セッションの対応付け、入力検証、認証情報、接続ツールについては、依然として顧客に責任がある。
セキュリティガイダンスも、MicroVM内のコードは、その環境に割り当てられた認証情報へアクセスできると警告している。他のセッションから分離されていても、現在のセッション内で過剰な権限が安全になるわけではない。
したがって、安全なサンドボックスには一時的なコンピューティング環境以上のものが必要となる。構築者は実行ロールのスコープを限定し、ネットワーク経路を制限し、ツール入力をフィルタリングし、不要な認証情報を除外しなければならない。また、実行終了後にどの成果物を外部へ持ち出せるかも決める必要がある。
外部送信を許可しないパターンは、入力が自己完結しているタスクで特に有効だ。エージェントは範囲を限定した証拠パッケージを受け取り、ローカルで計算し、限定的な結果を返せる。任意のWebサイトや外部APIを必要とするワークフローでは、より難しいポリシー上の課題が生じる。
一つの解決策は、仲介型のツールレイヤーだ。一般的なネットワーク接続を与える代わりに、エージェントは制御されたプロキシを介して名前付きツールを呼び出す。各ツールは、認証、入力検証、許可リスト、ログ記録、限定された出力スキーマを強制できる。
この設計は、サンドボックスを通常のインターネット接続マシンへ変えることなく、有用な外部アクションを維持する。また、エージェントが何を要求し、ツールが何を返したのかという記録をセキュリティチームに提供する。
Abnormalの導入は、プロンプトインジェクションを排除するものではない。インジェクションが成功した場合に、単一環境内で実行できることを減らす。これは、モデルが常に悪意あるコンテンツを見抜けると主張するよりも、防御可能な本番運用上の主張だ。
三層パイプラインは、セキュリティベンダーとエージェント構築者の双方に圧力をかける
Abnormalのアーキテクチャは、説得力のあるエージェント回答を生成する段階から、実運用上の制約下で範囲を限定した判断を下す段階へと基準を引き上げている。
メールセキュリティベンダーはすでに、ルール、レピュテーションシステム、機械学習、行動分析を利用している。新たな圧力は、柔軟なエージェントを検知ワークフローのより深い位置に組み込むことから生じる。競合各社は、エージェントをアナリストの補助として置くのか、それとも分類経路に直接組み込むのかを決めなければならない。
Microsoftのアプローチは、単純な優劣を決めることなく、有益な比較対象を提供する。同社のSecurity Copilot Phishing Triage Agentは、メール内容、送信者のレピュテーション、行動シグナルを評価する。アナリストが確認または上書きできる分類と、自然言語による根拠を生成する。
そのフィッシングトリアージモデルは、統制されたエージェントID、定義済みトリガー、アクセス権限、操作権限を重視している。透明性と人によるレビューを、ワークフローの中心近くに置く設計だ。
一方、Abnormalの報告された導入では、慎重に絞り込まれたメッセージの一部に対してインラインエージェントを使用する。出力は配信前の判断に関与するが、その周囲には監視機構と分離された学習システムが配置されている。この差異は、基本的なモデル能力よりもワークフロー上の配置に関するものだ。
どちらのアプローチも、人間のアナリストを不要にするものではない。Abnormalにとって最も難しいケースは、従来であればアナリストの注意を必要とするものだ。その調査作業の一部をエージェントが担う一方で、人間は依然として制御を設計し、失敗を解釈し、モデル変更を統制する。
このアーキテクチャは、汎用エージェントプラットフォームベンダーにも圧力をかける。本番ランタイムは、単なるコード実行以上のものを支援しなければならない。管理者が理解・運用できるセッション分離、ライフサイクル制御、可観測性、予測可能なファイル処理、ネットワークポリシーが必要になる。
マネージドサービスは、使い捨てコンピューティング環境の運用に必要な作業を減らす。しかし、アプリケーションレベルの設計判断を不要にするわけではない。構築者は依然として、どの入力をサンドボックスに到達させるか、セッションをタスクにどう対応付けるか、どの結果が本番システムを変更できるかを選択する。
三層のファネルは、別の教訓も示している。エージェントのスケーリングは、部分的にはルーティングの問題だ。すべてのリクエストに同じモデル、コンテキスト、ツール、コンピューティング予算が必要だと考えるのではなく、不確実性を測定して選択的にエスカレーションすべきである。
この原則はセキュリティ以外にも適用できる。カスタマーサポートシステムは、定型的な依頼を決定論的なワークフローに振り分け、曖昧なケースのためにエージェントを確保できる。データシステムでは、まず固定的な変換を使用し、その後スキーマや証拠が衝突する場合にエージェントを呼び出せる。
バッチアナリストは、再利用可能な第二のパターンを提供する。本番環境の失敗をオフラインエージェントに渡し、繰り返される原因を探索させ、より低コストなルールを提案させることができる。人間または自動検証機構は、それらの提案を昇格前に評価できる。
ただし、このフィードバックループにはガバナンス上の問題が伴う。過去の誤分類から導かれた候補ヒューリスティックは、一時的なパターンを取り込んだり、偏ったサンプルを増幅したりする可能性がある。構築者は、初期段階のパイプラインを更新する前に、評価セット、ロールアウト制御、ロールバック経路を必要とする。
AWSのケーススタディは、これらの運用詳細を示していない。別システムがエラーから学習し、監視が稼働中のシステムを検証するとしているが、承認の閾値、評価方法、エージェント提案のうち本番へ到達する割合は開示していない。
エンドツーエンドのレイテンシーも明らかにしていない。インラインのメール検知には配信上の制約があり、遅い第3層はユーザー体験に影響し得る。選択的ルーティングはそのリスクを軽減するが、構築者には依然としてパーセンタイルレイテンシーとタイムアウト時の挙動が必要だ。
コストも同様に不明確だ。このファネルは、数十億件もの定型的なメッセージすべてにエージェントコンピューティングを実行しないことを、ほぼ確実に可能にしている。公開資料には、メッセージ単位のコスト、セッション利用率、自己管理型サンドボックスとのインフラ比較は示されていない。
こうした欠落は、アーキテクチャを無効にするものではない。有用な顧客ケーススタディと、独立して検証された性能証拠との境界を定めるものだ。エンタープライズの購入者は、このパターンを評価しつつ、ワークロード固有の測定値を求めるべきである。
セキュリティリーダーにとって最も有益な問いは、あるベンダーが「エージェント型」検知を備えているかどうかではない。エージェントが意思決定経路のどこに入り、どの証拠を受け取り、失敗したときに何が起きるかだ。
プラットフォームチームにとっても、問いは同じく具体的だ。エージェントは厳密にスコープを限定した環境内で価値ある作業を完了できるのか。それとも、提案されたワークフローは広範な認証情報とオープンなネットワーク接続に依存しているのか。
有用な作業に無制限のアクセスが必要なら、その設計は中心的なトレードオフを解決していない。そのリスクをランタイムへ移しただけだ。
Abnormal AIのケーススタディが証明していないこと
この導入は信頼できる封じ込めパターンを示しているが、精度、速度、総運用コストにおける独立した改善を立証するものではない。
中心となる情報源は、Abnormalの参加を得て作成されたAWSの記事だ。AWSはインフラを提供し、Abnormalは紹介される顧客である。読者は、規模の数値とワークフローの説明を、企業に帰属する主張として扱うべきだ。
報告された処理量は、それでも参考になる。第1層には数十億件のメッセージが入り、第2層には数百万件が到達し、毎日数万件がエージェントに送られる。しかし、こうした件数からは、エージェントが最終判定をどの程度改善するのかは分からない。
いくつかの欠けている測定値が、評価を変え得る。偽陽性率は、難しい正当なメッセージがどの程度の追加リスクにさらされるかを示す。偽陰性率は、エージェントが先行モデルで見逃された攻撃を捉えるかどうかを示す。
アナリストレビューのデータも役立つ。人間がエージェントの判断を頻繁に覆すなら、第3層は自律的な検知ではなく、優先順位付けツールとして機能している可能性がある。覆されるケースがまれであっても、購入者には監視が静かなエラーを検知するという証拠が必要になる。
平均値は運用上の失敗を隠し得るため、レイテンシー分布は重要だ。典型的な分類がすぐに終わっても、少数の長時間実行セッションがメールを遅延させる可能性がある。タイムアウトとフォールバックは、モデル品質と同じくらい慎重にテストすべきだ。
同じ注意は、決定論に関する主張にも当てはまる。パブリックインターネットへのアクセスを除去すれば外部変動性は低減するが、モデル出力は依然として確率的であり得る。ソフトウェアライブラリ、入力順序、ランタイムのバージョン、オーケストレーションロジックも結果に影響を及ぼし得る。
「外部送信なし」も同様に、正確に解釈すべきだ。これはサンドボックスからのパブリックネットワーク通信を制限する。受信データを自動的に検証するわけでも、有害なローカル計算を防ぐわけでも、返却された成果物に機密情報が含まれないことを保証するわけでもない。
したがって、出力制御も必要になる。生成されたレポート自体に機密データが含まれる場合がある。スクリプトはインターネットに接続せずとも、過大な成果物を作成したり、セッションリソースを消費したり、誤解を招く結果を生成したりできる。
永続ストレージには追加の考慮事項が生じる。Abnormalは、作業がセッションを超える場合に、ファイルをチェックポイントとして使用する。このパターンを採用する構築者は、保持期間、アクセス境界、暗号化、同時書き込み、成果物の所有権を定義しなければならない。
ファイルシステムは復旧ポイントであり、セキュリティポリシーではない。一時的なセッションから外へ出たデータは、別の場所で永続化される。その保護は、その後ストレージサービスと、それを利用するアプリケーションに依存する。
長時間実行の作業は、ID管理も複雑にする。1日を要するプロセスは、複数のセッションや外部トレーニングジョブにまたがる可能性がある。各引き渡しには、認証済みのタスクID、明示的な入力、検証可能な出力が必要だ。
可観測性は、こうした遷移の再構成に役立つ。AgentCoreはログをAmazon CloudWatchに送信し、AWS CloudTrailを通じてアクティビティを監査できる。チームは、機密性の高いメッセージ内容を別システムに複製せずに、何をログに残すかを選ばなければならない。
エージェントの監視には、運用シグナルとセキュリティシグナルの両方が必要だ。実行エラー、タイムアウト、リソース消費は信頼性の問題を明らかにする。予期しないコマンド、ブロックされたネットワーク試行、異常な出力サイズは、悪意ある行動や混乱した行動を露呈させる可能性がある。
構築者は失敗経路も意図的にテストすべきだ。サンドボックスが起動できない場合、スクリプトが制限を超えた場合、モデルが無効なコードを生成した場合には何が起きるのか。システムには、不確実性を安全性として静かに分類しない、安全なフォールバックが必要だ。
Abnormalでは、先行する検知層がその周辺構造の一部を提供している。公開されたケーススタディは、すべての第3層の失敗に対する最終フォールバックを明示していない。このギャップは、技術評価の際に検討する価値がある。
したがって、このケーススタディが支持する結論は、その規模だけから想起されるものより限定的だ。ルーティングによってエージェントのワークロードを厳しく制限すれば、管理型の一時的コンピューティングは大規模セキュリティパイプラインに組み込める。強力な封じ込めは、モデル障害の影響も低減できる。
これは、すべてのセキュリティ判断がエージェントの恩恵を受けることを証明するものではない。より単純なシステムでは確信を持って解決できない、小規模かつ困難な末尾部分にこそ柔軟な計算が価値を持つと、Abnormalが考えていることを示している。
このパターンが大規模環境でも成立するかを示す三つのシグナル
次に注目すべき点は、AbnormalとAWSが、隔離アーキテクチャと測定可能な検知成果を結び付ける運用上の証拠を公表するかどうかだ。
最初のシグナルは、ワークロード品質に関するデータである。偽陽性率、偽陰性率、アナリストによる上書き、そして従来の第3層プロセスと比べた測定可能な改善を注視したい。こうした結果は、エージェントがアーキテクチャの複雑さではなく、検知面での価値をもたらすという主張を強めることになる。
こうした測定値が示されないからといって、失敗が証明されるわけではない。ただし、最も強い主張はベンダーが報告する導入経験の範囲にとどまる。購入側は自社のトラフィックと脅威プロファイルを用いた統制された評価を実施する必要がある。
2つ目のシグナルは、マネージド型コード実行サービスにおける、より高度なポリシー制御である。有用な進展としては、より限定的な送信先許可リスト、ツール単位の認可、成果物スキャン、認証情報ブローカリング、詳細なセッション来歴などが挙げられる。こうした制御は、サンドボックス全体を広げることなく機能を付与することで、このトレードオフを改善する。
無制限のネットワーク接続へ向かう動きは、このパターンを弱めるだろう。統合は容易になるかもしれないが、その分だけ確率的なモデル防御への負荷が増す。最も安全なアーキテクチャは、可能な限り権限をモデルの外部に置く。
3つ目のシグナルは、他のセキュリティベンダーによる選択的なエージェントルーティングの採用である。Microsoftはすでに、エージェントをフィッシングのトリアージやアナリストのワークフローと結び付けている。次に重要なのは、透明性のあるフォールバックとレビュー経路を維持しながら、ベンダーがエージェントをインラインに配置できることを示す証拠だ。
採用が広がれば、Abnormalの3層ファネルが業界のパターンになりつつあることを示唆する。アナリスト専用のコパイロットへ後退する動きは、レイテンシー、信頼性、またはガバナンスが依然としてインライン自律性を妨げていることを示すだろう。
開発者は、その市場判断を待つ必要はない。境界が明確なワークロードと明示的な評価基準を用いれば、今すぐアーキテクチャを試験できる。入力パッケージが自己完結しており、決定論的な検証器が結果を判定できるケースから始めるべきだ。
永続的な認証情報は実行環境の外部に置く。1つのタスクに必要なデータとツールだけを付与する。すべての文書、メッセージ、Webサイト、ツール応答を、潜在的に敵対的な入力として扱う。
セッション終了を、後片付けの細部ではなく設計の一部にする。承認済みの成果物だけを永続化し、監査可能なタスクIDに紐付ける。すべてのタイムアウト、不正な結果、利用不能な依存関係に対して、安全な挙動を定義する。
最も重要なのは、ファネルを測定することだ。各層で解決されるケース数、エスカレーションが発生する理由、次の層が結果を改善するかどうかを記録する。エージェントコンピュートは、測定可能な価値によってその役割を獲得すべきである。
Abnormal AI AgentCoreによるメールセキュリティの事例は、突き詰めれば規律ある制約に関するものだ。エージェントには、固定的なシステムでは結論を出せないケースを調査するのに十分な自由が与えられる。しかし、その推論が有用に見えるというだけで、無制限の到達範囲が与えられるわけではない。
これは、すべての本番エージェントチームにとって実践的な問いである。使い捨て可能で、観測可能かつ厳格に境界付けられた環境の中で、あなたのエージェントはどのような価値ある作業を完了できるのか。まずその境界を構築し、その内部にどれだけの自律性を持たせるべきかを決める。
