AI エージェントの権限モデル設計：ユーザーアイデンティティ、ツール権限、監査ログ、Secret 分離

チームが同じ管理者 token をエージェントに渡し、「社内システムだから大丈夫」と考えます。するとユーザー A の検索リクエストに対して、エージェントが管理者アイデンティティでユーザー B の CRM レコードを読んでしまう。権限が崩れたエージェントは、エージェントがない状態より危険です。

これは仮の話ではありません。MCP Security Best Practices は token passthrough を明確に anti-pattern としています。セキュリティ制御を迂回し、audit trail を壊し、trust boundary を越えてしまうためです。OWASP AI Agent Security Cheat Sheet も、「ツールの悪用と権限昇格」を主要リスクの 1 つに挙げています。

問題は 3 つに分解できます。エージェントは誰を代表するのか。何を根拠に呼び出せるのか。何にアクセスできるのか。以下では、アイデンティティ対応表、ツール権限フィールド、Secret Vault の基本手順、監査ログ schema とマスク規則、権限判断表、トラブルシューティング、実装手順までをまとめます。

アイデンティティマッピング：エージェントは誰を代表するのか？

エージェントがツールを呼び出すとき、ログと権限システムが最初に答えるべき問いは 1 つです。誰が呼び出しを開始し、誰を代表して操作しているのか。この 2 つは同じ場合も、違う場合もあります。混同すると、権限が暴走し、監査も追えなくなります。

アイデンティティタイプ対照表

タイプ	actor	subject	適用シーン	権限境界
user identity	ユーザー A	ユーザー A	ユーザーの直接操作	ユーザー権限を継承
service account	system_bot	null	バックグラウンドタスク、定期ジョブ	システムレベル権限、ユーザーとは独立
delegated token	workflow_123	ユーザー A	ユーザーが承認した自動化 workflow	workflow scope、ユーザーの承認範囲に制限
tenant context	agent_456	tenant_B	マルチテナントシステム	テナント分離、テナント横断アクセスは禁止

フィールド定義：actor は呼び出しを開始したエンティティ（ユーザー、エージェント、workflow、システム）で、ログには actor の ID を記録します。subject は代表されるエンティティ（ユーザーまたは null）です。ユーザー本人の操作では actor=subject、システムアカウントがバックグラウンドタスクを実行するときは subject=null です。delegatedBy は委任元で、どのユーザーがこの workflow を承認したかを示します。tenantId はテナント識別子で、マルチテナントシステムのデータ分離に使います。

MCP Authorization 仕様では、MCP servers は access token が自分を intended audience として発行されたものかを検証しなければなりません。Token の audience フィールドは、その MCP server の resource identifier を指す必要があります。Token を URI query string に置くべきではありません。URI はログ、ブラウザ履歴、プロキシキャッシュに残るためです。

OWASP Access Control Cheat Sheet は deny by default、least privilege、すべてのリクエストでの権限チェックを強調しています。アイデンティティマッピングは権限チェックの最初のステップです。actor、subject、tenantId が、その後の権限判断を決めます。

ツール権限：エージェントは何を呼び出せるのか？

ツール登録は name、description、input_schema を定義して終わりではありません。OpenAI Agents SDK のツール reference には、権限と実行制御に関わるフィールドがあります。

ツール権限判断表

権限制御	適用シーン	実装方法	リスク
per-tool permission	ツールごとに個別認可する	ツール登録時に permission_level（read/write/admin）を設定	権限設定が複雑になり、権限マトリクスの保守が必要
scope minimization	段階的な最小権限	初期 scope は低リスク操作だけにし、高権限操作は scope challenge で追加	Scope 管理コストが高く、動的調整が必要
whitelist	ツール許可リスト	read_customer + summarize のように、特定のツール組み合わせだけ許可	許可リストの保守コストがあり、柔軟性を制限しやすい
approval	人の承認	needs_approval=true のツールは実行前に一時停止し、承認を待つ	承認に時間がかかり、ユーザー体験に影響する

OpenAI Agents SDK のツールフィールドには、実行時の有効化制御を行う is_enabled があります。ユーザー role、tenant、workflow context に応じてツールを動的に無効化できます。needs_approval は人の承認が必要かを示します。承認後も tool_input_guardrails は実行されます。tool_input_guardrails は PII 検出やパラメータ範囲チェックなどの入力検証を担当します。tool_output_guardrails はコンテンツフィルタリングなどの出力検証を担当します。

MCP Security Best Practices は、scope minimization について段階的な最小権限を推奨しています。初期 scope は read:metadata、list:resources のような低リスクの発見・読み取り操作だけにし、高権限操作は正確な scope challenge で追加します。wildcard/full-access scopes は避けます。

OWASP AI Agent Security Cheat Sheet は per-tool permission scoping を勧めています。trust level ごとに異なる tool sets を使い、機微な操作には明示的な承認を求め、権限チェックに失敗したら fail closed にします。

