AIエージェントの権限管理｜ガードレールとサンドボックスの考え方

この記事の内容は、2026年10月2日に OWASP、n8n、Dify の公式ドキュメントと、AISI・経済産業省の資料で確かめたものです。機能やプランの条件は変わることがあります。末尾の出典から最新の内容を確かめてください。

AIエージェントの権限管理で考えるのは、AIが誤った判断をしたときに何が起きるかです。権限が広いほど、誤りや乗っ取りの被害も広がります。被害の種類はAIエージェントのセキュリティで説明しています。

権限は「必要な分だけ」が基本

OWASP の「Top 10 for LLM Applications 2026」は、過剰な権限（Excessive Agency）を防ぐ方法を挙げています。基本は、ツール、機能、権限のどれも必要な最小限にすることです。

• ツールを絞る：URLの中身を取ってくる必要がないなら、そのツールは渡さない
• 機能を絞る：メールを要約するだけなら、読む機能だけにし、送信や削除の機能は付けない
• 何でもできるツールを避ける：シェルのコマンドを実行するツールではなく、ファイルに書くだけのツールを作る
• 権限を絞る：商品を勧めるだけなら、商品の表を読む権限だけにし、書き込みや削除は許さない

OWASP は、操作を許すかどうかの判断をAIに任せず、プログラムの側で決めることも勧めています。AIの指示文に「削除しないこと」と書くだけでは、指示が破られたときに止まりません。削除の権限そのものを渡さないことが、確実な止め方です。

AISI の「AIセーフティに関する評価観点ガイド（第1.20版）」にも、AIエージェントが必要な情報やツールだけにアクセスできるかを確かめる評価項目の例があります。

AIエージェント用のアカウントと認証

AIエージェントの認証では、誰の権限で動くかを決めます。OWASP は、利用者の代わりに行う操作は、その利用者の権限の範囲で、最小限の権限で実行するよう勧めています。たとえば、利用者のコードを読むツールなら、OAuth で必要最小限の範囲だけ許可してもらいます。

• AIエージェント専用のアカウントやAPIキーを作り、人のアカウントと分ける
• APIキーやトークンは、AIではなくプログラムの側で持つ
• AIへの指示文（システムプロンプト）に、パスワードやトークンを書かない
• 連携先のアプリの権限は、使う機能に合わせて選ぶ

AI専用のアカウントにしておくと、記録から誰の操作かを見分けやすくなります。問題が起きたときも、そのアカウントやキーだけを止められます。OWASP の「Agentic AI - Threats and Mitigations」は、AIエージェントの持続的なIDが盗まれると、長期間APIにアクセスされるおそれがあると指摘しています。

ガードレール：入力と出力を確かめる

ガードレールは、AIへの入力と、AIからの出力を確かめる仕組みです。Anthropic の解説は、1つのモデルが本来の作業をし、別のモデルが不適切な内容をふるい分ける形が、同じモデルに両方をさせるより良く働きやすいと紹介しています。

OWASP は、出力の形の確認は、別のAIに頼まずプログラムで行うよう勧めています。ただし、形が正しくても中身が悪いことはあります。ガードレールだけに頼らず、権限を絞る対策と組み合わせます。

サンドボックス：試す場所を分ける

サンドボックスは、本番から切り離した試す場所です。Anthropic の解説は、自律して動くエージェントは費用が高くなりやすく、誤りが積み重なるおそれもあるとして、サンドボックスでの十分なテストと、適切なガードレールを勧めています。

n8n では、ワークフローと認証情報をプロジェクトにまとめられます。検証用のプロジェクトと本番用のプロジェクトを分け、検証用にはテスト用の認証情報だけを入れておくと、試している間に本番のデータへ触れません。Dify でも、検証用のアプリやワークスペースを分けて試せます。

AIが書いたコードを動かす場合も、サンドボックスが使われます。OWASP の「Agentic AI - Threats and Mitigations」は、AIが作ったコードの実行権限を制限し、サンドボックスで実行するよう勧めています。

人の承認を挟む操作の決め方

すべての操作に人の承認を挟むと、確認する人の負担が増えます。OWASP は、取り消せる操作や影響の小さい操作は自動で通し、取り消せない操作や影響の大きい操作は人の確認に回す、段階的な決め方を紹介しています。例として、店のポイントでの返金は取り消せるので自動で処理し、外部への送金は人の承認に回す形を挙げています。

AI事業者ガイドライン（第1.2版）は、AIに単独で判断させず、適切なときに人の判断を挟むことを検討するよう求めています。あわせて、人の判断が機械への過度な信頼（自動化バイアス）に左右されない対策も求めています。承認の依頼には、AIが何をしようとしているかを具体的に載せます。

n8n・Difyの権限設定の例

n8n の権限管理

n8n の権限管理は、インスタンス全体のロールと、プロジェクトごとのロールの2段階です。インスタンスのロールは Owner、Admin、Member です。プロジェクトにはワークフローと認証情報（credentials）をまとめ、Admin、Editor、Viewer のロールを付けます。Viewer は読むだけで、ワークフローを手動で実行することもできません。

使えるロールはプランで変わります。プロジェクトのロールは、n8n Cloud の全プランと、自分のサーバーの Registered Community、Business、Enterprise で使えます。Editor は n8n Cloud の Pro と自分のサーバーの Enterprise、Viewer は Enterprise で使えます。

AIエージェントのツールには、人の承認を付けられます。承認されればツールが動き、却下されれば動きません。承認の依頼は Slack、Microsoft Teams、Gmail などに送れます。自分のサーバーで動かす場合は、n8n audit というコマンドでセキュリティの監査を実行できます。監査の報告は、認証情報、データベース、ファイルシステム、ノード、インスタンスの5つに分かれています。

Dify の権限管理

Dify のワークスペースには、4つのロールがあります。Owner はワークスペース全体を管理し、1つのワークスペースに1人です。Admin はメンバーとモデルの提供元を管理できます。Editor はアプリとナレッジを作成・編集・削除できます。Normal は公開されたアプリを使うだけです。メンバーの数の上限は、Sandbox が1人、Professional が3人、Team が50人です。

Dify で作ったWebアプリは、初期設定では公開されており、URLを知っている人なら誰でも開けます。社内だけで使う場合は、公開の範囲を確かめます。ワークフローには、人の入力を待って止まる Human Input ノードがあり、メールなどで確認を依頼できます。Agent には繰り返しの上限（Maximum Iterations）を設定できます。

組織としてAIの使い方を決める方法はAIガバナンスで、間違いや暴走への備えはAIエージェントのリスクで説明しています。

Employee Store で導入するとき

Employee Store では、開発者が作ったAIエージェントを買い切りや月額で導入できます。導入の前に、AIエージェントがどのアカウントで動き、どの権限を必要とし、どの操作に人の承認があるかを確かめます。購入後は、取引ルームのメッセージで出品者に確認できます。掲載中のAIはAI社員の一覧から探せます。