AIエージェントのセキュリティは、すべてのアクションを代理対象のID、テナント、リソース、権限へ紐づけることから始まります。プロバイダー認証情報をモデルコンテキストの外に置き、下流サービスで認可を強制し、影響の大きい効果の前に承認を求め、調査のために判断と結果を記録します。
システムプロンプトは振る舞いを形作れますが、ツールprocessから利用できる管理者tokenの権限を減らすことはできません。
アクション全体でIDを伝える
エージェントの実行には、人間のユーザー、アプリケーションテナント、エージェントdeployment、session、background workerが関係する場合があります。これらのIDを個別に保持します。
flowchart LR
User[Authenticated user] --> Session[Agent session]
Session --> Policy{Tenant, resource, action}
Policy -->|allow| Tool[Server-side tool]
Tool --> Credential[Scoped provider credential]
Credential --> Backend[Downstream service]
Policy --> Audit[Decision record]
Backend --> Audit
バックエンドには、代理対象のユーザーとテナントを認可するのに十分なコンテキストを渡します。共有worker認証情報が避けられない場合、tool adapterが不足するリソースルールを適用してから使います。
エージェント・コントロールプレーンのガイドでは、これらの判断と認証情報参照を置く場所を示しています。
認証情報とAPIのレイヤーで権限を減らす
エージェントには現在の作業に必要なアクションとリソースだけを与えます。読み取り、書き込み、provisioning、billing、administrationの認証情報を分けます。テナントと環境でscopeを限定し、プロバイダーが対応していれば認証情報の有効期間を短くします。
タスク単位の操作で十分なら、広範なprimitiveを公開しないでください。refund_order(order_id, amount)は所有権、金額上限、承認、冪等性を強制できます。汎用SQLまたはprovider admin toolでは、これらの判断をすべて生成引数へ移してしまいます。
OWASPのExcessive Agencyガイダンスは、ツール機能、権限、自律性の最小化を推奨しています。モデルが有効なツールを選んでも、認可は引き続きバックエンドの責任です。
シークレットをモデル経路から外す
シークレットをサーバー側managerへ保存し、アプリケーションコードには参照を渡します。必要とする最小のruntimeへタスクscopeの認証情報を注入し、その後取り消すか失効させます。
シークレットは次の経路から漏れやすくなります。
- プロンプトと取得コンテキスト
- ツールの引数または説明
- URLとquery string
- exception messageとstdout
- trace、replay data、support export
- sandbox fileと継承された環境変数
export前にredactし、意図的にエラーを発生させてテストします。モデルにシークレットの反復や変換を求めてはいけません。MCP接続について、現在の認可仕様はaccess tokenをAuthorization headerに置くことを求め、URI内のtokenをサーバーが拒否すべきと定めています。
効果の前に承認を置く
破壊的、金銭的、外部から見える、または異常に広範なアクションには承認を求めます。正確なリソース、parameter、結果を示し、承認をそれらの値へ紐づけて失効期限を設けます。
実行時に権限を再確認します。操作の待機中にユーザーのroleやリソース所有権が変わる場合があります。承認者が持っていない権限を、承認によって与えることはできません。
Railwayの2026年4月のインシデント報告では、エージェントがアカウントtokenを見つけ、古い即時削除APIを呼び出した事例を説明しています。Railwayはvolumeを復旧し、APIの削除を48時間のsoft-delete経路へ変更しました。教訓は明確です。tokenのscope、APIの動作、復元可能性をまとめて設計する必要があります。
取得contentを信頼できない入力として扱う
Webページ、メール、issue、ドキュメントには、モデルを狙った指示が含まれる可能性があります。データを信頼されたシステムポリシーから分け、取得テキストによってツール権限を拡張できないようにします。モデルが提案したアクションに対して、新しいポリシーチェックを求めます。
ワークフローが狭い場合、ネットワーク接続先とリソース種類にallowlistを使います。外部contentの出典をtraceに記録し、調査担当者が影響元を確認できるようにしますが、そのcontentを権限として扱ってはいけません。
封じ込めに役立つ監査記録を書く
actor、代理対象ユーザー、テナント、エージェントとsession、ツール、リソース、アクション、policy version、decision、approval reference、operation ID、timestamp、outcomeを記録します。「許可」と「完了」は分けます。
監査ログへシークレットや無制限のモデルcontentを保存しないでください。詳細なコンテキストが必要な場合は、保護されたtraceへlinkします。監査経路では、失敗したエージェントに頼らず、取り消すべき認証情報と変更された可能性のあるリソースを特定できる必要があります。
取り消しとテナント間拒否をテストする
隔離環境で次を行います。
- タスクの待機中にsessionを取り消し、安全に再開が失敗することを確認する。
- すべてのツール経路から別テナントのリソースIDへアクセスを試す。
- 取得contentへ敵対的な指示を注入する。
- プロバイダーエラーと検証エラーを発生させ、ログにシークレットがないか調べる。
- 承認なしで破壊的アクションを要求し、下流呼び出しが起きないことを確認する。
本番チェックリストは、これらの制御を再試行、trace、復旧へ結び付けます。
以下のプロンプトは、コードから実際の権限matrixを作成します。強制地点が「システムプロンプト」になっている行は、セキュリティ作業が未完了です。