LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AIエージェントのセキュリティとは、出力ではなく行動を守る対策

AIエージェントのセキュリティとは、AIエージェント(自律的に判断し外部システムのツールやAPIを呼び出して行動するAI)が実行するツール操作・API呼び出しを、権限の範囲・承認・記録の面から制御する対策を指します。OWASPは「Top 10 for LLM Applications」2025年版で、このリスクをLLM06「過剰な代理行為(Excessive Agency)」に位置づけています^*1。

生成AIの安全対策と聞くと、不適切な出力や機密情報の漏えいを防ぐ話を思い浮かべる方も多いでしょう。本稿が扱うのはそれとは別の領域です。AIエージェントが自律的に実行するツール操作・API呼び出しという「行動」そのものを対象にします。

AIエージェントは、指示を理解して結論を出すだけでなく、社内システムやSaaSのツールを呼び出して結果を反映するところまでを担います。ツールを実行する力を持つからこそ、想定外の操作や乗っ取りが起きた場合の影響は、通常の生成AI利用より大きくなりやすいです^*1。

次章からこの行動リスクをOWASPの分類に沿って整理し、権限設計・承認ゲート・認可・監査ログという4つの観点で対策を見ていきます。

OWASPのExcessive Agency——機能・権限・自律性が生む3つの過剰

OWASP(Open Worldwide Application Security Project。Webアプリケーションセキュリティを扱う国際的な非営利団体)は、AIエージェントに与える自律性そのものがリスクの発生源になり得ると整理しています^*1。過剰な代理行為(Excessive Agency)は、機能・権限・自律性という3つの過剰に分けて説明されています^*1。

過剰な機能——不要な操作までツールに持たせてしまう

1つ目は過剰な機能です。読み取りだけで十分な業務に対し、文書の削除まで実行できるプラグインを選んでしまう例がOWASPの説明に挙げられています^*1。エージェントに持たせる機能は、業務上必要な範囲に絞り込む発想が前提になります^*1。

過剰な権限——ツールの先にあるシステム側の権限が広すぎる

2つ目は過剰な権限です。データベースへの参照だけで足りる場面で、更新・削除の権限を持つ認証情報をツールに与えてしまう例が挙げられています^*1。ツール自体の機能を絞っても、接続先システムの権限設定が広いままでは同じリスクが残ります^*1。

過剰な自律性——重要操作の前に人の確認を挟まない

3つ目は過剰な自律性です。利用者の文書を削除するような影響の大きい操作を、確認なしにエージェント単独で実行させてしまう状態を指します^*1。OWASPが示す代表例は、メールの読み取りと送信の両方に対応したプラグインを持つ個人アシスタントです^*1。

間接プロンプトインジェクション(外部の文書やメールにAIへの指示を埋め込む攻撃手口)によって、機密メールを攻撃者へ転送させられる恐れがあると説明されています^*1。この事例は3つの過剰が重なったときに実害へつながることを示す例です^*1。機能・権限・自律性のどれか一つだけを対策しても、抜け道が残る可能性があります。

権限を絞る設計——機能とアクセス権をタスクの最小限にする

OWASPは過剰な代理行為への対策として、拡張機能とその権限を必要最小限にすることを推奨しています^*1。これは心構えの話ではなく、クラウド側の権限管理機能に落とし込める具体的な設計事項です^*1。

AWSの例——サービスロールとLambdaのリソースベースポリシー

Amazon Bedrock Agentsでは、エージェント用のIAM(Identity and Access Management。AWSリソースへの権限を管理する仕組み)サービスロールに、必要な操作だけを許可します^*3。ツールを実行するLambda関数側にも、そのエージェントからの呼び出しだけを許可するリソースベースポリシーを設定します^*3。特定のエージェントIDに絞った条件キーの使用が、セキュリティのベストプラクティスとして案内されています^*3。

権限を絞っても機能が広ければ意味がない

権限設定を絞り込んでも、ツールそのものが不要な機能を持っていれば、過剰な機能のリスクは残ります^*1。ツールが対応するAPIの範囲とサービスロールの権限、この両方を業務要件に合わせて絞り込む作業が欠かせません。

承認ゲート(HITL)——重要な操作の前に人の確認を挟む設計

HITL(Human In The Loop。最終的な実行判断を人が担う運用設計)は、過剰な自律性への直接的な対策です^*1。主要クラウドは、この確認ステップを具体的な機能として提供しています。