Secret 分離：エージェントはどう credential を取得するのか？

エージェントが長期の平文 API key を直接持つべきではありません。OWASP Secrets Management Cheat Sheet は、secret 管理の集中化と標準化を推奨しています。Secret 管理システム自体も、Authentication、Authorization、Accounting、lifecycle を備えるべきです。

Secret アクセスパターン対照表

パターン	リスク	適用シーン	例
直接保持（平文 .env）	漏えいリスクが高く、追跡できず、失効も難しい	非推奨	ハードコードされた API key
環境変数	ログ漏えいリスクがあり、追跡と失効も弱い	単一マシンのデプロイ	process.env.API_KEY
secret vault	集中管理、暗号化保存、監査追跡、失効が可能	本番環境	AWS Secrets Manager、HashiCorp Vault
secret reference	エージェントは reference を保持し、実行時に短期 token を必要に応じて取得	マルチテナント、高セキュリティ環境	vault.get(secretRef)

Secret の lifecycle は 4 段階です。creation では長期 key ではなく短期 token を生成します。rotation は定期的に行い（例：30 日ごと）、自動化プロセスで secret を更新し、関連システムへ通知します。revocation では緊急失効の仕組みを用意し、漏えいを見つけたらすぐに secret を無効化します。expiration では有効期限を設定し、期限切れ後に自動で失効させます。

MCP Security Best Practices は token passthrough を anti-pattern と明記しています。ユーザーの OAuth token をエージェントへ直接渡すと、セキュリティ制御を迂回し、audit trail を壊し、trust boundary を越えます。正しい設計では、ユーザーがエージェントに承認したタイミングで delegated token を発行します。短期で、scope が限定され、audience が明確な token です。

OWASP Secrets Management の基本原則は centralize、least privilege、automate、auditing です。Secret へのアクセスは最小権限に従います。手作業の保守は漏えいとミスを増やします。rotation、revocation、expiration は lifecycle の一部です。

監査ログ：誰がいつ何を呼び出したのか？

監査ログでは「誰が誰を代表してどのツールを呼び、どのオブジェクトへアクセスし、結果はどうだったか」を復元できる必要があります。同時に、引数と secret はマスクしなければなりません。

Audit Log Schema

フィールド	説明	マスク規則
traceId	呼び出し chain ID（N156 の trace/runId 概念を再利用）	マスクしない
timestamp	呼び出し時刻（ISO 8601）	マスクしない
actor	呼び出しを開始したエンティティ	マスクしない
subject	代表されるエンティティ	マスクしない
tool	ツール名	マスクしない
action	操作タイプ（read/write/delete）	マスクしない
resource	操作対象	マスク：customer_id → cust_***
outcome	結果（success/failure/denied）	マスクしない

マスク規則：token、secret、password、email、phone、PII は記録しません。記録するのは who/what/when/where/outcome です。例：customer_id=12345 は cust_、email=[email protected] は e@***.com、token=Bearer xxx は Bearer ***、password=secret123 は記録しません。

OWASP Logging Cheat Sheet によれば、セキュリティログは調査、監査、監視を支えるべきですが、password、session id、access token、機微な個人データを記録してはいけません。who/what/when/where/outcome のような追跡可能な情報を記録します。

NIST SP 800-53 の audit and accountability control family は、監査ログが権限システムの最後の砦になることを示しています。権限チェックが失敗したときは、actor に権限がない、subject に target 権限がない、scope が足りない、といった理由をログへ残す必要があります。

権限モデル判断表：エージェントに必要な制御の組み合わせ

アイデンティティマッピング、ツール権限、Secret 分離、監査ログは独立した制御ではありません。組み合わせて効く制約です。以下はシーンごとの制御セットです。

シーン	identity type	tool permission	secret access	audit log	典型的な用途
低リスクの内部ツール	service account	whitelist（read ツールのみ）	環境変数	actor/tool/outcome	内部レポート生成、定期同期
マルチテナント SaaS	delegated token + tenantId	per-tool permission（tenant でフィルタ）	secret vault（tenant 分離）	full schema（tenantId を含む）	CRM エージェント、メールアシスタント
金融取引	user identity + approval	scope minimization + approval	secret reference（短期 token）	full schema + approvalId	取引承認、資金操作
機微データ操作	delegated token + approval	whitelist + approval + guardrails	secret vault（緊急失効）	full schema + マスク	データエクスポート、顧客照会

OWASP AI Agent Security Cheat Sheet は、trust level ごとに separate tool sets を使い、機微な操作には explicit authorization を求めることを勧めています。権限モデル判断表の要点は組み合わせです。高リスクなシーンでは、単一の制御ではなく、複数の制御を重ねます。

トラブルシューティング：権限問題でよく出る症状

以下は、権限問題でよく出る症状、考えられる原因、確認手順、解決策です。

