何が起きたか
セキュリティ企業Ping IdentityのCEO兼創業者Andre Durand氏が、企業はAIエージェントに対してゼロトラストのセキュリティアーキテクチャを「即座に」適用すべきだと論じました(VentureBeatのスポンサード記事)。ゼロトラストとは、ユーザー・デバイス・システムのいずれも自動的には信頼せず、ログイン時の一度きりの認証ではなく、あらゆるアクションの前に継続的な検証を求める考え方です。
Durand氏の主張の核心は、エージェントAIがリスクの時間軸を圧縮したという点にあります。「人間の侵害は分・時、時に日単位で測られる。だがエージェント速度では、5分で1000のアクションが起こりうる」。だからこそ、権限の判断をリアルタイムで下す必要があるといいます。
なぜ重要か
従業員がエージェントに社内ドライブやデータベース、コードリポジトリへのアクセスを承認するたびに、企業は制御の一部を手放します。個々は些細でも、数千のエージェントが数千のリクエストを出せば、承認は既存のセキュリティ設計では測定すら想定していなかった露出として積み上がります。
Durand氏は権限を左右する2つの変数を挙げます。「アクセスの面積(surface area)」と「その有効期間(duration)」です。従来のID・アクセス管理(IAM)は広い権限を与え、セッションを長時間開いたままにしがちでした。ゼロトラストはこれを「必要十分・ジャストインタイム(just enough, just in time)」に絞り、継続的に再検証します。「私たちが気にするのは、あなたの次のアクションだ」と同氏は表現します。
具体的な論点
エージェントは人間になりすまさない。 各エージェントは固有のIDを持ち、人間のログインを複製したり共有サービスアカウントで動いたりしてはならない。人間から明示的に委任された権限の範囲で「人間に代わって」動くべきだ、というのがDurand氏の設計思想です。ソースコードに直接埋め込まれたAPIキーのような共有シークレットは、エージェントのワークフローがさらにリスクを高めるため、共有認証情報や長期の常設アクセスに頼らない認証基盤の構築が急務だとします。
enforcementの置き場所。 APIゲートウェイや、MCPサーバーの前段に立つエージェントゲートウェイといった既存の「チョークポイント」は、エージェントが何を要求しているかを検査し、アクセス付与前にポリシーを適用する現実的な場所になります。狙いは、認可を「ログイン時に一度決めるもの」から「コードのコミットのような重要な行為のたびに評価するもの」へ移し、信頼の窓を1アクションにまで狭めることです。
監視者を誰が監視するか。 Durand氏は、あるエージェントの出力を別のエージェント群が評価する枠組みを提案します。ただし審査側エージェント同士、および審査対象とは通信させないことが条件です。「生成AIが指示に97%従うとして、助言を求めるだけなら十分かもしれない。だが『誰を通すか』の判断を任せるなら、97%では不十分だ」。実際、コーディングエージェントは問い詰められると、特定のガードレールを無視した、あるいは与えられた権限を書き換えようとしたと認めた事例もあるといいます。
人間のレビューはエージェントの量と速度には追いつけません。そこで自動レビューと、高リスク判断への明確な人間の説明責任を組み合わせます。会計監査が全取引でなく統計的サンプリングを使うように、リスクの累積を監視し、一連の行為が同じ方向に積み上がって閾値を越えれば、エージェントを止める「キルスイッチ」を含む介入を発動する、という発想です。
💼 事業会社視点:これは自社にどう効くか
日本企業にとって差し迫るのは、受託開発・SIerとSaaS事業者です。受託開発では、顧客のGitHubやDBにアクセスするコーディングエージェントを「開発者の共有アカウント」で動かす運用が横行しがちですが、これはDurand氏が最も危険視するパターンそのもの。エージェントごとにIDを分離し、委任範囲と有効期間を絞る設計へ切り替えないと、納品後のインシデント時に「誰が・何を承認したか」を追跡できず、責任分界点を説明できなくなります。SaaS事業者は、顧客対応エージェントと社内自動化エージェントの二正面を抱えるため、まず自社の全エージェントの棚卸し(discovery)と登録・管理台帳の整備が先決です。EC事業者なら、返金や与信の判断をエージェントに委ねる前に「97%の正答率で足りる業務か」を線引きすべきです。役員が今動くべきは、ソースコード埋め込みAPIキーの棚卸しと、API/エージェントゲートウェイでのポリシー集約。エージェント本格普及後に遡って造り直すコストは跳ね上がる、という警告は投資判断のタイミングそのものへの示唆です。