AWSのユーザー確認機能——CONFIRMとDENYで実行を分岐

Amazon Bedrock Agentsには、アクション実行前に利用者の確認を求める機能があります^*2。OpenAPIスキーマのx-requireConfirmationや、functionベースの action groupのrequireConfirmationパラメータで有効化します^*2。利用者がCONFIRMを選ぶとアクションが実行され、DENYを選ぶと実行されません^*2。

Microsoft Agent Frameworkの例——関数ツールへのapproval_mode

Microsoft Agent Frameworkでは、関数ツールごとにapproval_modeを設定できます^*5。always_requireを指定した関数は、実行前に承認要求としてエージェントの応答に含まれます^*5。呼び出し側が承認か却下かを返すまで、その関数は実行されません^*5。

どちらの実装も、承認を求める粒度をアクション単位・関数単位で開発者が選べる点が共通しています^*2*5。読み取り専用の操作は自動実行に任せ、書き込みや外部送信を伴う操作にだけ承認ゲートを置く、という切り分けが実務的な出発点になるでしょう。

エージェントの本人性——AWS・Azure・Googleが提供する認可の仕組み

権限を絞り込んでも、その権限を使っているのが本当にそのエージェントなのかを確かめられなければ意味がありません。主要クラウドは、エージェント自身に固有の識別子を持たせる仕組みを提供しています。

共有の認証情報に頼らない——エージェント単位の識別

Microsoft Foundry(Azure AI Foundry)は、Microsoft Entra IDにエージェント専用の識別子「エージェントアイデンティティ」を発行します^*4。これは人間の利用者や共有のマネージドIDとは別の、エージェント固有のサービスプリンシパルです^*4。公開したエージェントには専用のアイデンティティが割り当てられ、RBAC(Role-Based Access Control。役割単位でアクセス権を管理する仕組み)のロールをそのアイデンティティへ直接割り当てます^*4。

Google CloudのVertex AI Agent Engineは、SPIFFE(Secure Production Identity Framework For Everyone。ワークロードに暗号学的なIDを割り当てる標準規格)に準拠したエージェント単位のIDを発行します^*6。デプロイ時に自動でX.509証明書が発行され、24時間ごとに更新される仕組みです^*6。principal://形式のIDに対してIAM権限を個別に付与できるため、サービスアカウントを複数のエージェントで共有せずに済みます^*6。

3つのクラウドを比較すると、識別・権限付与・実行前のゲート・追跡性のいずれも対応範囲が異なります^*2*3*4*5*6*7。整理すると次の通りです。

サンドボックス化と監査ログ——実行環境の分離と行動の追跡

実行環境を分離する——コード実行・ツール呼び出しの隔離

AIエージェントがコードを生成して実行する機能を持つ場合、その実行環境を本番システムから隔離するサンドボックス化が必要になります。Amazon Bedrock Agentsのコード実行機能は、S3からアクセスするファイルの範囲を個別の権限で絞り込む設計です^*3。実行環境そのものを分離したうえで、渡すデータの範囲も権限で絞る、二重の制御になっています。

行動を追跡する——誰が・いつ・何を実行したかを残す

監査ログは、権限設計や承認ゲートをすり抜けた操作を事後に検知するための最後の防御層です。Amazon Bedrock AgentsはInvokeAgentのレスポンスに、ツール呼び出しの経緯を示すトレース情報を含めます^*2。Microsoft Entra管理センターでは、テナント内のエージェントアイデンティティを一覧し、条件付きアクセスやアイデンティティ保護を適用できます^*4。

Google Cloudでは、SPIFFE IDがログに記録されるため、どのエージェントがリクエストを送ったかを呼び出し元まで追跡できます^*6。権限設計・承認ゲート・認可・監査ログの4層は、どれか1つだけでは機能しません。権限を絞っていても本人性を確認できなければ権限の使い回しが起こり得ますし、監査ログだけでは実行後の検知にしかならないためです。

見落としやすい落とし穴——ツール連携時の権限スコープとMCP認可

AIエージェントに社内システムやSaaSのツールを接続する際、MCP(Model Context Protocol。AIエージェントと外部ツールの接続方法を標準化した規格)のようなプロトコルを使う実装が広がっています。

