AI暴走に対抗するための企業セキュリティのあり方
AIエージェントが企業システムの中で実際に動き始めたことで、従来のセキュリティ対策では対応しにくい問題が増えている。
AI新聞ではこれまで、AIエージェントが評価中に実在企業のシステムへ侵入した事例や、外部サービスにデータを送信した事例、AIを使った攻撃者が短期間で企業内部へ入り込んだ事例などを相次いで報じてきた。
こうした問題に対して、一般企業はどう備えればいいのか。
米VC大手Andreessen Horowitz（a16z）が9月26日に公開したPodcastでは、元Microsoft幹部でa16z Board PartnerのSteven Sinofsky氏と、a16z General PartnerのMartin Casado氏らが、AIエージェントの普及に伴い、企業の認証や権限管理、ネットワーク、さらにはOSまで見直す必要があると指摘した。
同じ方向性は、米国立標準技術研究所（NIST）、米Microsoft、Webアプリケーションのセキュリティ標準化団体OWASPも示している。
共通するのは、AIが適切に判断してくれることを前提にせず、「何をしてよいか」を企業システム側で制御するという考え方だ。
「人間なら普通に使う」という前提が崩れる
企業の情報システムは、長い間、人間が操作することを前提に作られてきた。
もちろん内部犯行やアカウントの乗っ取りは想定されている。しかし日常のシステム設計では、大多数の社員が与えられた権限の範囲で通常の業務を行うことが前提になっている。
AIエージェントが入ると、この前提が崩れる。
a16zのPodcastでSinofsky氏らは、AIエージェントの特徴として、人間とは比較にならない量の操作を短時間で実行できる点を挙げた。多数のAPIを呼び出し、ファイルを開き、社内サービスを横断して作業を続けることができる。指示の解釈を誤れば、望ましくない操作を大量に繰り返す可能性もある。
人間なら一度や二度で気づく誤操作でも、ソフトウェアなら人間に気づかれないまま高速に何度も繰り返されてしまう。そのため、これまで社内利用では大きな問題になりにくかったAPIやファイル共有、社内SaaSなども、使われ方が変われば新たなリスクになり得るわけだ。
Microsoftは、こうしたAIエージェントにもZero Trustの考え方を適用する必要があるとしている。Zero Trustとは、社内だから安全だとみなさず、アクセスのたびに相手を確認し、必要最低限の権限だけを与える考え方だ。
さらにMicrosoftは、アクセスを許可するかどうかをAI自身に判断させるのではなく、通常のソフトウェアで決めたルールによって制御すべきだとしている。AIはあくまでも統計論の世界。100％の絶対はない。一方のソフトウェアは決定論の世界、「OK」と「だめ」がはっきりしている世界だ。アクセスの許可をソフトウェアで制御すれば、ルール通りに動いてくれるというわけだ。
すべてのAIエージェントに「身分証」を持たせる
企業側の具体策として、NISTとMicrosoftが重視しているのが、AIエージェントに独立したIDを持たせることだ。
AIエージェントが社員のアカウントやAPIキーをそのまま使って動けば、問題が起きた際に、「社員本人が操作したのか」「社員の指示を受けたAIが実行したのか」を記録上で区別しにくくなる。
Microsoftは、AIエージェント一体一体を「first-class principal」、つまり人間のユーザーや通常のアプリケーションと同じように、独立したアクセス主体として扱うべきだとしている。
例えば「請求書確認Agent」「顧客問い合わせ分類Agent」「コードレビューAgent」それぞれに別のIDを与える。そのうえで、誰が管理しているのか、何の目的で使うのか、どのデータを読めるのか、どのAPIを利用できるのかをIDごとに決める。
NISTも、AIエージェントの普及には「identity」と「authorization」、つまり身元確認と権限管理が基盤になるとの考えを示している。
エージェントが増えたときに、「どのエージェントが、どの権限で動いたのか」を区別できる状態にしておくことが出発点になる。
「何でもできるAI」を作らない
次に重要になるのが、エージェント一体あたりの役割を小さくすることだ。
Microsoftは、AIエージェントを「マイクロサービスのように設計する」ことを勧めている。
一つのAIに、メール、Slack、Google Drive、顧客データベース、GitHub、会計システムまで扱わせるのではなく、仕事ごとにエージェントを分ける。
例えば、請求書を読むAI、異常を検知するAI、修正案を作るAIを別々にする。
そうすることで、一体のエージェントに問題が起きても、影響をその担当範囲にとどめやすい。
企業が考えるべきなのは、「このAIにどこまで多く仕事を任せられるか」ではなく、「このAIの役割をどこまで限定すべきか」だ。
権限は「読む」と「書く」を分ける
役割を小さく分けたうえで、各エージェントに与える権限も必要最小限にする。
例えば資料を要約するAIなら、文書を読む権限は必要だが、元のファイルを書き換えたり削除したりする権限までは必要ない。
問い合わせを分類するAIなら、顧客情報を参照する必要はあっても、顧客データベースを変更する権限は不要かもしれない。
Microsoftは、権限を部署やチーム単位ではなく、「その仕事を実行するために必要な範囲」で細かく設定することを推奨している。
さらに同社は「least privilege（最小権限）」に加えて、「least agency（最小自律性）」という考え方も示している。これは権限だけでなく、AIが自律的に動ける範囲そのものを必要最小限にするという考え方だ。
例えば読み取り権限しかないエージェントでも、社内システムへのアクセス回数に制限がなければ、大量のデータを取得したり、サービスに過剰な負荷をかけたりする可能性がある。
OWASPも、AIエージェントには必要なツールだけを与え、読み取りと書き込みを分離することを推奨している。
危険な操作だけ、人間に戻す
権限を絞ったうえで、それでも影響の大きい操作については、人間の承認を入れる。
ただし、すべての操作について人間に確認を求めればいいわけではない。
Sinofsky氏は、AIが外部サービスへアクセスしたりファイルを書き換えたりするたびに「許可しますか」と尋ねる仕組みを、Cookieの同意画面が大量に表示される仕様になぞらえた。警告が多すぎれば、人間は内容を読まずに「OK」を押すようになる。
そこで、データ削除、外部への機密情報の送信、送金、本番環境の変更、アクセス権の変更など、失敗した場合の影響が大きい操作だけを承認対象にする。
Microsoftも、「deterministic（決定論的） human-in-the-loop」という考え方を示している。どの操作で人間の承認が必要になるかを、AIの判断ではなくシステム側のルールで決めておく方法だ。
「誰が何をしたか」を後から追えるようにする
もう一つ不可欠なのが、AIエージェントの行動記録だ。
一つの仕事を終えるまでに、AIエージェントが複数のシステムへ入り、ファイルを読み、APIを呼び出し、別のエージェントへ処理を渡す可能性がある。
問題が起きたときに最終結果だけを見ても、どこで誤ったのかは分からない。
Microsoftは、エージェントID、使用した権限、アクセスしたデータ、実行した操作、誰の代理として動いたのか、実行時刻などを記録できるようにすることを求めている。
必要なのは、「AIが何と答えたか」だけではなく、「どの操作を実行したか」を追える記録だ。
また、異常が起きた場合には、そのエージェントを即座に止める必要がある。IDを停止すれば、そのエージェントが持つ認証情報やトークンも無効になる仕組みにしておくのがいいだろう。
OWASPも2026年9月に公開した「Agent Control Standard」で、企業がAIエージェントについて「何者か」「何にアクセスできるか」「何をしたか」「なぜしたか」を確認し、実行中にも制御できることを重要な要件としている。
OSから変わる可能性
こうした対策を進めていくと、現在のOSや企業システムそのものにも変化が必要になる可能性がある。
現在のOSは基本的に人間が操作することを前提にしているため、AIエージェントに権限を与えようとすると、「広く許可する」か「操作のたびに確認する」かという粗い設定になりやすい。
Martin Casado氏は、高度な権限管理や多層型のセキュリティ自体は新しい考え方ではないと指摘する。OSやネットワークの研究分野では何十年も前から研究されてきたが、人間が日常的に使うには複雑だったため、十分には普及しなかった。
AIエージェントが多数のシステムを操作するようになれば、こうした技術を実用化する必要性が高まる。Casado氏は、AIをきっかけにOS、ネットワーク、プログラミング言語などの研究が再び活発になる可能性があると指摘している。
「安全なAIを選ぶ」だけでは足りない
企業が生成AIを導入するとき、これまではモデルの性能や、入力したデータが学習に使われないかといった点が主な検討事項だった。
しかしAIエージェントが企業システムを実際に操作するようになれば、検討対象はモデルだけでは済まない。
重要になるのは、エージェントがどのIDで動き、どのシステムに接続し、どの権限を持ち、その行動を後から確認できるかだ。
これまでAI新聞が報じてきたセキュリティ事故でも、被害の大きさを左右したのはモデルだけではなかった。エージェントが接続できる範囲や与えられた権限、実行環境の設定が重要な要因になっていた。
AIエージェントの普及に伴い、企業のセキュリティ対策も「AIそのものを守る」だけでなく、「AIを社内でどう動かすか」を管理する方向へ広がり始めているようだ。
参考URL
https://www.youtube.com/watch?v=TLJNJDf2XGo
https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd
https://www.microsoft.com/en-us/security/blog/2026/05/14/defense-in-depth-autonomous-ai-agents/
https://genai.owasp.org/resource/agent-control-standard-acs/
https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html
