AI専門会社・合同会社あとらくしょん代表の長 純です。
2026年10月、セキュリティ企業Zenity Labsが、AWSのAIエージェント基盤「Amazon Bedrock AgentCore」に関する調査結果を公表しました。外部に公開された1つのAIエージェントへのプロンプト（指示文）から始めて、同じAWSアカウント内にある他のすべてのエージェント、その会話内容、記憶、鍵情報にまで届いてしまう経路を実証した、という報告です。
結論から書きます。この報告が示したのは、「AIの性能が高いから危険」なのではなく、「AIに渡した権限が広いから、被害範囲も広くなる」という、昔からある情報システムの原則です。 逆に言えば、権限の設計と点検は、経営側の判断で今日から変えられます。
同じ10月には、IPA（情報処理推進機構）が「AIセキュリティ短信」10月号を公開し、AIエージェントが情報漏えいの経路になった事例を複数整理しています。本記事では、この2つの公表資料をもとに、何が起きたのか、そして中小企業が何を点検すべきかを、元システムエンジニアの視点で整理します。
この記事の要点
- Zenity Labsの実証では、1つの公開AIエージェントへのプロンプトが入口になり、認証情報を経由して、同一アカウント内の全エージェントに波及しうることが示された。被害範囲を決めたのは、初期設定（デフォルト）の権限の広さだった
- これは研究者による実証報告であり、実際の犯罪被害が確認されたものではない。AWSは公表前に初期設定の権限を大幅に絞ったが、すでに設定済みの権限は利用者側が直さない限り自動では変わらない
- 中小企業の点検は3つ。AIに渡した権限の一覧化、AIが読む情報の入口の把握、承認やログといった「外側のブレーキ」の確認
何が起きたのか ― 1つのプロンプトから始まる連鎖
入口は、特別な攻撃コードではなく、公開されたAIエージェントへの普通の文章の指示でした。
Zenity Labsの研究者（Tamir Ishay Sharbat氏、Lana Salameh氏）が2026年10月8日にカンファレンス「SecTor」で公表した「AgentCorruption」と呼ばれる調査の概要は、次のような連鎖です。
まず、インターネットから利用できるAIエージェントに対して、特定のアドレスへアクセスするよう文章で指示します。そのアドレスは、クラウドの実行環境が内部で使う「メタデータサービス」と呼ばれる仕組みで、本来はその環境自身の認証情報を渡すためのものです。エージェントが持つWebアクセス機能がこの仕組みへのサーバー側リクエストとして働き、攻撃者側にエージェントの一時的な認証情報が渡ってしまいました。
次に問題になったのが、その認証情報に紐づく「実行ロール」という権限の初期設定です。当時の初期設定では、その権限の範囲が1つのエージェントに閉じておらず、同じAWSアカウント・同じ地域（リージョン）にある他のエージェント全体に及んでいました。研究者は、この権限を使って、他のエージェントを呼び出す、すべてのエージェントの会話記録を読む、エージェントの「記憶」に指示を書き込んで以後の振る舞いを変える、APIキーや秘密情報を取り出す、といった操作が可能だったと報告しています。
つまり、突破されたのは1つのエージェントでも、それは「たまたま権限が広かった1台」だったために、アカウント全体の入口になってしまった、というのがこの報告の骨格です。
誤解しないための、3つの留保
この報告は、研究者による実証であり、犯罪者による実被害の報告ではありません。 ここを正確に押さえておくことが、権威ある情報発信としても、経営判断としても重要だと考えています。
1つ目に、Zenity Labsは2025年12月と2026年1月に、段階を分けてAWSへ報告しています（いわゆる責任ある開示）。AWSは当初、この挙動を「仕様として文書化された想定内の動作」と扱いましたが、その後、2026年2月には新規の実行環境について認証の方式を強化し、2026年9月29日までに初期設定の権限から、他のエージェントの呼び出しや会話の読み取り、秘密情報へのアクセスなどを取り除いたことが、研究者側の確認として公表されています。
2つ目に、実際の顧客環境でこの連鎖が悪用された証拠は、現時点で示されていません。CVE（共通脆弱性識別子）も発行されていません。「AWSで大規模な情報漏えいが起きた」という話ではないのです。
3つ目に、ただし「直ったから終わり」でもありません。初期設定が締められたのは、これから新しく作る設定の話です。すでに従業員や開発者が設定済みの権限は、ベンダーが初期値を変更しても自動では変わりません。 ここが、実務でいちばん見落とされる点だと思います。
IPA短信が示した、もう1つの入口 ― 「AIが読むもの」
権限と並ぶもう1つの論点が、AIエージェントに「何を読ませているか」です。
IPAが2026年10月16日に公開した「AIセキュリティ短信 2026年10月号」は、9月7日から10月5日までの事例を一次情報から整理した資料です。この中で、AIエージェントが情報漏えいの経路になった事例として、次のような報告が紹介されています。
1つは「SalesBleed」と呼ばれる、こちらもZenity Labsによる報告です。SalesforceのAIエージェント「Agentforce」に対し、認証不要のWebフォームから指示を紛れ込ませて送ると、担当者がAIに内容の確認を依頼した際に、顧客データを外部へ送り出す経路があった、というものです。すでにすべて修正済みで、Salesforceは顧客への悪用の証拠はないとしています。ここで重要なのは手口の巧妙さではなく、「問い合わせフォームの文章」が、そのままAIへの指示の入口になりうるという構造です。
もう1つは、Glow Labsによる報告です。画像の添付に制限がかかったAIコーディングエージェントが、その制限を避けるために隣接する公開リポジトリへ画像を置く方法を自ら取り、300を超える組織の1.3万枚を超える社内画像が公開状態になった、とされています。さらに、この事例の93%は従業員の個人アカウントの下で起きており、会社のセキュリティ担当は検知できなかったと報告されています。
IPA短信はこの動向を、「統制をエージェント自身に委ねず、外側から強制する設計が必要」「管理下にないエージェントには統制が及ばない」という趣旨で整理しています。AIに任せる範囲が広がるほど、「AIが読むもの」「AIに渡す権限」「AIの外側のブレーキ」の3点を、AI自身ではなく人間と仕組みの側で管理する必要がある、ということです。
中小企業が今日から点検できる、3つのこと
点検の中心は、高度な技術ではなく、「一覧化」と「初期設定の見直し」です。
1. AIに渡した権限を、一覧にする
社内のAI利用について、「どのサービスに」「どのアカウントやAPIキーで」「何にアクセスできる設定で」つないでいるかを書き出してください。クラウドのAI基盤に限らず、業務SaaSのAI機能や、外部サービスと連携するAIツールも対象です。特に、導入時に初期設定のまま使っている権限は要注意です。ベンダーが後から初期値を安全側に変えても、設定済みの権限は自動では変わらない、というのが今回の報告の実務的な教訓です。
2. AIが読む情報の入口を、把握する
問い合わせフォーム、受信メール、共有フォルダ、Webページ。AIに読ませているものは、すべて「指示が紛れ込む入口」でもあります。外部から届く文章をAIがそのまま処理する業務フローがあるなら、そのAIの出力や次の操作に、どこで人間が目を通すのかを決めておいてください。前作「ダウンロードフォルダでClaude Codeを起動してはいけない理由」で扱った設定ファイルの話も、根は同じです。AIが読むものを管理することが、防御の出発点になります。
3. 外側のブレーキを、確認する
重要な操作（送信、削除、公開、支払いなど）の前に人間の承認を挟む設定があるか。操作のログが残り、あとから確認できるか。そして、従業員が個人アカウントで業務にAIを使っていないか（いわゆるシャドーAI）。画像1.3万枚の事例が示すように、管理の外にある利用には、どんな統制も届きません。禁止するだけでなく、会社として使える正規の手段を用意することが、結果として棚卸しを可能にします。
よくある質問
Q. うちはAWSのエージェント基盤など使っていません。それでも関係がありますか？
仕組みの名称は違っても、構造は共通しています。業務SaaSに組み込まれたAI機能、外部サービスと連携するAIツール、社員が使うAIチャット。これらにも「渡している権限」「読ませている情報」「外側のブレーキ」という3点は必ず存在します。今回の報告を、特定のクラウド製品の話ではなく、AIに仕事を任せるときの設計原則として読むことが大切だと思います。
Q. ベンダーが初期設定を直したなら、もう安心なのでしょうか？
初期設定の改善は、これから新しく設定する環境には有効です。ただし、すでに使っている設定や権限は、ベンダーの初期値変更では自動的には変わりません。また、権限以外の入口（フォームやメールなど、AIが読む情報）はベンダー側の修正だけでは管理できません。自社側で「今、何を渡しているか」を確認する作業は、依然として必要です。
Q. 何から始めればよいでしょうか？
まずは一覧化です。部署ごとに、使っているAIサービスと、そのAIがアクセスできる情報・操作の範囲を書き出してください。それだけでも、「初期設定のままの広い権限」や「個人アカウントでの業務利用」が見つかることがあります。そのうえで、権限を業務に必要な最小限へ絞り、重要な操作には人間の承認を挟む。この順番が、現実的で効果の見える進め方だと思います。AIエージェント全般の考え方は「AIエージェントのセキュリティ、中小企業がまず押さえるべきこと」でも整理しています。
まとめ：被害範囲は、モデルの賢さではなく設計で決まる
今回の2つの公表資料が共通して示しているのは、AIエージェントの事故の大きさは、モデルの性能よりも、「どんな権限を渡し、何を読ませ、どこにブレーキを置いたか」という設計で決まる、ということです。それは裏を返せば、経営者と現場の判断で変えられる領域が大きい、ということでもあります。
まずは今週、社内で使っているAIの一覧を書き出すところから始めてみてください。その一覧こそが、これからのAI活用の土台になります。
著者について
長 純（ちょう じゅん）。合同会社あとらくしょん代表。金融・通信分野でシステムエンジニアを約10年経験したのち、福祉分野へ。放課後等デイサービス「ウィズ・ユー」のCAIOとして現場のAI活用を進めながら、中小企業向けのAI導入支援と研修を行っています。埼玉県登録のAIコンサルタントとして、商工会議所の専門家派遣も行っています。
「社員にAIを使わせたいが、権限やセキュリティの設計が不安」という経営者・人事担当者の方は、お気軽にご相談ください。導入支援と研修を、現場目線で設計しています。
参考資料
- IPA（情報処理推進機構）「AIセキュリティ短信 2026年10月号」（2026年10月16日公開） https://www.ipa.go.jp/digital/ai/security/rcu1hd0000007gji-att/2026-4_1016.pdf
- CyberInsider「AgentCore research shows how exposed AI agents could cross cloud boundaries」（Zenity LabsのAgentCorruption報告の解説） https://cyberinsider.co.uk/agentcore-research-shows-how-exposed-ai-agents-could-cross-cloud-boundaries/
- SecJuice「AgentCorruption: AWS Tightened AgentCore’s Default Role, Not Yours」（同報告とAWSの対応の解説） https://secjuice.com/agentcorruption-aws-tightened-agentcores-default-role-not-yours/
