はじめに
AWS Bedrock は、基盤モデル（LLM）を企業の S3・Salesforce・SharePoint などのデータや Lambda 関数と直接連携させ、生成 AI アプリケーションを構築できるプラットフォームです。この「つながりやすさ」が生産性を高める一方で、モデルを取り巻く AWS リソースの権限設定が新たな攻撃面になります。
2026 年 3 月、XM Cyber の脅威リサーチチームが Bedrock 環境に潜む 8 つの攻撃ベクトルを公表しました。共通点は、いずれも LLM 本体の脆弱性ではなく、モデル周辺の IAM 権限・構成・連携を突くという点です。本記事は、この 8 ベクトルを「どの IAM アクションが起点になるか」という観点で整理し、自環境の IAM ポリシーで点検すべき権限を一覧化します。
- AWS Bedrock が攻撃対象になる理由と、OWASP Top 10 for LLM との対応関係
- 8 つの攻撃ベクトルそれぞれの起点となる IAM アクション（点検用の一覧表）
- データソース・エージェント・ガードレールを狙う攻撃の具体的なメカニズムと対策
- IAM 権限の点検手順と、GuardDuty による構成変更の検知方法
要点を先に述べます。8 ベクトルはいずれも過剰に付与された単一の IAM 権限（over-privileged identity）が起点であり、ログのリダイレクト・エージェントの乗っ取り・プロンプト汚染・オンプレミスへの横展開といった結果を招きます。防御の出発点は、どの AI ワークロードにどの権限が付いているかを把握し、bedrock:Update* や lambda:UpdateFunctionCode のような書き込み系 API を日常の運用ロールから分離することです。あわせて Amazon GuardDuty で構成変更を継続的に監視する体制が有効に働きます。
AWS Bedrock が攻撃対象になる理由
Bedrock で構築した AI エージェントは、Salesforce へのクエリ実行、Lambda 関数のトリガー、SharePoint ナレッジベースからのデータ抽出などを自律的に行います。つまりエージェントは、権限と到達性を持つインフラ内の 1 ノードとして機能します。攻撃者はモデルの推論精度ではなく、この「ノードとしての権限」を標的にします。
参考: We Found Eight Attack Vectors Inside AWS Bedrock. Here’s What Attackers Can Do with Them（XM Cyber / The Hacker News）
“attackers target the permissions, configurations, and integrations surrounding the model – not the model itself.”
（攻撃者はモデルそのものではなく、モデルを取り巻く権限、構成、連携を標的にする。）
https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html
単一の過剰権限が起点になる
XM Cyber の整理では、各攻撃ベクトルは低レベルの権限 1 つから始まり、そこを足場に機密データやオンプレミスの重要システムへ到達し得るとされています。単一の過剰権限があるだけで、攻撃者はログのリダイレクト、エージェントの乗っ取り、プロンプト汚染、あるいは Bedrock 内の足場からオンプレミスシステムへの到達を試みることが可能になります。「モデルは堅牢だから安全」という前提は成立せず、点検の対象は IAM ポリシーと周辺リソースの構成そのものになります。
OWASP Top 10 for LLM との関係
これらの脅威は、OWASP が定義する LLM アプリケーション向けのリスク分類「OWASP Top 10 for LLM Applications」と対応づけて整理できます。たとえばエージェントに不正な実行ツールを追加させる攻撃は「安全でない出力処理・過剰なエージェンシー」の系統に、ナレッジベース経由で認証情報が漏洩する脅威は「機密情報の漏洩」の系統に位置づけられます。AI 固有のリスク分類と AWS の標準的なセキュリティ対策を統合し、システム全体を俯瞰した設計が求められます。（各ベクトルと OWASP 項目の詳細な対応は後述の対策セクションで扱います。）
8 つの攻撃ベクトルと起点になる IAM 権限
ここでは 8 ベクトルの全体像を、起点となる主な IAM アクションとあわせて一覧化します。自環境の IAM ポリシーやロールで以下のアクションを誰が保持しているかを洗い出すことが、点検の第一歩になります。 各ベクトルの詳細なメカニズムと対策は次章以降で解説します。
| Vector | 攻撃の概要 | 起点となる主な IAM アクション |
|---|---|---|
| 1. モデル呼び出しログ攻撃 | ログの窃取・リダイレクト・削除による証拠隠蔽 | bedrock:PutModelInvocationLoggingConfiguration / s3:DeleteObject / logs:DeleteLogStream |
| 2. ナレッジベース攻撃（データソース） | S3 等からの生データ直接取得、SaaS 連携認証情報の窃取 | s3:GetObject / Secret の取得・復号権限 |
| 3. ナレッジベース攻撃（データストア） | ベクトル DB の endpoint・API キー取得による管理者アクセス | bedrock:GetKnowledgeBase |
| 4. エージェント攻撃（直接） | ベースプロンプト書き換え、不正な実行ツールの追加 | bedrock:UpdateAgent / bedrock:CreateAgent / bedrock:CreateAgentActionGroup |
| 5. エージェント攻撃（間接） | エージェントが使う Lambda への不正コード・依存の注入 | lambda:UpdateFunctionCode / lambda:PublishLayer |
| 6. フロー攻撃 | 不正ノード注入によるデータ経路の改ざん、暗号鍵の乗っ取り | bedrock:UpdateFlow |
| 7. ガードレール攻撃 | フィルターの弱体化・削除による防御層の無効化 | bedrock:UpdateGuardrail / bedrock:DeleteGuardrail |
| 8. マネージドプロンプト攻撃 | 共有プロンプトテンプレートへの悪意ある指示の注入 | bedrock:UpdatePrompt |
（出典: XM Cyber 脅威リサーチチームの分析。各アクション名は The Hacker News 掲載の一次情報に基づく。https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html ）
この表の書き込み系アクション（Update*・Create*・Delete*・Put*）は、いずれも日常的な推論利用（bedrock:InvokeModel 等）には不要です。運用ロールからこれらの構成変更系アクションを分離できているかが、8 ベクトル全体に共通する防御の核心になります。
データとナレッジベースを狙う攻撃と対策（Vector 1・2・3）
このセクションでは、AI が参照するデータ層とログ層への攻撃（Vector 1・2・3）を扱います。共通点は、モデルの推論を経由せず、背後の S3・ベクトル DB・ログ出力先へ直接到達する点です。
Vector 1: モデル呼び出しログの改ざん
Bedrock はモデルの呼び出し内容を CloudWatch Logs や S3 に出力できますが、その出力設定を書き換える権限（bedrock:PutModelInvocationLoggingConfiguration）を奪われると、攻撃者はログの出力先を自身の管理下に変更したり、無効化したりできます。さらに出力先 S3 のオブジェクト削除権限があれば、侵入の痕跡そのものを消去できます。
参考: We Found Eight Attack Vectors Inside AWS Bedrock. Here’s What Attackers Can Do with Them（XM Cyber / The Hacker News）
“Because prompt changes do not trigger application redeployment, the attacker can alter the AI’s behavior in-flight.”
（プロンプトの変更はアプリケーションの再デプロイを伴わないため、攻撃者は AI の挙動を実行中に変更できる。）
https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html
証拠となるログが消えると、フォレンジック調査が成立しなくなります。ログの出力設定変更（Put*）とログ格納先 S3 の削除権限を運用ロールから分離し、ログ用バケットにはオブジェクトロック（改ざん防止）を適用することが、他の全ベクトルの調査可能性を守る前提になります。
Vector 2・3: ナレッジベースを経由したデータ・認証情報の窃取
Bedrock のナレッジベースは、RAG を通じてモデルと S3・Salesforce・SharePoint・ベクトル DB を結びつけます。攻撃者はこの連携部分を狙います。データソース（Vector 2）側では、S3 の読み取り権限があればモデルを介さず生データを直接取得できます。
参考: We Found Eight Attack Vectors Inside AWS Bedrock. Here’s What Attackers Can Do with Them（XM Cyber / The Hacker News）
“an attacker with s3:GetObject access to a Knowledge Base data source can bypass the model entirely and pull raw data directly from the underlying bucket.”
（ナレッジベースのデータソースに対する s3:GetObject 権限を持つ攻撃者は、モデルを経由せず迂回して、背後のバケットから生データを直接取得できる。）
https://thehackernews.com/2026/03/we-found-eight-attack-vectors-inside.html
データストア（Vector 3）側では、bedrock:GetKnowledgeBase でナレッジベースの構成情報を取得すると、接続先ベクトル DB（Pinecone・Redis など）の endpoint や認証情報の在り処が判明します。これらの認証情報が窃取されると、攻撃者はデータストア全体への管理者アクセスを得て、Active Directory 等への横展開を試みる可能性があります。
対策として、ナレッジベースの S3 やベクトル DB への IAM アクセスは Bedrock のサービスロールのみに限定し、人間や他アプリケーションからの直接アクセスを最小権限で遮断することをおすすめします。 あわせて VPC エンドポイント（AWS PrivateLink）で Bedrock とデータストア間の通信をプライベート網に閉じ込め、インターネット経由の到達経路を排除する設計が有効です。SaaS 連携の認証情報は Secrets Manager で管理し、その取得・復号権限も同様に絞り込みます。
エージェント・フローを狙う攻撃と対策（Vector 4・5・6）
Bedrock のエージェントとフローは、入力に基づいて自律的にタスクを実行するオーケストレーターです。ここが侵害されると、AI ワークフロー自体が攻撃者の意図した処理を実行する経路になります。
Vector 4・5: エージェントの直接・間接的な改ざん
直接的な攻撃（Vector 4）では、エージェント構成の変更権限（bedrock:UpdateAgent など）を持つ攻撃者が、ベースプロンプトを書き換えたり、内部の指示やツールスキーマを漏洩させたり、悪意ある実行ツール（アクショングループ）を追加したりできます。
間接的な攻撃（Vector 5）はより検知が難しく、エージェントがタスク実行に使う Lambda 関数のコード自体（lambda:UpdateFunctionCode）や、依存レイヤー（lambda:PublishLayer）を改ざんします。Bedrock の構成上は正常に見えるため、エージェント定義の監査だけでは見落とします。
Vector 6: フローへの不正ノード注入
フロー（Vector 6）への攻撃では、bedrock:UpdateFlow を起点に、タスクの実行手順へ攻撃者が制御する不正な S3 ストレージノードや Lambda ノードが注入されます。アプリケーションの論理を壊さずに、機密性の高い入力データを攻撃者のエンドポイントへ静かにルーティングできる点が特徴です。あわせて KMS のキーポリシーが緩い場合、暗号化に使うキーを攻撃者のカスタマーマネージドキーへ差し替える乗っ取りも報告されています。
対策の核心は、AI エージェントが依存するインフラの変更権限を厳格に管理することです。 エージェントが呼び出す Lambda のコード更新権限やレイヤー公開権限は、開発者個人から切り離し、承認された CI/CD パイプライン（自動化ロール）のみに限定することをおすすめします。フロー機能では KMS のキーポリシーを絞り、意図しないキー差し替えを防ぐ設定が有効です。
ガードレールとプロンプトを狙う攻撃と対策（Vector 7・8）
Bedrock の安全性を担保するガードレール機能とマネージドプロンプトも、更新・削除権限の不備により無効化・汚染されるリスクを抱えます。
Vector 7: ガードレールの無効化
ガードレールは、有害コンテンツフィルターや PII マスキング、拒否トピックなどを担う防御層です。bedrock:UpdateGuardrail や bedrock:DeleteGuardrail を奪われると、フィルター強度を下げたりガードレール自体を削除したりして、防御層を静かに無効化できます。アプリケーション側のコードは無変更のため、通常の監視では気づきにくいのが難点です。
Vector 8: マネージドプロンプトの汚染
一元管理されるマネージドプロンプト（Managed Prompt）の更新権限（bedrock:UpdatePrompt）を奪われると、テンプレートに悪意ある指示（常に特定リンクを含める、PII 制限を無視する等）を注入され、AI の挙動が密かに操作されます。前掲のとおり、プロンプト変更は再デプロイを伴わないため、実行中に挙動が変わり、従来のアプリ監視での検知が困難です。
対策として、プロンプトやガードレールを更新する API（UpdatePrompt・UpdateGuardrail・DeleteGuardrail など）の実行権限を日常の運用ロールから切り離し、変更に承認プロセスを設けることをおすすめします。 これらの構成変更は後述の GuardDuty による検知対象にもなり、権限分離と監視の二層で守るのが有効です。
OWASP Top 10 for LLM（2025 年版）との対応
8 ベクトルを、AI アプリケーションのリスク分類である OWASP Top 10 for LLM Applications 2025 に対応づけると、フレームワーク横断で整理できます。なお 2025 年版は 2023-24 年版から項目が再編されており、旧版の番号とは対応が異なる点に注意が必要です。
参考: OWASP Top 10 for LLM Applications 2025（OWASP GenAI Security Project）
“LLM06: Excessive Agency … LLM07: System Prompt Leakage … LLM08: Vector and Embedding Weaknesses”
（LLM06: 過剰なエージェンシー、LLM07: システムプロンプトの漏洩、LLM08: ベクトルと埋め込みの脆弱性）
https://owasp.org/www-project-top-10-for-large-language-model-applications/
| Vector | 主に対応する OWASP Top 10 for LLM（2025） |
|---|---|
| 1. ログ改ざん | LLM04: データとモデルのポイズニング（証拠隠蔽・監査回避の側面） |
| 2. データソース窃取 | LLM02: 機密情報の漏洩 |
| 3. データストア窃取 | LLM08: ベクトルと埋め込みの脆弱性 |
| 4. エージェント直接改ざん | LLM06: 過剰なエージェンシー |
| 5. エージェント間接改ざん | LLM03: サプライチェーン ／ LLM06: 過剰なエージェンシー |
| 6. フロー改ざん | LLM06: 過剰なエージェンシー |
| 7. ガードレール無効化 | LLM01: プロンプトインジェクション（防御層の無効化） |
| 8. マネージドプロンプト汚染 | LLM07: システムプロンプトの漏洩 ／ LLM01: プロンプトインジェクション |
（OWASP 項目名は 2025 年版の公式定義に基づく。攻撃の主眼に応じた代表的な対応であり、複数項目にまたがるベクトルもある。）
この対応表により、既存の AI セキュリティプログラムを OWASP ベースで運用している場合でも、XM Cyber の 8 ベクトルを自組織のリスク台帳に紐づけて管理できます。
IAM 権限の点検と最小権限化の実務手順
ここまで見てきた 8 ベクトルは、いずれも特定の書き込み系 IAM アクションを起点とします。このセクションでは、自環境で「誰がそれらの権限を持つか」を洗い出し、運用ロールから分離するための具体的な手順を扱います。以下のコマンドは AWS 公式リファレンスで確認したものですが、実行前にご自身の環境の最新版 CLI で挙動を確認することをおすすめします。
点検の対象とする IAM アクション
第 1 節で示した一覧のうち、点検の優先度が高いのは構成をコード変更なしに書き換えられる次のアクション群です。外部のセキュリティ検証でも、これら 6 つの権限がエージェントの挙動書き換え・安全制御の削除・データ経路の変更を新規デプロイなしに可能にすると指摘されています。
参考: AWS Bedrock Security: Enterprise Hardening Guide（BeyondScale）
“Six IAM permissions (UpdateAgent, UpdatePrompt, UpdateGuardrail, DeleteGuardrail, CreateAgentActionGroup, and UpdateFlow) can rewrite agent behavior, remove safety controls, or redirect data without deploying new code.”
（UpdateAgent、UpdatePrompt、UpdateGuardrail、DeleteGuardrail、CreateAgentActionGroup、UpdateFlow の 6 つの IAM 権限は、新規コードをデプロイせずにエージェントの挙動書き換え・安全制御の削除・データのリダイレクトを可能にする。）
https://beyondscale.tech/blog/aws-bedrock-security-enterprise-guide
権限を保持する主体を洗い出す
まず、特定の Bedrock アクションを「誰が実行できるか」を IAM ポリシーシミュレーターで確認します。simulate-principal-policy は、指定した principal（ユーザーやロール）が特定アクションを許可されているかを評価する公式コマンドです。
# 特定ロールが Bedrock の構成変更系アクションを実行可能か評価する
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:role/YourRole \
--action-names \
"bedrock:UpdateAgent" \
"bedrock:UpdateGuardrail" \
"bedrock:DeleteGuardrail" \
"bedrock:UpdatePrompt" \
"bedrock:UpdateFlow" \
"bedrock:CreateAgentActionGroup"各アクションについて EvalDecision が allowed と返る principal が、点検対象です。ロールやユーザーを列挙する aws iam list-roles・aws iam list-users と組み合わせ、棚卸しを自動化できます。
参考: Test IAM policies and permissions with the IAM policy simulator（AWS re:Post）
“aws iam simulate-principal-policy –policy-source-arn arn:aws:iam::444455556666:user/USER –action-names …”
https://repost.aws/knowledge-center/iam-policy-simulator
使われていない権限を特定する
付与されているが実際には使われていない権限は、剥奪の第一候補です。IAM Access Analyzer の未使用アクセス分析（Unused Access Analyzer）は、ロールやユーザーの未使用の権限を継続的に検出します。
# 未使用アクセスを検出するアナライザーを作成（追跡期間 90 日）
aws accessanalyzer create-analyzer \
--type ACCOUNT_UNUSED_ACCESS \
--analyzer-name bedrock-unused-access \
--configuration '{"unusedAccess": {"unusedAccessAge": 90}}'あわせて、アクセスアドバイザー（service last accessed data）を使うと、あるロールが直近で Bedrock サービスにアクセスしたかを確認できます。90 日間 Bedrock を呼び出していないロールに bedrock:Update* が付いていれば、過剰権限の可能性が高いと判断できます。
参考: IAM Access Analyzer updates（AWS News Blog）
“a new analyzer that continuously monitors roles and users looking for permissions that are granted but not actually used.”
（付与されているが実際には使われていない権限を、ロールとユーザーについて継続的に監視する新しいアナライザー。）
https://aws.amazon.com/blogs/aws/iam-access-analyzer-updates-find-unused-access-check-policies-before-deployment/
構成変更系アクションを運用ロールから分離する
洗い出した書き込み系アクションは、日常の推論利用（bedrock:InvokeModel など）を担う運用ロールから切り離すことをおすすめします。分離の手段は主に次の 2 つです。
- SCP（サービスコントロールポリシー）: 組織単位で
bedrock:Update*・bedrock:Delete*などをガードレール的に制限し、承認された管理ロールのみ例外とする。 - 権限境界（permissions boundary）: 開発者個人のロールに上限を設定し、構成変更系アクションを境界外に置く。
Lambda を経由する間接攻撃（Vector 5）への対策として、lambda:UpdateFunctionCode や lambda:PublishLayer は開発者個人ではなく、承認された CI/CD パイプライン（自動化ロール）のみに限定することをおすすめします。「推論する権限」と「構成を変える権限」を別の主体に分けることが、8 ベクトル全体に効く共通の防御線になります。
GuardDuty による検知と監視
権限分離は攻撃の起点を減らしますが、万一の構成変更を検知する監視層も欠かせません。Amazon GuardDuty は、AI ワークロードに対する脅威検知に対応しています。
基礎脅威検知が捉える Bedrock の異常
GuardDuty を有効化すると、追加設定なしで CloudTrail 管理イベントを監視する基礎脅威検知が動作します。AWS 公式ドキュメントによると、この基礎検知は Bedrock を含む生成 AI ワークロードの疑わしい操作を検知対象とします。
参考: Protecting AI workloads with GuardDuty（Amazon GuardDuty ドキュメント）
“Unusual removal of Amazon Bedrock security guardrails / Change of model training data source that can potentially lead to data poisoning attack”
（Amazon Bedrock セキュリティガードレールの異常な削除／データポイズニング攻撃につながりうるモデル学習データソースの変更。）
https://docs.aws.amazon.com/guardduty/latest/ug/ai-protection.html
ガードレールの異常な削除は Vector 7、学習データソースの変更は Vector 1・2 に対応します。つまり GuardDuty の基礎検知だけでも、複数ベクトルの兆候を捉えられます。
Extended Threat Detection による多段攻撃の相関検知
GuardDuty の Extended Threat Detection は、単体では脅威と判断しにくい複数のイベントを、時系列で相関させて「攻撃シーケンス」として検知します。この機能は GuardDuty を有効化すると追加費用なしで自動的に有効になり、利用に別途料金は発生しません。XM Cyber が指摘する「単一の過剰権限を起点にした横展開」というシナリオは、まさにこの多段検知が対象とする挙動です。
ただし制約があります。S3 Protection を有効にしないと、GuardDuty は S3 が関与する攻撃シーケンスを十分に検知できません。 ナレッジベースの背後にある S3（Vector 2）を守るには、S3 Protection の有効化をあわせて検討することをおすすめします。
デフォルトで記録されないログに注意
監視を機能させる前提として、Bedrock のログ設定には見落としやすい既定の挙動があります。外部の技術検証によると、モデル呼び出しログはデフォルトで無効で、PutModelInvocationLoggingConfiguration を呼び出して有効化する必要があります。さらに、エージェント実行時の操作（InvokeAgent・Retrieve・InvokeFlow など）は CloudTrail の管理イベントではなくデータイベント扱いのため、既定では記録されません。
参考: AWS Bedrock Security: Enterprise Hardening Guide（BeyondScale）
“InvokeAgent, Retrieve, RetrieveAndGenerate, InvokeFlow, and RenderPrompt are data events. They are not logged by default.”
（InvokeAgent、Retrieve、RetrieveAndGenerate、InvokeFlow、RenderPrompt はデータイベントであり、デフォルトでは記録されない。）
https://beyondscale.tech/blog/aws-bedrock-security-enterprise-guide
エージェントやフローの挙動を追跡するには、CloudTrail で対象リソースタイプ（AWS::Bedrock::AgentAlias など）のデータイベントを明示的に有効化する設定が必要です。 この設定を怠ると、Vector 4・5・6 の実行時挙動がログに残らず、GuardDuty や事後調査の材料が得られません。監視体制を整える際は、まずログが記録される状態になっているかを確認することをおすすめします。
まとめ
AWS Bedrock を狙う 8 つの攻撃ベクトルは、モデル本体ではなく周辺の IAM 権限・構成・連携を起点とします。防御の要は、構成変更系の書き込み権限を運用ロールから分離し、GuardDuty と CloudTrail で変更を監視することにあります。以下に本記事の要点を整理します。
- 攻撃の起点は過剰に付与された単一の IAM 権限
- 8 ベクトルはいずれも書き込み系アクションから始まる
- ナレッジベースの S3 やベクトル DB はサービスロールのみに限定
- Lambda のコード更新権限は CI/CD ロールに限定
- ガードレールとプロンプトの更新 API は運用ロールから分離
- GuardDuty はガードレール削除や学習データ変更を検知
- エージェント実行ログはデータイベントの明示的な有効化が前提
以上、最後までお読みいただきありがとうございました。
