はじめに

2025年は AI Agent にとってパラダイムシフトとも言える圧倒的な進化・浸透となった一年でした。
非常に便利な AI Agent ですが、セキュリティの観点では考慮すべきことがあります。
このブログでは、What’s AI Agents のおさらいから、そこで生まれる新たなセキュリティリスク、AWS機能を活用したその対策について触れてみたいと思います。

AI Agent の特徴

私はよくこの説明に、副操縦士から優秀な新入社員への変化と例えます。
これまでの AI（例えば初期の Amazon CodeWhisperer など）は、コーディングでの入力補完や、膨大なドキュメントの要約、翻訳など、自身の作業を補助する役割でした。 一方、現在の AI Agent は、目的を指定することで、その達成のために Action Group（API 呼び出しなどのツール）を活用しながら目的達成の道筋を自律的に立てます。また、Chain of Thought（思考の連鎖）によりツール使用の結果を自ら振り返り、必要に応じて試行錯誤を繰り返します。
ただし、完全に放置しておくだけで勝手にあなたの仕事を完遂してくれるわけではありません。正しい指示（インプット）を与える必要があります。やってはダメなことも Guardrails で伝える必要があります。 LLM の驚異的な進化に伴って、プロンプトの理解力が飛躍的に向上している今も変わりはありません。例えるなら、超優秀なスペックを持った新入社員のようなものです。

用途が変われば、アーキテクチャも変わります。 従来のアーキテクチャが線形処理だったのに対し、AI Agentはループ型の処理をとることが一般的です。ループ処理を行うためにオーケストレーション処理や記憶領域が必要になります。AWS ではこれを Amazon Bedrock Agents がマネージドで担います。

これらの用途やアーキテクチャの変更の違いに伴って、新たなリスクも発生しています。

AI Agent のリスク

従来の AI リスクは、AI システムを直接的に攻撃してくるものでした。一方、AI Agent でのリスクは、Agent を介して、システムや組織の脆弱性を突くことができてしまうようになります。

いくつか、具体的なリスクについても簡単に解説しておきます。

間接的プロンプトインジェクション

プロンプトインジェクションとは、悪意あるユーザーが、AIに直接悪意のある指示（プロンプト）を与えるものでした。
一方、間接的プロンプトインジェクションでは、ユーザー自身は悪意がないまま、プロンプトを介して被害に遭います。例えば、「このWebサイトの記事を要約して」という指示をするように仕向けます。このサイトには人間が視認できないほどの小さな文字や透明な文字でインジェクションが埋め込まれています。それにより、エージェントが持つ権限を使ってユーザーの認証情報などが盗まれることもあり得ます。

混乱した権限管理（Confused Deputy）

AI Agent を作成する場合は、一人だけで利用するものは稀です。大体は複数名で利用します。それぞれの人には IAM 権限がまちまちです。 エージェントはその最大値の権限（Execution Role）で振る舞える必要があります。しかしながら、そのエージェントを利用する人が持つ権限を超える動きはしてはなりません。 エージェントの利用時に、利用者の権限を引き継いで振る舞う必要があります。 例えば、DynamoDB の人事テーブルにアクセスできる社員がエージェントを利用する際は参照してもいいが、そうでなければ参照しないようにするべきです。

メモリポイズニング

AI Agent のアーキテクチャの特徴であるループ処理の実現にあたっては、メモリが利用されます。
このリスクは、これらのメモリ領域（RAG ソース）を活用した攻撃です。 攻撃者はドキュメントソースに悪意ある指示を潜ませておくことで、時限爆弾のように設置（仕込み）と爆発（被害の発生）のタイミングをずらすことができます。 こうすることで、CloudTrail のログを追っても原因究明の難解化を図ることもできます。
AWS においては、Knowledge Bases for Amazon Bedrock のデータソースに仕込まれることが想定されます。

AI Agents のリスク対策

これらのリスクに対して、AWS 環境におけるいくつかの対策案を挙げておきます。

HITL ワークフロー

現時点では、最も重要な考え方の一つです。
Human In The Loop というもので、AI に完全な自己完結を委ねるのではなく、重要な操作の際は必ず人間の承認を挟むようにします。 Amazon Bedrock Agents では、アクション実行前にユーザーに確認を求めるフローを組み込むことが可能です。 これは、人間だけでの作業でも同じです。重要な本番環境への変更作業を、一人の作業者が全て単独で進めることは危険です。
ただ、何でもかんでも HITL とするのは、個人的には反対です。AI Agent の価値が半減します。AWS Step Functions の承認フローのように、どこに HITL を確実に適用するかが、今後の鍵になってくると考えます。

