AIエージェントの権限管理リスク｜過剰な権限が招いた事故7選と最小権限の決め方
AIエージェントの事故は、AIの判断ミスではなく、渡した権限の広さが原因で起きていることもあります。
2025年から2026年にかけて、AIに本番環境を削除された、AI連携アプリのトークンを盗まれて700社超に被害が広がった、といった事故が相次ぎました。公表された経緯を読むと、原因はAIの能力ではありません。作業に必要な範囲を超えた権限が、そのままAIに渡っていたことです。
生成AIの導入を任されている方から、「エージェントに社内システムを触らせるのが怖い」というご相談をよくいただきます。とはいえ、権限を絞りすぎれば何も自動化できません。知りたいのは「禁止か許可か」ではなく、「どこまで渡してよいか」の線引きのはずです。
スパイクスタジオは、AIエージェントの開発や既存システム改修のAI対応などAIを使った企業のDX推進を幅広く手がけています。現場で権限設計の判断を求められる立場から、この記事では次の3つに答えます。
- 生成AIに権限を渡すと、具体的に何が起きるのか
- 実際に起きた事故は、権限設計のどこでつまずいたのか
- 明日から決められる、権限の切り方は何か
生成AI全般のトラブルについては生成AIの問題事例13選で整理しています。
目次
- 生成AIに権限を渡すときに起きるリスク5つ
- 権限管理が原因で起きた事故事例7選（2022〜2026年）
- 2026年に入って変わった2つのこと
- 【対策】AIに権限を渡す前に決める5つのこと
- AIエージェントの権限設計はスパイクスタジオへご相談ください
生成AIに権限を渡すときに起きるリスク5つ
権限に起因するリスクは、次の5つに整理できます。実はどの項目も、AIが登場する前から存在していた問題です。
- 人が持つ権限を、そのままAIに渡してしまう
- 本番と検証が、同じ権限でつながっている
- 社内データ連携で、既存の過剰共有が一気に露出する
- AIに発行したトークンが、人の目から外れる
- 退職・異動のあとも、権限が残り続ける
①人が持つ権限を、そのままAIに渡してしまう
いちばん多い形がこれです。担当者のアカウントや、担当者と同じ役割をAIに割り当てて動かします。設定は簡単ですが、AIは人と違い、24時間365日稼働できます。
OWASP GenAI Security Projectは、この状態を「Excessive Agency（過剰な権限付与）」と呼び、AIエージェントやLLMに対して、必要以上の機能や権限、自律性を与えることで生じるリスクの1つに挙げています。根本原因は「過剰な機能」「過剰な権限」「過剰な自律性」の3つです。「過剰な機能」とは、AIエージェントに必要以上のツールやAPIを接続すること。「過剰な権限」とは、例えば一般ユーザー用の権限で十分なものに対し、管理者権限を付与すること。「過剰な自律性」とは、人による承認フローを挟むことなく、実行まで自動で行ってしまうことなどを指します（トレンドマイクロ「『OWASP Top 10 for Large Language Model Applications』2025年版のリスク概説」（2025年5月22日公開、8月6日更新））。
対策としては、権限を必要最小限に絞ること、権限の判断をLLM自身に委ねず接続先のシステム側で認可すること、影響の大きい操作には人の承認を必須にすることが示されています（OWASP「LLM06:2025 Excessive Agency」）。
②本番と検証が、同じ権限でつながっている
検証環境で試してから本番に適用する、という手順は広く行われています。ところが、検証環境と本番環境のストレージやデータベースが適切に分離されていなかったり、AIエージェントに本番環境まで操作できる権限が与えられていたりすると、検証中の操作が本番環境にも影響するおそれがあります。人であれば画面の色やホスト名で気づく違いを、APIを直接呼ぶAIは区別しません。
③社内データ連携で、既存の過剰共有が一気に露出する
社内の文書を横断して検索・要約するAIを入れると、「とりあえず全社員に閲覧可」で置かれていた文書が、質問1つで引き出せるようになります。Concentric AIが5億5,000万件超のデータレコードを分析した調査では、企業の重要データの16%が過剰共有の状態にあり、1組織あたり平均およそ80万2,000ファイルが露出していました（Concentric AI「Is Copilot Safe? A 2026 Guide to Copilot Risks」（2026年4月23日））。AIが権限を破っているのではなく、元の権限設定がそのまま使われている点が重要です。
④AIに発行したトークンが、人の目から外れる
AIエージェントやAI連携アプリは、人のアカウントではなくトークンやAPIキー、サービスアカウントで動きます。こうした「人ではないID（非人間ID）」は、入退社の手続きにも、棚卸しの対象にも入っていないことが少なくありません。発行した本人が異動すると、誰のものか分からないまま動き続けます。
⑤退職・異動のあとも、権限が残り続ける
退職者の権限が残る問題は、AI以前からある古典的な論点です。IPA（情報処理推進機構）の「企業における営業秘密管理に関する実態調査2020」では、情報漏えいのルートとして中途退職者によるものが36.3%で最多でした（IPA、「企業における営業秘密管理に関する実態調査2020」報告書（報告書P28）、2023年10月24日最終更新）。AI連携は後から足されることが多く、退職時の停止手順に含まれていない組織が目立ちます。
権限管理が原因で起きた事故事例7選（2022〜2026年）
ここからは、実際に起きた事故を7件紹介します。読むときは「何が起きたか」ではなく、「どの権限が広すぎたか」に注目してください。自社の設定と照らし合わせる材料になります。
①AI開発ツールをめぐる問題事例｜AWSでアクセス制御の設定ミスによるサービス停止
2025年12月、AWSが世界で展開する39の地理的リージョンのうち1つで、クラウドサービスの利用料金を管理する「AWS Cost Explorer」が一時停止する事象が発生しました。
この事象はAIコーディングツールが原因だと報じられましたが、Amazonは公式発表で、障害の原因はAIではなく、人為的なアクセス制御の設定ミスだったと説明しています。具体的には、権限を管理するロールの設定に問題があり、これはAIを利用した開発ツールに限らず、通常の開発ツールや人間による操作でも起こり得る問題だとしています。また、影響はAWS Cost Explorerという単一サービスに限定され、コンピューティング、ストレージ、データベースなど他のサービスには影響しなかったと説明しています。
再発防止策として、Amazonは本番環境へのアクセスに対する別の担当者によるレビューの義務化など、複数の安全対策を導入したと公表しています。
この事例から得られる教訓は、AIエージェントそのものの判断能力だけでなく、AIに付与する権限や操作を承認する仕組みが重要だということです。AIエージェントに作業を任せる場合でも、必要最小限の権限を設定し、本番環境に影響する操作には人間による確認を組み込むことが、リスクの低減につながります。
参照Amazon「Correcting the Financial Times report about AWS, Kiro, and AI」2026年2月20日
②AIコーディングエージェントの問題事例｜本番データベースとバックアップを9秒で削除
2026年4月、レンタカー事業者向けの管理システムを提供するPocketOSで、AIコーディングエージェントが本番データベースとバックアップを削除する事故が発生しました。
AIエージェントは検証環境での作業中に認証情報の不一致に直面し、それを「修正」しようと独断で、クラウド基盤「Railway」のストレージ領域（ボリューム）をAPI経由で削除しました。エージェントは削除の影響が検証環境だけにとどまると推測していましたが、環境間で同じボリュームIDが共有されていたため、本番データベースが削除されました。一連の操作は約9秒で完了し、クラウド側のバックアップも同時に失われています。
PocketOSは3か月前のバックアップに戻さざるを得ず、その後に登録された予約情報や新規顧客プロファイルなどのデータが失われました。失われた予約情報は、顧客が車を受け取る際にリアルタイムで必要となるものでした。
この事例は、検証環境での作業であっても、AIエージェントが本番環境に影響する操作を実行できる状態では重大な事故につながることを示しています。また、バックアップが本番データと同じ削除操作の影響を受ける構成では、障害発生時の復旧が困難になることも明らかになりました。
③MCPの問題事例｜チケットに埋め込まれた指示に従い非公開テーブルを書き出し
2025年7月、MCP（Model Context Protocol。AIと外部システムをつなぐ共通規格）を介した情報流出の経路が公表されました。開発者がCursorのエージェントにSupabase MCP経由でサポートチケットの要約を依頼したところ、チケット本文に紛れ込ませてあった偽の指示にエージェントが従い、非公開のトークン管理テーブルを読み出して、そのままチケットのスレッドに書き戻しました。
この検証事例では、MCPサーバーが高い権限のロールで動作していました。Supabaseは、MCPが行レベルセキュリティ（RLS）などのデータベース側の保護を迂回するわけではないとしたうえで、用途によってはMCPサーバーが高い権限で動作する場合があり、今回もそれに該当すると説明しています。
本来、サポートチケットの要約には、必要な情報を読み取る権限があれば十分です。しかし、読み取り専用であっても、機密情報を含む広範囲のデータにアクセスできる状態では、情報漏えいのリスクが残ります。そのため、操作を読み取り専用に制限するだけでなく、参照できるデータの範囲も業務上必要なものに限定することが重要です。
Supabaseは、読み取り専用モード、対象プロジェクトの限定、利用できる機能の制限といった防御策を導入しています。また、本番データへのAIエージェントの直接接続を避け、開発・検証用のデータベースや匿名化したデータを利用することを推奨しています。なお、今回の事例は攻撃手法を実証したものであり、Supabaseは顧客の実際の情報漏えい被害は報告されていないと説明しています。
参照Supabase「Defense in Depth for MCP Servers」2025年9月16日
④MCPの問題事例｜なりすましパッケージが送信メールを攻撃者へ転送
2025年9月、メール配信サービスPostmark向けのMCPサーバーとして、運営元が公開しているものと同名のパッケージがnpmで公開されました。v1.0.15までは正常に動作するコードでしたが、v1.0.16で、AIエージェントが送信するすべてのメールを外部ドメインのアドレスへ密かにBCC転送するコードが加えられました。MCPサーバーはメール送信の権限一式を預かる部品で、出所の検証やバージョンの固定が行われていなかったため、わずかなコードの追加が、送信メールの流出につながる仕組みになっていました。MCPサーバーが扱うメールには、パスワード再設定の通知や請求書など機密性の高い内容が含まれ得るため、Snykは2025年9月中旬以降にこのパッケージを導入した場合は情報が漏れたものとして対処するよう呼びかけています。
参照Snyk「npmの悪意あるMCPサーバー postmark-mcpがメールを窃取」2025年9月25日
⑤AI連携アプリの問題事例｜OAuthトークンの窃取で700社超に波及
2025年8月、営業用AIチャットボット「Drift」のSalesforce連携に使われていたOAuthトークンが窃取されました。攻撃者は正規のAPI経由で各社のSalesforce環境に接続し、取引先情報やサポート案件の本文を大量に照会しました。案件本文に書かれていたクラウドの鍵なども併せて持ち出されています。Googleの分析によれば、影響を受けた組織は700社を超えました。SalesforceとSalesloftは全トークンを失効させ、連携アプリを一時停止しています。AppOmniは、こうしたOAuthトークンは期限が切れないことが多く、広いアクセス範囲のまま審査なく承認されがちで、SaaSのログ監視も手薄になりやすいことが、被害を広げる要因になると指摘しています。
参照AppOmniによるGoogleの分析の整理（2025年8月26日）、Salesforce「Salesforce Security Response: Drift App (Salesloft) Unauthorized Access Incident」（2026年5月4日）
⑥退職者権限の問題事例｜元同僚のIDで転職元のデータベースに不正アクセス
2022年7月、商社に転職した元社員が、転職元である兼松の社内データベースに接続し、自動車部品の取引台帳など営業秘密3件を取得しました。接続に使われたのは本人のアカウントではなく、元同僚の派遣社員に虚偽の理由を伝えて聞き出したIDとパスワードです。退職者本人の権限を止めても、在職者のIDを通じて社外からアクセスできる状態が残っていました。兼松は、多くの社員が休む週末に単一のアカウントから多数のアクセスがあったことを異常として検知し、社内調査のうえ警視庁に相談しています。元社員は不正競争防止法違反で起訴され、2024年8月に有罪判決を受けました。
参照日本経済新聞「双日元社員の営業秘密取得 土日の不審アクセスで発覚」2023年9月29日、営業秘密ラボ、2025年8月21日
⑦管理者権限の問題事例｜保守用アカウントで約900万件を持ち出し
2023年10月、NTT西日本子会社のNTTビジネスソリューションズで、コールセンターシステムの保守を担っていた元派遣社員が、システム管理者アカウントを使って顧客データの保管サーバーに接続し、個人情報を私物のUSBメモリーで持ち出していたことが公表されました。持ち出しは2013年7月頃から2023年1月まで続き、件数は公表時点で約900万件、59社・団体に及ぶことが分かりました。保守業務に必要な範囲を超えた管理者権限が共用のまま長期間維持され、アクセス記録の定期的な点検も行われていませんでした。
参照日経クロステック「元派遣社員の顧客情報900万件持ち出し防げず、NTT西子会社のずさんな内部不正対策」（2023年10月19日）
2026年に入って変わった2つのこと
権限管理をめぐる前提は、この1年で変わりました。人のアカウントだけを管理していれば足りる時代ではなくなっています。
| 傾向 | 内容 | 影響・リスク |
|---|---|---|
| 過剰権限のリスクは人より機械のIDに多い | AIエージェントやサービスアカウントなど非人間IDのリスク保有率は52%で、人間の37%を上回った（Tenable、2026年2月19日発表） | 侵入されたときの到達範囲が、人のアカウントより広くなりやすい |
| 公的な指針が最小権限に言及した | AI事業者ガイドライン第1.2版が、人の判断を介在させる仕組み（P.17）と操作ログの記録・保存（P.19〜20）を留意事項として記載（総務省・経済産業省、2026年3月31日）。AIエージェントに対する最小権限設定は、総務省の更新内容資料に挙げられている（総務省、2026年3月12日） | 社内規程や委託契約で、権限の範囲を説明できることが求められる |
OWASP GenAI Security Projectも、2026年版のLLMアプリ向けリスク一覧を公開し、AIエージェント向けのリスク一覧との対応づけを含めて、扱う脅威の範囲を広げています（OWASP GenAI LLM Top 10 2026（2026年8月3日））。権限の渡しすぎは、もはや例外的な失敗ではなく、頻出する型として扱われています。
【対策】AIに権限を渡す前に決める5つのこと
7件の事故は、業種も規模も違いますが、つまずき方は似ています。下の図の左が事故の起きた渡し方、右がそこから逆算した渡し方です。
1. 読み取り専用から始める
最初に渡すのは参照だけにします。書き込みや削除は、業務で必要だと分かった時点で、対象を絞って足します。Supabaseの事例では、サポートチケットの要約という用途に対し、MCPサーバーが高い権限のロールで動作していたことが、非公開テーブルの読み出しにつながりました。
実践ポイント：用途を1行で書き出し（例「サポートチケットを要約する」）、その1行に出てこない操作の権限は渡さないと決めます。判断に迷ったら、まず参照のみで1週間動かし、止まった作業だけを権限追加の候補にします。
なお、読み取り専用であっても、すべての情報を閲覧できる設定は避け、業務に必要なデータだけにアクセスできるよう制限することが重要です。
2. 検証環境と本番環境を分離し、バックアップを独立して保管する
AIエージェントに開発や検証作業を任せる場合は、検証環境での操作が本番環境に影響しない構成になっているかを確認することが重要です。
実践ポイント：検証環境と本番環境でストレージやデータベースのID・ボリュームが適切に分離され、一方の削除操作がもう一方に影響しないことを確認します。あわせて、AIエージェントに付与する権限を作業に必要な範囲に限定し、本番環境の削除や変更につながる操作を実行できないようにすることが有効です。
また、バックアップは本番データとは別の場所に保存し、本番環境を操作する権限では削除・変更できないように管理します。バックアップを取得するだけでなく、定期的に復元テストを実施し、必要な時点までデータを復旧できる状態を維持することも大切です。
AIエージェントが誤った操作を実行しても、影響が本番環境やバックアップに及ばない仕組みを整えることが、被害の拡大防止につながります。
3. 取り消せない操作にだけ、人の承認を挟む
すべてを承認制にすると運用が回りません。対象を「取り消せないもの」に絞ります。具体的には、削除、外部への送信、支払いの3つです。AI事業者ガイドライン第1.2版も、人の判断を適切に介在させる仕組みを留意事項に挙げています。
実践ポイント：承認を挟む操作の一覧を3行で作り、それ以外は自動で通します。AWSは事故後、本番環境へのアクセスに対して別の担当者によるレビューを必須にしたと公表しています。AIエージェントを設計する手順はAIエージェントの作り方でも解説しています。
4. AIに発行したトークンに、持ち主と期限をつける
トークンやAPIキーは、発行した時点で台帳に記録します。記録するのは、どのAIが使うか、誰が責任を持つか、いつ失効するかの3つです。期限を入れておけば、忘れられたトークンが生き続ける状態を防げます。
実践ポイント：非人間IDのリスク保有率が人間を上回るという調査結果（Tenable、2026年2月）を前提に、人のアカウントの棚卸しと同じ周期で、AI連携のトークンも見直します。棚卸しの初回は、使われていないトークンを止めるだけでも効果があります。
どこから手をつけるか迷う場合は、AIエージェントに渡す権限の範囲を一緒に設計するところからご相談いただけます。現在の環境を確認したうえで、最初に絞るべき権限を整理します。
5. 退職・異動で、AI連携の権限も止める
人事の手続きに、AI連携の停止を組み込みます。アカウントを無効にしただけでは、その人が発行したトークンは動いたままです。委託先との契約終了時も同じです。
実践ポイント：退職時のチェックリストに「本人が発行したトークンの失効」を1行足します。なお、削除したつもりでも残ることがあります。プルデンシャル生命保険では、退職時に登録情報を削除する運用を行っていたものの、削除した情報がサーバー内に論理的に残る製品仕様だったため、11,919名分の流出対象に退職者の情報が含まれていました（プルデンシャル生命保険、2025年6月20日公表）。運用で消したつもりの情報が実際に消えているかは、仕様まで確認する必要があります。
外部に開発を委託する場合は、同じ論点を発注前に確認します。確認項目はAI開発の外注先に確認すべきセキュリティ項目にまとめています。
スパイクスタジオの支援事例
スパイクスタジオは、株式会社Circloop様のシステム改修で、生成AIを全面的に活用しました。開発業務の80%以上をAIが担い、従来の約1.3倍のスピードで改修を完了しています（株式会社Circloop様の事例）。
開発の大半をAIが進める体制では、AIに渡す権限の範囲が、そのまま事故の大きさの上限になります。どの作業を自動で通し、どの操作で人が止めるかを工程の設計に組み込むことが、速度を落とさずに進めるための条件です。
AIエージェントの権限設計はスパイクスタジオへご相談ください
権限の線引きは、ツールを選ぶ前の設計の問題です。スパイクスタジオでは、次の2つのサービスでご支援しています。
- Spike AI Agent Studio：専任のエンジニアと開発AIがチームになり、月額定額でAIエージェントを作り続ける体制です。権限の範囲、承認を挟む操作、ログの残し方を設計に含めて進めます
- AIモダナイゼーション：AIが安全に触れる状態まで既存システムを作り直します。権限が役割ごとに分かれていない、ログが残らない、といった制約を抱えたまま自動化を急がないための選択肢です
「どこまでAIに任せてよいか決められない」「エージェントは導入したものの、権限設定の段階で止まっている」といった段階からで構いません。現在の環境と、止めたい事故の種類を伺ったうえで、最初の一手を整理します。