MCPサーバー側の認可設計は、それ自体が独立した検討テーマです。本稿では、権限設計の観点から関わる部分だけに触れます。ツールが受け取るトークンのスコープが広すぎると、そのツールを介して過剰な機能・過剰な権限のリスクがそのまま持ち込まれてしまいます^*1。

Google Cloudの組織的ゲート——承認済みツールだけを使わせる

Google Cloudは、開発者が個別にツールを実装する代わりに、管理者が承認したツールだけを組織全体で使わせる仕組みをVertex AI Agent Builderのコンソールへ統合しました^*7。BigQueryなど主要サービス向けにMCP対応のツールをあらかじめ用意し、既存のAPIをApigee経由でMCPサーバー化して登録する方法も案内されています^*7。個々のエージェント開発者が任意のツールを自由に接続できる状態を避け、組織として使えるツールの範囲を先に絞る発想です^*7。

ツール連携を増やすほど、機能・権限・自律性のどこかが緩む可能性が高まります。新しいツールを追加するたびに、これまで見た4つの観点(機能・権限・本人性・監査ログ)へ影響がないかを確認する運用が実務的です。

内製と外注の分かれ目——AIエージェントの権限設計に必要な知識と工数

AIエージェントの権限設計を内製で担うには、複数領域の知識が要ります^*1*2*3*4*5*6。主な領域は次の3つです。

• OWASPのリスク分類(機能・権限・自律性の3つの過剰)に関する理解^*1
• 利用するクラウドのIAM・RBAC・エージェントアイデンティティの設定方法^*3*4*6
• 承認ゲートの実装と、ツール追加時に権限スコープを見直す運用スキル^*2*5

これらを開発チームの数名が兼務するのは負荷が大きく、セキュリティ担当との連携体制が前提になります。専門パートナーに委託する場合は、依頼範囲の広さが選定の分かれ目です。

初期の権限設計・承認ゲートの実装だけでなく、ツール追加時の継続的な見直しや監査ログの監視まで一括して依頼できるかを確認します。内製では初期設定までは対応できても、継続的な見直しに手が回らない場合があります。

。接続するツールの数やクラウドの組み合わせによって必要な工数は変わってきます。現状のAIエージェント活用計画を診断したうえで、内製・外注の切り分けを検討することが実務的です。

まとめ：AIエージェントのセキュリティ・権限設計で押さえる3つの判断軸

本稿ではAIエージェント特有の行動リスクについて、OWASPの分類と主要クラウドの機能をもとに整理しました。要点は3つに集約できます。第一に、リスクの本質は過剰な機能・過剰な権限・過剰な自律性という3つの過剰であり、いずれか一つの対策では抜け道が残ります^*1。第二に、承認ゲートと本人性の確認は別々の機能であり、AWS・Azure・Googleでそれぞれ異なる粒度で提供されています^*2*4*5*6。第三に、ツール連携を増やすほど見直しの負荷が増えるため、監査ログを含めた継続的な運用体制が内製・外注の判断材料になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：OWASP GenAI Security Project「LLM06:2025 Excessive Agency」（OWASP Top 10 for LLM Applications 2025）（https://genai.owasp.org/llmrisk/llm062025-excessive-agency/）
2. *2　出典：AWS「Get user confirmation before invoking action group function」（Amazon Bedrock User Guide）（https://docs.aws.amazon.com/bedrock/latest/userguide/agents-userconfirmation.html）
3. *3　出典：AWS「Create a service role for Amazon Bedrock Agents」（Amazon Bedrock User Guide）（https://docs.aws.amazon.com/bedrock/latest/userguide/agents-permissions.html）
4. *4　出典：Microsoft「Agent identity concepts in Microsoft Foundry」（Microsoft Learn）（https://learn.microsoft.com/en-us/azure/ai-foundry/agents/concepts/agent-identity）
5. *5　出典：Microsoft「Using function tools with human in the loop approvals」（Microsoft Learn、Agent Framework）（https://learn.microsoft.com/en-us/agent-framework/agents/tools/tool-approval）
6. *6　出典：Google Cloud「Agent identity」（Vertex AI Agent Engine ドキュメント）（https://docs.cloud.google.com/agent-builder/agent-engine/agent-identity）
7. *7　出典：Google Cloud Blog「New enhanced tool governance in Vertex AI Agent Builder」（https://cloud.google.com/blog/products/ai-machine-learning/new-enhanced-tool-governance-in-vertex-ai-agent-builder）

Tweet