症状	考えられる原因	確認手順	解決策
エージェントがツール呼び出し時に 403 Forbidden を返す	actor に tool permission がない、または subject に target permission がない	actor の permission_level と subject の resource 権限を確認	アイデンティティマッピングが正しいか確認し、権限マトリクスを調整
ログで actor が空、または subject が混乱している	アイデンティティマッピングフィールドが正しく渡されていない	agent context に actor/subject/tenantId が入っているか確認	呼び出し chain 全体でアイデンティティフィールドを正しく渡す
ツール呼び出しは成功するが、監査ログに必要フィールドがない	Audit Log Schema が不完全	ログ書き込み処理が全フィールドを含むか確認	Schema を補完し、traceId/approvalId を追加
ユーザー A のリクエストでユーザー B のデータが読める	tenantId または subject が分離されておらず、管理者 token を共有している	delegated token を使っているか、tenantId が正しいか確認	delegated token に切り替え、tenantId 検証を強制
Secret rotation 後もエージェントが古い key を使う	Secret reference が更新されていない、または rotation が効いていない	vault が新しい secret を返すか、エージェントが再取得しているか確認	rotation で reference を自動更新する
承認後もツール呼び出しが失敗する	Guardrails が失敗している（パラメータ範囲外、PII 検出）	tool_input_guardrails のログを確認	パラメータまたは guardrails ルールを調整

実装チェックリスト：0 から Agent 権限モデルを作る

権限モデルを実装するための主要な 5 ステップです。

ステップ 1：アイデンティティマッピングルールを定義する

判断ポイント：マルチテナント分離が必要ですか（tenantId フィールドを追加）？バックグラウンドタスクがありますか（service account を定義）？自動化 workflow がありますか（delegated token を使う）？

擬似コード：

interface IdentityContext {
  actor: string;        // 呼び出しを開始したエンティティ
  subject: string | null;  // 代表されるエンティティ
  delegatedBy?: string;  // 委任元
  tenantId?: string;    // テナント識別子
}

ステップ 2：ツール権限マトリクスを設計する

判断ポイント：承認が必要ですか（needs_approval=true を設定）？動的フィルタリングが必要ですか（is_enabled の実行時判断を実装）？パラメータ検証が必要ですか（tool_input_guardrails を実装）？

コード例：

interface ToolPermission {
  name: string;
  permission_level: 'read' | 'write' | 'admin';
  required_scope: string[];
  needs_approval: boolean;
  is_enabled: (context: IdentityContext) => boolean;
}

ステップ 3：secret vault を接続する

判断ポイント：短期 credential が必要ですか（secret reference を使う）？緊急失効が必要ですか（vault が即時無効化に対応しているか確認）？

コード例：

async function getSecret(secretRef: string, context: IdentityContext): Promise<string> {
  // アイデンティティを検証
  await vault.authenticate(context.actor);
  // 権限を検証
  await vault.authorize(context.actor, secretRef);
  // 短期 token を取得
  const token = await vault.getToken(secretRef, expiresIn: '15m');
  // 監査を記録
  await auditLog.record({
    actor: context.actor,
    action: 'get_secret',
    resource: secretRef,
    outcome: 'success'
  });
  return token;
}

ステップ 4：監査ログを実装する

判断ポイント：マスクが必要ですか（redaction ルールを実装）？traceId が必要ですか（N156 の trace/runId を再利用）？

コード例：

interface AuditLogEntry {
  traceId: string;
  timestamp: Date;
  actor: string;
  subject: string | null;
  tool: string;
  action: 'read' | 'write' | 'delete';
  resource: string;  // マスク済み
  outcome: 'success' | 'failure' | 'denied';
}

ステップ 5：権限境界をテストする

判断ポイント：越権シナリオをテストしますか（ユーザー A がユーザー B のデータへアクセスするケース）？token 漏えいをテストしますか（secret 漏えい後の失効フローを再現）？監査追跡をテストしますか（traceId で chain 全体をたどる）？

テストチェックリスト：越権テスト（actor=user_A、resource=tenant_B → 403 を返すべき）。token 漏えいテスト（vault.revoke(secretRef) → エージェントは新しい token を取得できないべき）。Audit 追跡テスト（traceId で呼び出し chain 全体を検索 → actor/subject/tool/outcome を含むべき）。

次のステップ：関連する読み物

Agent 権限モデルは、アイデンティティ、ツール、Secret、監査など複数の層にまたがります。関連する記事もあわせて読むと整理しやすくなります。

公開済みの記事：

• Agent Sandbox ガイド：Sandbox は実行隔離（コンテナ/Docker）を扱います。この記事は権限と secret boundary を扱い、両者は補完関係にあります。
• ツール呼び出し実践：ツール呼び出しの基礎。この記事では tool whitelist、per-tool permission、入力検証まで広げています。
• AI Agent の監視と復旧：監視とアラートの基礎。この記事では audit fields と traceId を補っています。