Nutanix、AIエージェント向けブリッジを追加 Blocks Files報道が示す新たな制御ポイント
企業がエージェントアクセスに関する確立されたルールを依然として欠く中、NutanixはAIエージェントのための新たな制御ポイントを追加した。Blocks Filesの報道は、Nutanix Cloud Platform内で起きている重要な変化を浮き彫りにしている。Nutanixはもはや、AIアプリケーションの基盤となるインフラだけを管理しようとしているのではない。エージェントがモデル、ツール、そして非公開の業務データにアクセスする方法も統制しようとしている。
この変化の中心にあるのが、Nutanix Enterprise AI 2.7で一般提供が始まったNutanix Agent Gatewayだ。このゲートウェイは、エージェントとそれらが利用するシステムの間に位置する。ポリシーを適用し、アクティビティを記録し、トークン消費量を監視し、ホスト型モデルとプライベートモデルの間でリクエストをルーティングする。
ただし、最も重要なコネクターは依然としてテクニカルプレビュー段階にある。Model Context Protocol（MCP）は、AIアプリケーションが共通インターフェースを通じて外部ツールを検出・呼び出しできるようにするオープンプロトコルだ。Nutanixは、MCPサポートにより、エージェントが承認済みサーバー経由でアクセスできるツールを制御できるとしている。
一般提供とテクニカルプレビューの違いは重要だ。ゲートウェイは現在、モデルへのトラフィックを管理できる。一方で、エージェントにより広範な業務上の到達範囲を与えるツールアクセス層は、まだ本番利用向けには位置付けられていない。
Nutanixは、主要クラウドプロバイダーがすでに重要性を認識している市場にも参入している。Microsoft AzureとAmazon Web Servicesは、認証、ポリシー、監視をエージェントとエンタープライズシステムの間に配置するゲートウェイを提供している。Nutanixは、自社のハイブリッドインフラにおける立ち位置が、より優れた制御境界を生み出すことを証明しなければならない。
Nutanixがクラウドプラットフォームに実際に追加したもの
Nutanixは、AIエージェント、モデル、業務ツールの間にある経路へと、インフラ制御プレーンを拡張している。
Nutanix Agent Gatewayは、Nutanix Enterprise AI 2.7を通じて利用できる。同社はこれを、モデルアクセス、エージェントガバナンス、利用状況の可視化、コスト管理のための一元化レイヤーと説明している。
このゲートウェイは統合エンドポイントを提供する。つまり、アプリケーションはモデルプロバイダーごとに個別統合するのではなく、単一の制御されたインターフェースを呼び出せる。Nutanixによれば、管理者はクラウドホスト型モデルとセルフホスト型モデル全体にわたり、一貫した認証、監視、レート制限を適用できる。
このアプローチは実務上の課題に対応する。開発チームは、あるワークロードには外部モデルを使い、別のワークロードにはプライベートホスト型モデルを使うかもしれない。ゲートウェイがなければ、接続ごとに認証情報、ログシステム、制限、運用手順が異なる可能性がある。
統合エンドポイントは、その不整合を減らせる。Nutanixはまた、プロバイダーが利用不能になった場合や上限に達した場合、ワークロードが設定済みのフォールバックモデルを利用できるとしている。これにより開発者は、すべてのアプリケーション統合を書き換えることなくルーティングを変更できる。
ゲートウェイの第2の役割は、MCPサーバーに関わるものだ。MCPサーバーは、対応するAIクライアントが検出して利用できるツール、リソース、またはプロンプトを提供する。サーバーは、GitHub、Stripe、社内データベース、その他の業務システムに対する承認済み操作を公開できる。
NutanixのAgent Gateway overviewによれば、ゲートウェイはMCPトラフィックにアクセスポリシーとツール単位のフィルタリングを適用できる。また、その制御された経路を通過するリクエストの監査記録も提供できる。
これがBlocks Filesの記事で言及されたブリッジだ。Nutanixがすでに運用しているインフラと、エージェントがタスクを実行するために必要なツールを接続する。これによりNutanixは、エージェントの判断がセキュリティや財務上の影響を生み得るアプリケーション活動に、より近づくことになる。
この変化は、チャットボットに新たなコンテキストソースを与えるだけの話ではない。ツールアクセスを持つエージェントは、外部アクションを実行できる。課題を更新し、ワークフローを開始し、顧客記録を照会し、あるいは取引を送信することもあり得る。
したがってNutanixには、2つの異なる境界での制御が必要となる。1つ目はエージェントによる言語モデルへのアクセスを統制する。2つ目は、MCPサーバーを通じたエージェントのツールおよびデータへのアクセスを統制する。
これらの境界は重なり合うが、互いに代替できるものではない。トークン制限はモデル利用を抑制できる一方、ツール権限はエージェントが実行できることを制限する。エージェントが質問への回答から業務タスクの完了へと進むなら、企業には両方が必要だ。
Nutanixによると、Agent GatewayはNutanix Enterprise AIの顧客に一般提供されている。ローカルMCPサーバー機能はテクニカルプレビューのままであり、同社はプレビュー機能を本番環境で利用すべきではないと明示している。
この注意書きにより、この発表を完成したエンタープライズ向けエージェントスタックと見なすことはできない。Nutanixは中核となるゲートウェイを提供したが、最も重要なエージェントアクセス経路の1つは、依然として評価段階にある。
それでも、この出来事は明確な方向性を示している。Nutanixは共通の運用レイヤーを通じて、コンピュート、モデル、エージェント接続を制御するプラットフォームを目指している。次の問いは、なぜインフラベンダーが今このレイヤーへ進出しているのかということだ。
AIエージェントのアクセスがインフラの課題になった理由
エージェントは通常のアプリケーション統合を継続的な認可判断へと変え、インフラチームにモデル可用性をはるかに超える責任を負わせる。
従来の生成AIアプリケーションは、多くの場合、1つのモデルにプロンプトを送信してテキストを返す。その主なインフラ要件は、モデルホスティング、レイテンシー、データ処理、容量に関わる。
エージェントは異なるワークロードを生み出す。ツールを選択し、モデル呼び出しを繰り返し、サブタスクを作成し、目的に到達するまで継続できる。各ステップでトークンを消費したり、別の保護対象システムを呼び出したりする可能性がある。
Nutanixは、この振る舞いが運用モデルを変えると主張する。同社の2026年3月のagentic AI releaseでは、しばしば1つの大規模ジョブを中心に構成されるモデル学習と、多数のサービスと同時接続ユーザーを支える本番エージェント環境が対比されている。
この整理は、なぜゲートウェイが重要なのかを説明する。エージェントの最初のリクエストはホスト型モデルを呼び出すかもしれない。次のリクエストではプライベートモデルにアクセスし、その後に社内サービスを照会するツールを使用する可能性がある。さらに後のステップでは、情報を書き戻すこともあり得る。
直接接続では、こうした経路を一貫して統制するのが難しくなる。各エージェントチームが、プロバイダーの認証情報、権限、ログ、クォータ、フェイルオーバーをそれぞれ異なる方法で扱うことになりかねない。
ゲートウェイは、プラットフォームチームに共通の強制適用ポイントを提供する。呼び出し元を認証し、アクセス可能なエンドポイントを制限し、消費量を記録し、承認済みトラフィックをルーティングできる。MCPサポートは、この強制適用モデルを言語モデルから業務ツールへ拡張する。
コストもまた、圧力の要因だ。エージェントのワークフローは、ユーザーに見える1つのタスクの中で多数のモデル呼び出しを行う可能性がある。失敗したステップを再試行したり、並列サブタスクを生成したりすることもある。そのため、単一のリクエストは実際のリソース消費量を測る指標としては弱い。
Nutanixは、自社のゲートウェイがモデルベンダー横断でトークンレベルの可視性を提供するとしている。管理者は利用量を割り当て、レート制限を課し、選択したワークロードをセルフホスト型モデルへルーティングできる。これらは同社の主張であり、顧客は得られる会計情報が完全なエージェントワークフローをカバーしているかを検証する必要がある。
可視性が自動的に節約を生むわけではない。可視性は消費がどこで起きているかを運用者に示すが、チームには依然として、モデル選定、品質、レイテンシー、許容可能な失敗率に関するポリシーが必要だ。
アクセスの問題はさらに根本的である。エージェントがGitHub、決済サービス、またはプライベートデータベースにアクセスする際、重要なのは単に接続が機能するかではない。管理者は、どのIDが開始したのか、どのツールが実行されたのか、どの引数を受け取ったのか、そして結果が外部状態を変更したのかを知る必要がある。
MCPはクライアントがツールを検出・呼び出す方法を標準化するが、共通プロトコルが認可リスクをなくすわけではない。標準化された接続性は、実際には利用可能な統合の数を増やし得る。そのため、信頼できるポリシー境界の重要性は高まる。
Nutanixは、NAI 2.7 APIでMCPツール、プロンプト、リソースのサポートを文書化している。このドキュメントでは管理APIも実験的と表示されており、本番導入に向けた慎重な評価の必要性を改めて示している。
この圧力は主にエンタープライズのプラットフォームチームにかかる。開発者はモデルとツールへ迅速にアクセスしたい一方、セキュリティチームは制御されたIDと監査可能なアクションを求める。財務チームは説明責任のある消費管理を求める。運用チームは予測可能な障害時の挙動を求める。
Nutanixは、これらの要件を既存のハイブリッドクラウド運用モデルの一部にしようとしている。この提案は、プライベートデータセンターとクラウド環境にまたがってNutanixインフラをすでに運用している組織に、最も直接的に訴求する。
こうした購入者にとって、ローカルの制御レイヤーはガバナンスをプライベートワークロードの近くに置ける。また、すべての管理機能を単一のパブリッククラウドプロバイダー経由で送る必要性を減らすこともできる。
しかし、導入済みインフラがエージェント採用を保証するわけではない。開発者は、インフラチームが標準化する前にフレームワークやツールを選ぶことが多い。Nutanixは、チームを孤立した開発体験に縛り付けることなく、自社ゲートウェイを有用なものにしなければならない。
この緊張関係こそが、実際の競争を生む。Nutanixは単なるAI機能を販売しているのではない。あらゆるエージェントリクエストが通過すべきポリシーレイヤーになるために競っている。
Blocks Filesの報道が示す本当の競争：ゲートウェイを制御するのは誰か
主な競争は、Nutanixのハイブリッド制御プレーンと、すでにエンタープライズのモデル、ID、APIのそばに位置するクラウドプロバイダーのゲートウェイとの間で繰り広げられている。
Microsoftは、MCPサーバーを扱えるようAzure API Managementを拡張している。同社のドキュメントによれば、このサービスは既存のMCPサーバーを公開したり、管理対象のREST APIをMCPインターフェースに変換したりできる。
Azureは、これらの接続に認証、クォータ、レート制限、監視を適用できる。セルフホスト型ゲートウェイはハイブリッド環境でバックエンドの近くにも配置できるため、オンプレミス制御がNutanixだけのものだという主張を弱める。
MicrosoftのMCP governanceは、ツールアクセスを既存のAzureサービスとも結び付ける。すでにEntra ID、Azure Monitor、API Managementを利用している企業は、別のエージェントレイヤーを導入するのではなく、使い慣れた制御を拡張できる。
AWSも、Amazon Bedrock AgentCore Gatewayを通じて同様の方向性を取っている。このサービスは、エージェント、モデル、ツール、他のエージェントのための単一の管理エントリーポイントを提供する。
そのAgentCore Gatewayは、API、Lambda関数、サービスをMCP互換ツールに変換できる。推論ルーティングやエージェント間トラフィックもサポートする。
これらの提供は、ゲートウェイのカテゴリーが複数の機能を中心に収束していることを示している。ベンダーはモデルエンドポイントを統合し、ツール呼び出しを仲介し、認証を強制し、利用量を制限し、テレメトリーを収集しようとしている。
Nutanixは、デプロイメント制御と、より広範な自社プラットフォームとの統合によって差別化しなければならない。その立ち位置は、エージェントガバナンスが、すでに企業の管理下にあるインフラとデータのそばに置かれるべきだという考えに基づいている。
この主張は、規制の厳しい環境、データ主権に敏感な環境、または接続が制限された環境で重みを持つ。顧客は、プライベートモデル、ローカルデータ経路、エージェントツールを、自らが運用するインフラ境界の内部にとどめたいと考えるかもしれない。
Nutanixは、ゲートウェイをプライベート推論管理、Kubernetes、仮想化、ネットワーキング、ストレージとも組み合わせている。同社の広範なAIプラットフォームは、オンプレミスおよびパートナー環境にまたがるエージェント・ワークロードの運用に向け、これらのコンポーネントを一つのスタックとして提示している。
利点は、アーキテクチャ上の一貫性にある。プラットフォームチームは、エージェントをホストする環境、リクエストを処理するモデル、ツールを制御するゲートウェイを、関連するNutanix製品群を通じて管理できる。
リスクはスタックへの集中だ。複数の連携したNutanixレイヤーを導入する買い手は、運用の簡素化を得られる一方、Nutanixのリリーススケジュール、統合、ポリシーモデルへの依存を深める可能性がある。
クラウドプロバイダーも、しばしばより大きな規模で同様の批判に直面している。MicrosoftとAWSは、アイデンティティ、モデルアクセス、API、監視、エージェントサービスを一括提供できる。両社の広い到達範囲は統合を容易にするが、ワークロードをそれぞれのプラットフォームへ引き寄せる可能性もある。
したがって、この判断は単にNutanixと一つのパブリッククラウドのどちらを選ぶかではない。組織がエージェントのコントロールプレーンをどこに置くかという選択だ。
パブリッククラウドのゲートウェイは、そのクラウド上ですでに稼働しているモデルやサービスと自然に連携できる。Nutanixのゲートウェイは、データ、モデル、アプリケーションが複数の拠点にまたがるハイブリッド環境と整合し得る。
どちらの道を選んでも、認可セマンティクスを精査する必要はなくならない。ゲートウェイは呼び出し元がMCPサーバーへアクセスできることを検証できるが、基盤となるツールには、結果が大きく異なる複数の操作が公開されている可能性がある。
ツールレベルのフィルタリングは、この問題への対処に役立つ。ソフトウェアサポート用のエージェントにはリポジトリへの読み取りアクセスを与えても、コードをマージする権限は与えない、といった運用が可能だ。財務アシスタントは取引状況を照会できても、支払いを開始する権限までは持たないようにできる。
こうした区別には、接続済みサーバーの一覧以上のものが必要となる。買い手には、アイデンティティ、タスクの文脈、ツール操作、データ範囲、そしてアクションが状態を変更するかどうかを反映したポリシーが必要だ。
また、使いやすいログも必要となる。エージェントが一つのサーバーに到達したという記録だけでは、どのツールを選択したのか、どのパラメーターを渡したのか、あるいはモデルがなぜその行動を選んだのかは説明できない可能性がある。
Nutanixは、Agent Gatewayが集中型のポリシー適用、利用状況の可視化、監査証跡を提供するとしている。これらの主張は、適切な制御面を示している。実運用での証拠は、記録がどれほど多くの文脈を保持するのか、そしてセキュリティチームが疑わしいアクションをどれほど容易に調査できるのかを示す必要がある。
これが、「blocks files」という見出しが単なる製品追加以上の意味を持つ理由だ。エージェントの橋渡し機能は、インフラガバナンスをアプリケーションレベルの制御問題へと変える。Nutanixは新たな役割を得る一方で、厳しいセキュリティ期待も引き継ぐことになる。
MCPブリッジは依然プレビュー段階であり、それが主張を変える
Nutanixには一般提供済みのゲートウェイがあるが、エージェントからエンタープライズツールへの最も直接的な橋渡しは、同社自身のガイダンスによれば、依然として本番利用には適さない。
テクニカルプレビューのステータスは、その機能に価値がないことを意味しない。本番ワークロードを委ねる前に、顧客がアーキテクチャ、互換性、管理、ポリシー動作を検証する手段を提供する。
しかし、プレビューのステータスは、この発表が証明できる範囲を制限する。Nutanixは意図する設計を確立したが、多様なエンタープライズのエージェント環境で成熟した運用を実証したわけではない。
同社のゲートウェイ発表では、MCPサーバーアクセスはテクニカルプレビュー段階にあるとされている。付随する注記では、プレビュー機能を本番環境で使用すべきではないとしている。
ここには重要な隔たりがある。組織は、一般提供済みのゲートウェイを推論トラフィックの制御に利用できる。一方で、Nutanixがサポート方針を変更するまで、ローカルMCP接続は評価機能として扱うべきだ。
セキュリティチームは、まずアイデンティティの伝播から検討すべきである。エージェントへのリクエストは、人間のユーザー、サービスアカウント、別のエージェント、自動化プロセスから発生し得る。ゲートウェイは、ツールが適切な認可判断を下すのに十分なアイデンティティの文脈を保持しなければならない。
共有APIキーは接続を簡素化できるが、帰属の追跡を弱める。複数のエージェントが一つの認証情報を使用する場合、調査担当者は、どのユーザーまたはワークフローが機微なアクションを認可したのかを特定しにくくなる可能性がある。
組織は、ゲートウェイとツールバックエンド間の認証情報の扱いも検証すべきだ。ゲートウェイは受信したエージェントを認証する一方で、GitHub、Stripe、データベース、社内API向けには別の認証情報を保持する場合がある。
この構成は、バックエンドのシークレットをエージェントアプリケーションから保護できる。一方で、ゲートウェイを価値の高い制御点にもする。設定ミスや管理者アカウントの侵害によって、多数の接続済みシステムが露出する可能性がある。
ツールディスカバリーにも同等の精査が必要だ。MCPでは、クライアントが利用可能なツールを一覧表示し、その説明を確認できる。これらの説明は、モデルがどの操作を呼び出すかを判断する助けとなる。
曖昧な説明は、エージェントを誤ったツールへ導く可能性がある。悪意ある、あるいは侵害されたツールメタデータも、エージェントの選択に影響し得る。承認済みサーバーをフィルタリングすることは必要だが、承認だけで公開されるすべての操作が安全であることを保証するわけではない。
管理者は、読み取り専用ツールと外部に変更を生じさせるアクションを分けるべきだ。読み取りアクセスでも機密情報を露出し得るが、書き込みアクセスは別種のリスクを持ち込む。
有用な展開は、限定的なタスクから始めることになる。たとえば、サポートエージェントには、再起動権限を与えずに社内サービスの状態を取得させられる。チームはその後、ゲートウェイの記録をバックエンドログと比較できる。
影響の大きいアクションでは、人による承認を引き続き利用できるようにすべきだ。プロトコル接続がエージェントの推論を信頼できるものにするわけではなく、ポリシーが必要な文脈を提供しない限り、ゲートウェイはビジネス上の意図を判断できない。
レート制限も、もう一つの不完全な防御策を提供する。暴走した呼び出しや過剰なトークン消費を抑えることはできる。しかし、許可された一回の呼び出しが許容できないビジネス上の結果を生むかどうかは判断できない。
フェイルオーバーも検証に値する。Nutanixによれば、統合エンドポイントはトラフィックを設定済みの代替先へ切り替えられる。この動作は可用性を向上させるが、異なるモデルは同じプロンプトやツール説明に対して異なる応答をする可能性がある。
フォールバックモデルは別のツールを選択したり、引数を異なる形式で指定したり、プライマリモデルが受け入れる操作を拒否したりする可能性がある。チームには、エンドポイントの稼働状況だけでなく、ルーティング変更後の挙動もカバーする評価が必要だ。
可観測性は、モデルとツールのアクティビティを結び付けなければならない。調査では、ユーザーリクエストからモデルの判断、ツール呼び出し、ツール応答、最終的なエージェントアクションまでの流れを再構築できるべきだ。
共通の識別子を持たない個別のログは、その再構築を遅らせる可能性がある。Nutanixは、そのようなエンドツーエンドのトレーシングがどれほど完全で使いやすいものになるかを、独立したテストを通じて公に確立してはいない。
買い手は、ポリシー変更が進行中のワークフローにどう影響するかも問うべきだ。エージェントは時間をかけて複数ステップのタスクを実行できる。ワークフローの途中で取り消された権限は、キャッシュされた認証情報や開いたセッションを残すことなく、予測可能な形で有効になるべきだ。
互換性も別の不確実性である。Nutanix Enterprise AI 2.7は、特定のMCPプロトコルバージョンへの対応を文書化している。MCPは進化を続けており、クライアントやサーバーは異なる速度で機能を実装し得る。
ゲートウェイは、予期しない動作を生むことなく、こうした差異を仲介しなければならない。本番利用への準備は、アップグレード手順、後方互換性、明確なエラー報告に左右される。
これらの問題はいずれも、Nutanixだけの信頼性を損なうものではない。Microsoft、AWS、その他のゲートウェイプロバイダーも、同じ根本的な課題に直面している。MCPは通信を標準化する一方、本番環境のガバナンスは依然としてベンダー固有の制御と運用上の規律に依存する。
より正確な結論は、より限定的だ。Nutanixは適切な境界を見定め、制御レイヤーの一部を提供した。そのプレビュー表記は、顧客がエージェントからツールまでの経路全体を信頼する前に、なお証拠を必要としていることを示している。
ナレッジワーカーにとって、この区別は、エージェントにどのシステムへの到達を許可すべきかに影響する。パーソナルナレッジベースは、自律ワークフローに本番ツールへの権限を与えずに、情報の整理を支援できる。
検索と実行を同じ権限として扱うべきではない。組織は、エージェント支援による調査の恩恵を得つつ、運用上の変更はより限定的なワークフローと強固なレビューに委ねることができる。
顧客が、アイデンティティ、最小権限のアクセス許可、詳細な監査記録、予測可能なフェイルオーバー、実際のワークロード下での安全なツール動作を検証できるようになったとき、ゲートウェイは信頼性を得るだろう。それまでは、このブリッジは完成された答えではなく、検証可能なアーキテクチャにとどまる。
Nutanixがエージェントアクセスを担えるかを示す三つのシグナル
次の試金石は、また一つのエージェント型AI発表ではない。Nutanixがプレビューブリッジを、顧客が実際に信頼する本番用コントロールプレーンへと変えられるかどうかだ。
第一のシグナルは、MCPサーバーアクセスの一般提供だ。Nutanixは、対応するデプロイメントパターン、プロトコル互換性、ライフサイクル手順、本番サポートに関する期待値を明確にすべきである。
一般提供のリリースは、Agent Gatewayがモデルトラフィックとツールアクセスの両方を統制するというNutanixの主張を強化する。プレビューが長期化すれば、最も運用上センシティブな接続が未完成のままとなるため、より広範なフルスタックのメッセージは弱まるだろう。
リリースの詳細は、ラベルと同じくらい重要だ。買い手は、アイデンティティを認識する権限、ツールレベルのポリシー制御、認証情報の分離、詳細な監査イベント、明確なアップグレードガイダンスを確認すべきだ。
第二のシグナルは、顧客による証拠である。Nutanixには、エージェントが何にアクセスできるのか、ゲートウェイがどこで稼働するのか、チームがセキュリティまたは運用面の改善をどのように測定するのかを示す本番事例が必要だ。
一般的な推奨コメントから得られる情報は少ない。有用な証拠は、定義されたワークフロー、接続されたMCPツール、承認モデル、運用担当者が失敗または拒否されたリクエストをどう調査したかを示すものとなる。
既存のNutanix顧客内での採用は、同社のハイブリッド・コントロールプレーンに関する主張を裏付けるだろう。顧客がゲートウェイをモデルルーティングだけに使い、ツールガバナンスには別製品を選ぶなら、Nutanixの立場はより限定的に見える。
第三のシグナルは、競合の反応と機能比較だ。MicrosoftとAWSはすでに、ゲートウェイ製品を通じてMCPガバナンスを提供している。両社のサービスは、アイデンティティ、ポリシー、監視、ツール公開機能を継続的に追加している。
Nutanixは、既存のパブリッククラウドゲートウェイを拡張するのではなく、なぜ買い手が自社プラットフォームにエージェントポリシーを置くべきなのかを示さなければならない。デプロイメントの近接性、プライベート推論、Nutanixインフラとの統合はもっともらしい答えを構成するが、顧客には測定可能な運用上の利点が必要だ。
Nutanixが、周辺コンポーネントのすべてをNutanix製にすることを求めずに、異種ツールとモデルをサポートするかを注視すべきだ。幅広い相互運用性は、中立的なハイブリッドレイヤーであるという主張を強化する。密な依存関係は、ゲートウェイをもう一つのプラットフォームバンドルのように見せるだろう。
「blocks files」レポートは、最終的にクラウド管理におけるより大きな変化を示している。エージェントはインフラチームが観測し、制約しなければならない判断を生むため、インフラベンダーは仮想マシンやストレージの上位へ移行している。
Nutanixは、その制御点としてゲートウェイを選んだ。アーキテクチャは理にかなっており、一般提供済みのモデルゲートウェイはこの戦略に実際の基盤を与えている。MCPブリッジは依然として、決定的で未完成の要素だ。
エンタープライズの買い手は、プレビュー期間を利用して、限定的で読み取り中心のテストを構築し、監査記録が実務的なセキュリティ上の問いに答えられるかを測定すべきだ。機能リストだけを評価するのではなく、同じワークフローをNutanix、Azure、AWSで比較すべきである。
ユーザーのアイデンティティを維持し、各ツールを厳密に制限し、すべてのアクションを説明し、プライベートおよびパブリックのインフラストラクチャ全体で稼働し続けるゲートウェイはどれでしょうか。これらの問いに本番環境での実証をもって答えるベンダーは、エージェントのトラフィック以上のものを掌握することになります。AIの意図と企業のアクションを隔てる運用上の境界を支配することになるのです。