OBO 認証と JIT アクセス

エージェント自身の権限（サービスアカウント）でなく、エージェント利用者の ID に基づいてエージェントが振る舞うようにします。 また、権限は永続的に持たせるのではなく、一時的（Just In Time）であるべきです。
AWS IAM Identity Center と連携した Trusted Identity Propagation の仕組みを使うことで、Amazon Bedrock Agents はこの ID 伝播に対応できますがソースにメタデータを付与しフィルタリングを実装する必要があります。
Amazon Q Business では利用者の権限に合わせた合わせた振る舞いをサービス側で提供しています。

入出力のサニタイズ（Guardrails）

AI Agent のセキュリティ対策においても、多層防御は有効です。 プロンプトインジェクションの検出、PII（個人情報）のマスキング、不適切なコンテンツのフィルタリングを、LLM の呼び出し前後で強制的に適用します。これにより、LLM が解釈する前、あるいはツールを実行する前にリスクを低減できます。
AWS では Guardrails for Amazon Bedrock がこの役割を担います。

サンドボックス化

こちらも、セキュリティ対策としてはレガシーな種類ですが、AI Agent においても非常に効果的です。 AI Agent がコードを実行したり、ツールを使用する環境は、AWS Lambda や AWS Fargate 上で動作させることが一般的です。これらは Firecracker マイクロ VM 技術によって強力に隔離されています。意図しない暴走を行った時も、被害を局所化できるように設計しておきたいです。

IDEsaster

最後に、IDEsaster にも触れておきます。 Amazon Q Developer (in IDE) など、最近多くの AI Agent を搭載した IDE が利用されていますが、調査レポートによれば、その調査対象となった多くの IDE 拡張機能に脆弱性が見つかったというものです。IDE + Disaster（災害）の造語です。 これらは、従来は人間がタイピングすることで利用することを前提に設計されてきた IDE に対し、自律的に振る舞う AI Agent を搭載することによって、これまでなかった脆弱性が確認できたというものになります。

例えるなら住居に泥棒するために、これまでは外からドアを破壊するような直接的な AI 自体への突破（プロンプトインジェクションなど）を試みることに対し、IDEsaster では住人を騙すことで、中から鍵を開けさせるような攻撃が発見されたようなものです。
IDEsaster が怖いところとしては、一見、なんともなさそうな README の閲覧だけでも、被害が発生する可能性があるところです。さらに、その際に、IDE のグローバル設定（~/.aws/credentials や .ssh など）を読み取られたり書き換えられることで、永続化や水平展開も行われてしまいかねません。
IDEsaster 対策としては、Amazon CodeCatalyst のようなリモート開発環境（Dev Environments）を利用し、ローカルマシンから切り離されたコンテナ環境で開発することが有効策の一つです。また、確実に問題のないリポジトリや信頼できる AWS パートナーのツール利用を徹底する必要があります。 さらなる対策として、AI Agent 自身に攻撃の検知や防御をさせるだけでなく、攻撃のシミュレート（Red Teaming）をすることも提唱されています。
Amazon Q Developer には、セキュリティスキャン機能や、コード変換時の安全性確保機能があるので、積極的に活用しましょう。 ローカル端末のファイル消失事故なども、コンテナベースのリモート開発環境（Dev Environments）で動かしていれば防げた可能性が高いです。

まとめ

AI Agent がもたらすものは発展か破壊か？
私は、前者と考えます。 善人が使わなくとも、悪人は AI Agent を悪用して、攻撃の複雑化をしてきます。これは断言できます。この速度には、従来のやり方だけでは追いつけません。 我々は、AI Agent を正しく安全に活用して、立ち向かう必要があります。
しかしながら、現時点では完全な安全を保証できる銀の弾丸はありません。責任共有モデル（Shared Responsibility Model）に基づき、リスクを把握しながら対処していく必要があります。 AWS には、Amazon Bedrock Agents や Guardrails、IAM Identity Center のような、Agent 開発・運用をセキュアにサポートしてくれる基盤が提供されています。これらには、本文でも紹介した機能以外にも、CloudTrail によるトレーサビリティや多段防御を補助する仕組みが提供されます。

本ブログが安全な AI Agent 利用の促進に一役立てばこれ幸い。