re:Invent 2025 で押さえるべき「生成AIセキュリティ」アップデート整理

🧩 この記事でわかること

• re:Invent 2025 は 「エージェント × セキュリティ」 が強く打ち出された年だった
• 特に以下3つが、生成AIシステムの「安全な本番運用」に直結する

1. Amazon Bedrock AgentCore Policy / Evaluations

2. AWS Security Agent（セキュリティ専用フロンティアエージェント）

3. S3 Vectors など、RAG基盤のセキュア化につながるデータ系アップデート

1. Amazon Bedrock AgentCore Policy / Evaluations

―「エージェントに何をさせてよいか」をポリシーで固める

1-1. Policy 機能：エージェントの権限を Cedar で制御

re:Invent 2025 で、Amazon Bedrock AgentCore に Policy 機能（プレビュー） が追加されました。

ポイントは：

• Cedar などのポリシー言語で
• 「誰が (principal)」
• 「どのエージェント／どのツールに対して (resource)」
• 「どの操作を許可／拒否するか (action)」

を厳密に定義できる

• 「このエージェントは “読み取り専用のRAG検索” だけ 許可」

「このユーザロールでは 顧客PIIを含むインデックスには到達不可」

のような制御がコードではなく ポリシーとして一元管理 できる

「危険なツール呼び出しの制御」を、Bedrock標準機能としてデザインできるようになりつつあります。

1-2. AgentCore Evaluations：エージェントのふるまいを継続評価

同時に AgentCore Evaluations も発表され、エージェントの動作ログをもとに、以下のような尺度でスコアリングできるようになりました。

• タスク達成度
• 応答の有用性・正確性
• 有害性 / セキュリティ違反の有無（攻撃的・不適切・ポリシー違反など）

これにより、

• 「このエージェントは、どのくらいの確率で危険な出力をするのか？」
• 「特定のツール呼び出しパスで、失敗やポリシー違反が多発していないか？」

を定量的にトラッキングできます。CloudWatch や GenAI Observability との連携により、メトリクス / トレースベースで監視可能な点も大きいです。

Securing AI with AWS

Build trusted generative AI applications with Amazon Bedrock

aws.amazon.com

1-3. 実務的な示唆

• 「エージェントPoCが動いたので、そのまま本番へ」ではなく、
• Policy で権限境界を固める
• Evaluations で “安全性と品質の振る舞い” を見ながら SLO を設計する
• RBAC/RAGガバナンス（Day15）で決めたルールを、AgentCore Policy に落とし込む イメージ

2. AWS Security Agent

―「AIでAIを攻める」アプリケーションセキュリティ

2-1. 概要：設計〜コード〜ペンテストまで“AIセキュリティ担当”

re:Invent 2025 では、AWS Security Agent が新サービスとして発表されました（プレビュー）。

公式ブログによると、Security Agent は以下のような特徴を持つ セキュリティ専用フロンティアエージェント です。

https://aws.amazon.com/jp/blogs/aws/new-aws-security-agent-secures-applications-proactively-from-design-to-deployment-preview/

• アプリケーションのライフサイクル全体（設計・コード・インフラ）を通じて セキュリティリスクを自動的に洗い出し・改善案を提示
• 具体的には：
• 設計レビュー：アーキ図や要件からセキュリティ要件抜けを指摘
• コードレビュー：CI/CD と連携し、脆弱なコードパターンを検出
• ペネトレーションテストの補助：脆弱なエンドポイント候補を提示
• 結果を Security Hub など既存のセキュリティ基盤と連携

生成AIを使ってアプリを作るだけではなく、生成AIを使って“アプリとそのAI機能を攻めさせる” という立ち位置になっています。

2-2. 生成AIセキュリティへの効きどころ

Security Agent 自体は「LLM専用ツール」というより、アプリ全体のセキュリティ向けですが、次のような点で、生成AI機能にかなり効きます。

• プロンプトインジェクションの入り口になりがちな Web エンドポイントの設計漏れを早期に発見
• LLM アプリ側の認可抜け・入力バリデーション不足をコードレビューで指摘
• Bedrock や S3 Vectors、RAG 構成の誤設定などを、

セキュリティベストプラクティスに基づいて検査

「AI機能だけ単体で守る」のではなく、アプリ全体のセキュリティ診断フローの中に、生成AI機能も組み込まれていくイメージです。

2-3. 実務的な示唆

• これまで「アプリケーションセキュリティ」と「生成AIセキュリティ」を分けて考えていた組織にとって、両方を一気通貫でレビューできる“入口” になり得る
• プロジェクトとしては
• まずは Security Agent を 既存のCI/CD や Security Hub と連携して試す
• その後、生成AI機能を含むアプリを流し込んでベースラインを作る
• LLMレッドチーミングを 半自動化する相棒としても検討価値あり

3. S3 Vectors と周辺アップデート

―「RAG基盤をセキュアかつ運用可能にする」方向性

3-1. S3 Vectors GA：“S3ネイティブのベクトルストア”

re:Invent 2025 では、S3 Vectors が GA（正式リリース）とされ、東京リージョンでも利用可能になりました。

S3 Vectors は、ざっくり言うと：

• Amazon S3 上に ネイティブなベクトル検索機能 を統合したサービス
• RAG 用のベクトルストアを、S3 の
• IAM
• 暗号化
• バケットポリシー
• アクセスポイント

といった既存のセキュリティ機構の上で運用できる

これにより、

• 「RAGだけ別ベンダーのベクトルDBを立てる → セキュリティ/運用がバラバラ」
• 「S3のアクセス制御とベクトルDBのACLが二重管理でつらい」

といった課題を、かなり軽減できます。

3-2. GuardDuty / Security Hub / CloudWatch との組み合わせ

同じく re:Invent 2025 では、

• GuardDuty Extended Threat Detection for ECS/EC2 グループ
• 新しい Security Hub の GA`
• CloudWatch のユニファイドデータストア（ログ基盤強化）

といったアップデートも発表されています。

これら自体は「生成AI専用」ではないものの、

• S3 Vectors や Bedrock を利用した RAG/エージェントの実行ログ を CloudWatch に集約
• Security Agent / GuardDuty / Security Hub と組み合わせて RAG まわりの挙動や権限逸脱を検知・集約
• Day20 で述べたような LLM可観測性 / SIEM連携 を、AWS内で完結させやすくなる

という意味で、生成AIセキュリティ運用の“インフラ層” として重要です。

3-3. 実務的な示唆

• RAG を AWS 上で組むなら：
• ベクトルストア：S3 Vectors
• アクセス制御：IAM / バケットポリシー / AgentCore Policy
• 可観測性：CloudWatch + GenAI Observability
• セキュリティモニタリング：GuardDuty / Security Hub / Security Agent

という形で、「フルスタックAWSで閉じる」構成をかなり現実的に描けるようになった

📌 次の一手（社内でやるべきこと）

この記事を読んだあと、実務担当としては例えば以下のようなステップが現実的です。

4. ### 自社ユースケースを棚卸し

5. 既に or 検討中の Bedrock / RAG / エージェント案件をリストアップ

6. ### 「どこでポリシーを効かせるか」を構想

7. RAGの権限、Agentが叩くツール、外部API などを洗い出し

8. AgentCore Policy / IAM / RBAC のどこに境界線を引くかを検討

9. ### Security Agent / GenAI Observability の PoC

10. 既存アプリの一部を対象に、「AIでAIを攻める」診断フロー

を試してみる

11. ### S3 Vectors 前提のRAGリファレンス構成を描く

12. S3 Vectors + GuardDuty + Security Hub でどう実現するかスケッチする