何が起きたか
VB Transform 2026のセッションで、NTT DATA AIVistaのCTOであるMukesh Karki氏と、Snowflakeで最高セキュリティ・トラスト責任者を務めるMayank Upadhyay氏が、企業のAIエージェント運用における権限とガバナンスの設計を議論しました。前提として示されたのが、VentureBeatが6月に実施した調査結果です。AIエージェントを稼働させている企業の69%が、いまだ認証情報を共有した状態で運用しており、この慣行はセキュリティインシデントおよびヒヤリハットの発生率の高さと結びついているとされます。
両氏の主張はシンプルです。エージェントごとにIDを割り当てる（アイデンティティを直す）のは出発点にすぎず、自律システムを安全にスケールさせるには、行動単位の認可と改ざん耐性のある監査証跡を、すべてのエージェント対話に組み込む必要がある、というものです。
なぜ重要か：従来ソフトの前提が崩れている
Upadhyay氏は、多くの企業が一世代前のソフトウェアの前提を引きずっていると指摘します。従来型のソフトは、人間がクリックした後は決定論的に動き、どのAPIを呼ぶかが事前に分かります。対してエージェント型のソフトは「自分の脳を持ち」、絶えず自らを配線し直します。目的に対して過剰な権限を与えれば、探索的な性質を持つエージェントはあれこれ試し、意図しない副作用を生む——これが第一の失敗モードです。
象徴的なのが、単一の静的APIキーをエージェントに埋め込むパターンです。Upadhyay氏はこれを「エージェントに全員のニーズの和集合を与えている」と表現しました。SaaS側から見れば、そのエージェントは「誰としてでも」話しかけてくる存在になります。
第二の失敗モードはフォレンジック、つまり事後追跡です。適切なIDがなければ、問題が起きたときに「どのエージェントの仕業か」を特定できません。
規制業種では「スコープ付き認証情報」すら出発点
Karki氏の顧客は保険・ヘルスケア・金融が中心で、スコープを絞った認証情報は当然の前提（table stakes）だと言います。規制環境では、共有スコープの認証情報で広く権限を持つエージェントは、そもそも稼働させられません。
その上でKarki氏が挙げたのが、二層の制約です。ひとつはエージェントが動作する法域、もうひとつは組織自身のルール。例として、ワシントン州で稼働する保険金査定エージェントは、カリフォルニア州のそれとは異なる規制の下にあります。しかも保険金請求は一件ごとに内容が違う。だから認可は静的な役割付与では足りず、行動が実行される「その時点で」ルールに基づいて判断される必要がある、という論理です。
そしてKarki氏は、監査人に対して改ざん耐性のある形で挙証できること——プロバビリティ（provability）こそが「規制環境における事業免許そのもの」だと述べました。
「新入社員」の比喩はどこで壊れるか
エージェントに組織のコンテキストが必要という点で、新しく入った従業員との類似はあります。ある会社のエース社員が転職先で振るわないのは能力が落ちたからではなく、その場のコンテキストを持たないから——エージェントも同じだ、とKarki氏は言います。
ただし比喩はそこまでです。従業員一人が100体のエージェントを持つ世界では、時間をかけて信頼を積み上げることも、一体ずつ身元調査をすることも成立しません。Upadhyay氏はより実務的な整理として「インターンとして扱え」と提案します。善意はあるが自分が何をしているか常に分かっているわけではないので、監督下に置きながら徐々に信頼を築く、という運用像です。
Snowflakeのプラットフォームでは、管理者が読み取り専用などのプラットフォーム全体のガードレールを課し、開発者がセッション起動時にさらに権限を絞り込む二段構えが取れるといいます。
ガバナンスは「エージェントの外側」に置く
Karki氏が繰り返したのは、ガバナンスはすべてのエージェント行動の時点で発動し、かつエージェントの外側に置かれなければならないという原則です。エージェント自身に自己申告させる設計では、「許可された行動を取った」ことを後から証明できません。
Upadhyay氏はガバナンスを3層に分解しました。エージェント層（ID、ツール権限、MCPガバナンス）、モデル層（間接プロンプトインジェクション対策、顧客のVPC内でモデルを動かしプロンプトをモデル提供者から見えなくする）、データ層（最小権限アクセス、ゼロコピーアーキテクチャ、ロールベースアクセス制御）。この3層すべてで統制が要る、という整理です。
着手点として同氏が挙げたのは2つ。ひとつは静的シークレットの権限監査で、これが「最も修正可能な攻撃面」だとします。もうひとつはシャドーAIへの対処で、MCPゲートウェイを設けることで、開発者が海賊版的なオープンソースのMCPサーバーを勝手に立てる状況をなくし、管理者は誰がどのMCPサーバーと通信しているかの可視性を得られます。
制約と能力のトレードオフについては、タスク単位で扱う道が示されました。信頼度スコアリングを使い、高リスクな行動については自律実行を保留する。サンドボックス化は中間解として位置づけられています。
そして最後の警告が実務的には最も重いところです。Karki氏は、これらの多くはエージェントシステムが稼働し始めてからでは後付けできず、監査人にエージェントの挙動理由を説明する必要が出れば後付けはさらに難しくなると述べました。挙証可能性は設計時にゼロから作り込むしかない、というのが結論です。
なお本セッション記事は、NTT DATA AIVistaによるスポンサード記事としてVentureBeatに掲載されたものです。主張の方向性にはその点を割り引いて読む余地がありますが、69%という調査値と、行動単位の認可・外部ガバナンスという設計論は、ベンダー選定とは独立に検討する価値があります。
💼 事業会社視点：これは自社にどう効くか
日本の事業会社にとって、この議論の実務的な焦点は「PoCの延長で本番投入したエージェントに、後から統制を被せられない」という一点です。すでに社内でLLMエージェントを動かしている企業の多くは、業務システムのAPIキーを1本埋め込んで動かしているはずで、これは指摘された「全員のニーズの和集合」を与える構成そのものです。金融・保険・医療に加え、個人情報を扱うECや人材系は、監査対応で真っ先に問われる領域になります。
経営者・事業責任者が今期に決めるべきは3つ。第一に、エージェント用の認証情報の棚卸しを情シスの宿題ではなく期限付きの経営課題として切ること。静的シークレットの権限監査は最も費用対効果が高い着手点です。第二に、MCPゲートウェイのような集約点を先に置き、現場が個別にオープンソースのMCPサーバーを立てるシャドーAIを、禁止令ではなく経路提供で吸収すること。第三に、監査ログをエージェントの外側に持つこと。エージェント自身に記録させる設計は、内部監査でも取引先監査でも「証拠」として通りません。
受託開発・SIerにとっては、これは要件定義の商機と同時にリスクでもあります。行動単位の認可と挙証可能性は後付けできない以上、初期設計で織り込まなかった案件は後工程で作り直しになり、その費用負担が争点化します。エージェント案件の見積もりに「ガバナンス層の設計」を独立した工程として明示できるかが、収益性の分かれ目になります。SaaS事業者側は逆に、顧客企業のエージェントが自社APIをどのスコープで叩くかを制御する機能——セッション単位の権限絞り込みや読み取り専用モード——が、今後のエンタープライズ商談で機能要件として問われると想定すべきです。