AIエージェントに本番権限を渡す前に考えること

Oracleの報告が示した権限の分け方

Oracleは2026年10月5日の導入報告で、社内システムへのMCP接続において、従業員本人の権限と、本人が同意したscopeを維持すると説明しています。MCPはAIと外部ツールを接続する仕組み、scopeはアクセスを認める範囲です。閲覧への同意から、送信や更新の許可は導けません。[1]

同報告では、対象となる開発者・運用担当者の展開に、JITアクセス、機微な操作への人間の承認、不要な権限の見直しを導入したとしています。JITは、承認された作業に必要な期間だけアクセスを与える考え方です。管理者本人に本番操作の権限があっても、それをエージェントへ常時渡さない設計につながります。[1]

ここで確認できるのはOracleの導入報告です。MCPを採用すれば同じ制御が自動で備わるとは限らず、自社の接続先や実行ツールでも確かめる必要があります。

調査から変更へ進むときの具体例

冒頭の決済APIを例に、運用を設計してみます。以下は本記事の設計例であり、Oracle環境での検証結果ではありません。

最初に渡す権限は、対象サービスのメトリクスと、調査に必要なログの閲覧までに絞ります。ログに個人情報や認証情報が含まれるなら、取得範囲やマスキングも先に決めます。「原因調査」の段階では、再起動や設定変更を実行できない状態にします。

再起動が対処候補に挙がったら、エージェントには対象、理由、利用者への影響、失敗時の対応を提示させます。人が変更を承認した後に、対象サービスの再起動に必要な権限を短時間だけ追加します。この承認を、増設やデータ削除の許可に広げてはいけません。

画面上の確認だけでなく、実行先も承認の対象と期限を検査できる構成にします。検証環境では、未承認の対象への実行、承認内容を書き換えた実行、期限切れ後の再実行が拒否されるかを試すと、境界の漏れを見つけやすくなります。

禁止ルールには適用範囲と例外がある

OracleのConsole AI公式資料には、AI経由の特定のデータベース削除をDenyポリシーで拒否する例があります。Denyは明示的な禁止ルールです。ただしConsole AIは、確認時点では限定的な本番前プレビューで、本番データや機密情報を使わないよう案内されています。ここでは権限設計の参考として扱います。[2]

適用されるDenyはAllow（許可）より優先し、利用者が承認しても上書きできません。一方、OCIの既定ドメインにある既定Administratorsグループは適用除外です。また、Deny機能は既定で無効であり、一度有効にすると機能自体を無効には戻せません。個々のルールの変更とは分けて判断する必要があります。[1][3]

経路にも注意が必要です。Console AIを指定する条件は、そのサービスからの直接の要求に適用されます。処理の途中で別のOCIサービスが行う操作には、その条件のDenyが及ばず、必要に応じて別の制約を設けます。入口で削除を止めたことだけでは、別ツールや後続処理まで制限できたと判断できません。[2]

短命トークンに替えた後も権限を確かめる

APIキーを置き続ける代わりに、実行中のプログラムの身元から有効期限の短い認証情報を得る方法がWIF（ワークロードID連携）です。Anthropicの仕様では、認証基盤が発行する署名付き情報と設定条件を確認し、サービスアカウントに結び付く短命トークンを発行します。認証情報の寿命を短くしても、認める操作範囲の設計は必要です。[4]

移行時には、実際に使われる認証情報も確認しましょう。Anthropic SDKの自動選択では、環境変数ANTHROPIC_API_KEYに残ったキーがWIFの環境設定より優先されます。明示したコンストラクタ引数はさらに上位です。設定を追加しただけで移行完了とせず、稼働する環境で選択された認証元を確かめます。[4]

別のエージェントへの委任も範囲を絞る

調査結果の要約を別のエージェントに任せるなら、必要なログの抜粋を渡す方法が考えられます。元のデータベース認証情報まで共有する必要があるかは、別に判断します。

Oracle DB Toolsの仕様では、利用者のIDとMCPサーバーの実行IDのどちらで処理するかを選べます。接続できた後に、誰の権限で動くかを確認する必要があります。また、委任を表現できるRFC 8693を使っても、権限が広がらないことが自動保証されるわけではありません。受け取る側の認可設計が必要です。[5][6]

本番導入前に確かめたい6つのこと

次の項目を、検証環境での許可・拒否テストに落とし込んでみてください。

1. 調査用IDとscopeを特定できるか。調査中の更新や削除は拒否されるか。
2. 権限追加の対象、操作、期限、影響が記録され、期限切れ後の再実行が止まるか。
3. 変更を提案するエージェントが自分で承認できないか。承認を通らない実行経路がないか。
4. 禁止ルールの適用除外は誰か。別サービスへの後続処理や別ツールも確認したか。
5. WIF移行後の認証元は意図どおりか。発行元、対象プログラム、トークンの宛先と権限を説明できるか。
6. 委任先に渡すデータと権限は必要な分だけか。依頼者、実行者、承認、結果を一つの作業として追跡できるか。

まずは、普段の調査依頼を一つ選び、「読んでよいもの」と「変更してよいもの」を書き分けるところから始められます。その境界を権限設定とテストで確かめてから、任せる作業を増やしましょう。

2026年10月6日時点の公式資料に基づく整理です。筆者による実環境での動作検証や、導入効果の測定は行っていません。