【AgentOps⑥・権限】“付けたら付けっぱなし”の落とし穴——エージェント権限のライフサイクル運用規律｜Just-in-Timeアクセス・最小権限のドリフト監視・権限行使の可観測性（誰が・何を・なぜできたか）・過剰権限＝ブラストラジウスのコスト・卒業/失効（deprovisioning）で「権限が事故になる」を防ぐ運用設計

AgentOps連載： ①入門／ ②評価／ ③観測／ ④コスト／ ⑤メモリ／ ⑥権限（本記事）

エージェントに強い権限を渡すと、できることは一気に増えます。ファイルを読み、APIを叩き、他システムへ書き込み、決済にまで手が届く——最初の設計では「必要だから」付けた権限ばかりのはずです。ところが実運用では、権限は「付けた瞬間」がピークで、そこから静かに劣化していきます。使われなくなっても剥がされず、一時的な検証のために広げた範囲がそのまま常設になり、棚卸しは後回しになる。最小権限は設計思想ではなく、運用し続けないと崩れる「生もの」だからです。

本記事は、ネットワーク／セキュリティ運用の現場感覚を土台に、エージェント権限を「設計」ではなく「ライフサイクル運用」として捉え直します。焦点は5つ——Just-in-Time（都度付与・自動失効）／最小権限のドリフト監視／権限行使の可観測性（誰が・何を・なぜできたか）／過剰権限のコスト（ブラストラジウス）／卒業＝deprovisioningです。

---

はじめに——「付けたら付けっぱなし」が、最小権限を静かに裏返す

権限設計の話は、たいてい「最小権限（least privilege）でいきましょう」で終わります。正しいのですが、それはスタート地点の話でしかありません。エージェントが長期運用されるほど、権限には3つのことが起きます。

• 膨張（scope creep）：新しいタスクのたびに「とりあえず付与」が積み重なる。
• 陳腐化（stale）：役目を終えた権限が剥がされず、使われないまま残る。
• 棚卸し漏れ：誰も全体像を把握しておらず、「なぜこの権限があるのか」を説明できない。

この3つが同時に進むと、設計した瞬間は最小だったはずの権限セットが、いつの間にか「実質フルアクセス」に近づいていく。しかも劣化は静かに進むので、事故が起きて初めて「そんな権限、まだ生きていたのか」と気づきます。これが「付けたら付けっぱなし」の落とし穴です。

本連載は、エージェントを「作る」から「運用する」へ移すためのライフサイクル要素を積み上げてきました。②評価で品質を測り、③観測で挙動を見え、④コストで採算を守り、⑤メモリで記憶を運用規律に載せました。⑥の「権限」は、そのどれとも接続します——権限は、エージェントが「何をできるか」を規定する、運用の結節点だからです。

なぜ今か——「権限を設計する」から「運用し続ける」フェーズへ

2026年、エージェントやサービス、スクリプトが持つ非人間アイデンティティ（NHI：Non-Human Identity）は、人間のアカウントを数のうえで大きく上回っています。人間なら入退社や異動のたびに権限が見直されますが、NHIには「卒業」の仕組みが標準では備わっていません。作られては忘れられ、使われなくなっても消えず、棚卸しの対象からこぼれ落ちやすい。

エージェントは、この問題をさらに悪化させます。自律的にツールを呼び、外部APIと連携し、必要に応じて権限を要求する——つまり「権限を使う主体」が増え続け、しかも動的に振る舞う。だからこそ、権限を一度きり「設計する」対象ではなく、付与・行使・棚卸し・失効を回し続ける「運用する」対象として扱う必要があります。最小権限は、監視して初めて維持できる状態になったのです。

前提——エージェント権限を「ライフサイクル」で捉える

権限を運用対象にする第一歩は、状態遷移として分解することです。1回付けて終わりではなく、次の段階を回し続けます。

段階	やること	運用上の主な論点
申請／要求	タスクに必要な権限を明示的に要求する	「なぜ必要か」を残せているか（正当化の記録）
付与	必要最小の範囲・期間で与える	常設ではなく期限付き（TTL）にできているか
行使	実際に権限を使って操作する	誰が・何を・なぜ実行できたかをトレースできるか
棚卸し	付与済みと実利用のズレを継続検証する	「設計図」と「実態」のドリフトを検知できるか
失効／卒業	役目を終えた権限を確実に剥がす	自動失効か、手動棚卸し頼みか

この5段階のうち、多くの現場が手厚いのは「付与」だけです。行使のトレース、棚卸し、失効が弱いと、権限は片道でしか動かず、増える一方になります。以下の5つの規律は、この片道通行を、往復する運用に変えるための処方箋です。

落とし穴——「付けたら付けっぱなし」がなぜ事故になるのか

過剰権限は、平常時は何も起こしません。問題は、何かが起きたときに影響範囲（ブラストラジウス）を決めてしまう点です。プロンプトインジェクションでエージェントが乗っ取られても、資格情報が漏れても、鍵が奪われても——被害の大きさは「そのアイデンティティが何をできたか」で決まります。付けっぱなしの権限は、事故が起きた瞬間に、そのまま被害の上限になるのです。

しかも過剰権限は、事故がなくてもコストを生みます。監査のたびに「この権限は本当に要るのか」を人手で確認する負荷、コンプライアンス対応での説明責任、棚卸しの工数——使っていない権限ほど、維持のための見えないコストを払い続けている。「念のため残す」は無料ではありません。

規律1：Just-in-Time（JIT）アクセス——「都度付与・自動失効」を既定にする

最も効くのは、そもそも常設権限を減らすことです。JIT（Just-in-Time）アクセスは、「必要になった瞬間に、必要な範囲だけ、期限付きで付与し、用が済んだら自動で失効させる」考え方です。付けっぱなしを防ぐ最短の方法は、そもそも「付けっぱなし」という状態を作らせないことにあります。

常設（standing）権限を、期限付き（ephemeral）に置き換える

設計の勘所は次の通りです。

• デフォルトは無権限：エージェントの初期状態を「何もできない」に寄せ、タスク単位で必要な権限を要求させる。
• TTL（有効期限）を必須にする：付与にはかならず期限を付け、期限が来たら自動で剥がす。「無期限」を作らせない。
• 危険な操作は昇格（elevation）を挟む：破壊的・不可逆な操作（削除・送金・本番書き込み）は、その都度の昇格要求＋承認を通す。恒久付与しない。
• スコープを絞る：「全ファイル読み取り」ではなく「このバケットのこの接頭辞だけ」。範囲を狭めれば、事故時のブラストラジウスも縮む。

JITは「不便になる」と敬遠されがちですが、都度付与を自動化すれば体感の摩擦はほぼ消えます。人手の承認が要るのは、あくまで高リスク操作に限定するのがコツです。

規律2：最小権限のドリフト監視——「設計図と実態のズレ」を継続検証する

最小権限は、設計した瞬間がピークです。運用の中で権限は膨張し、実利用は変化していく。だから「設計図（付与されている権限）」と「実態（実際に使われている権限）」のズレ（ドリフト）を継続的に測ることが、最小権限を維持する唯一の方法になります。

何を監視するか

• 未使用権限：付与されているが、一定期間まったく行使されていない権限。剥がす第一候補。
• 過剰スコープ：与えた範囲に対して、実際に触れているのはごく一部——という乖離。範囲を実態に寄せる。
• 付与の増加率：一定期間でどれだけ権限が増えたか。膨張の勢いそのものを指標にする。
• 例外の常設化：一時的に広げたはずの権限が、期限を越えて残っていないか。

ポイントは、これを棚卸しイベント（四半期に一度など）ではなく、継続監視にすることです。年に数回の棚卸しでは、膨張のスピードに追いつけません。「未使用90日で自動フラグ」「未使用180日で自動失効候補」のように、しきい値と自動化で回します。

規律3：権限行使の可観測性——「誰が・何を・なぜできたか」をトレースする

③観測ではエージェントの挙動全般を扱いましたが、権限の文脈ではもう一段踏み込みます。事故対応でも監査でも、答えるべき問いは決まっています——「誰が、何に対して、なぜ、その操作を実行できたのか」。ここを後から再構成できるかどうかが、権限運用の可観測性です。

1回の権限行使ごとに残すべきトレース

問い	残すべき情報
誰が（Who）	実行したアイデンティティ（どのエージェント／NHI／委任元）
何を（What）	対象リソースと操作（読み取り／書き込み／削除など）と結果
なぜ（Why）	その操作を許した根拠（どのポリシー／どの付与／どのタスク由来か）
いつ・どこから（When/Where）	時刻・呼び出し元・セッション文脈
委任の連鎖（On behalf of）	ユーザー→エージェント→ツールの委任経路（Confused Deputy追跡の起点）

とくに大事なのが「なぜ」——許可の根拠のトレーサビリティです。「操作できてしまった」ときに、どのポリシーがそれを許したのかを即座に辿れないと、封じ込めも再発防止も遅れます。ログは「操作の記録」だけでなく「許可の記録」まで含めて設計します。

規律4：過剰権限のコスト——ブラストラジウス＝監査負荷＝リスク（④コストと直結）

ここは④コストと正面から接続します。過剰権限のコストは、料金明細には出てきませんが、確実に払われています。

• ブラストラジウス（blast radius＝影響範囲）：事故時に何が壊れうるかの上限。過剰権限はこの上限を押し上げる。
• 監査・コンプライアンスの負荷：権限が多いほど、棚卸し・証跡確認・説明責任の工数が増える。
• リスクの期待値：「使われない権限」でも、漏洩・悪用の確率がゼロにならない限り、リスクを積み増している。

つまり権限は、保有しているだけでコストを生む在庫です。④コストで「動くが高すぎて続かない」を論じたのと同じ発想を、権限にも当てはめます——使っていない権限は、キャッシュされた過剰在庫と同じで、抱えるほど維持費とリスクがかさむ。ドリフト監視（規律2）と卒業（規律5）は、この在庫を圧縮するための仕組みでもあります。

規律5：卒業＝deprovisioning——「役目を終えた権限」を確実に失効させる

ライフサイクルの最後、そして最も抜けやすいのが卒業（deprovisioning）です。人間なら退職・異動で権限が見直されますが、エージェントやNHIには「辞める日」がありません。だから失効は、意識的に設計しないと永遠に起きません。

卒業を「イベント」ではなく「既定動作」にする

• TTL満了で自動失効：規律1のJITと対。期限切れを失効のトリガーにする。
• 役目の終了を検知して剥がす：タスク完了・プロジェクト終了・エージェント廃止に、権限失効を紐づける。
• 孤児（orphaned）NHIの掃除：所有者不明・利用実績ゼロのアイデンティティを定期的に検出し、停止・削除する。
• 失効の可逆性を用意する：誤って剥がしたときに素早く戻せる導線（規律3のトレースがあれば再付与の根拠も辿れる）。

卒業が回り出すと、権限セットは「増える一方」から「使われた分だけ残る」へと変わります。これが、最小権限を運用で維持するということです。

本連載と既存記事の棲み分け——⑥は「権限の運用規律」に集中する

権限まわりは既存記事でも扱っていますが、それぞれ切り口が違います。⑥は⑤メモリと同じく、攻撃・事故を防ぐセキュリティ実装ではなく、運用としての「権限の規律」に集中します。

テーマ	扱う層
NHI管理	アイデンティティの棚卸し（誰が・何が存在するか）
権限エスカレーション防止	権限の連鎖膨張を止める（攻撃の阻止）
Confused Deputy対策	委任の構造的脆弱性を塞ぐ（設計の堅牢化）
鍵管理	資格情報の保管・ローテーション（クレデンシャルの守り）
キルスイッチ／人間承認レイヤー	危険な行動を「止める層」
⑥権限（本記事）	付与・行使・棚卸し・失効を回す「運用規律」

言い換えると、⑥はJIT（都度付与・自動失効）・最小権限のドリフト継続検証・権限行使の可観測性・過剰権限のコスト・卒業（deprovisioning）という、日々回し続ける運用の話です。②評価・③観測・④コスト・⑤メモリを「権限」という軸で束ね直す結節点として、連載ハブの中心に置けます。

導入の順序——スモールスタートで規律を積む

5つの規律を一度に入れる必要はありません。効果とコストのバランスで、次の順に積むのがおすすめです。

1. まず可観測性（規律3）：現状を測れないと、何が過剰かも分からない。「誰が・何を・なぜ」のトレースから始める。
2. 次にドリフト監視（規律2）：未使用権限・過剰スコープを可視化し、剥がす候補を洗い出す。
3. 卒業を自動化（規律5）：しきい値を決めて、未使用権限の自動失効を回し始める。
4. 高リスク操作からJIT化（規律1）：削除・送金・本番書き込みなど、影響の大きい操作を都度付与に切り替える。
5. コストとして経営に接続（規律4）：過剰権限をブラストラジウス＝リスク＝監査負荷として可視化し、④コストの議論に載せる。

「まず測る→剥がす→自動で失効させる→都度付与に寄せる」。この順なら、既存運用を壊さずに、最小権限を維持する体力を少しずつ付けられます。

「権限が事故になったとき」の検知→切り戻し→監査

それでも、過剰権限が事故につながることはあります。そのときに効くのが、次の3段構えです。

段階	やること
検知（Detect）	異常な権限行使（普段使わない操作・想定外のリソース・急な範囲拡大）をトレースから検知する
切り戻し（Contain）	該当アイデンティティの権限を即時失効・隔離し、ブラストラジウスを止める（規律1・5の失効経路を流用）
監査（Audit）	「誰が・何を・なぜできたか」を再構成し、どのポリシー／付与が許したのかを特定して塞ぐ（規律3のトレースが根拠）

この3段が回るかどうかは、平時に規律1〜5を積んでいたかで決まります。可観測性がなければ検知できず、失効経路がなければ切り戻せず、許可のトレースがなければ監査で原因に辿り着けない——インシデント対応は、権限運用の答え合わせです。

権限運用チェックリスト

• エージェント／NHIの初期状態は「無権限」になっているか。
• 付与にTTL（有効期限）が付いているか。「無期限」を作っていないか。
• 破壊的・不可逆な操作は都度の昇格＋承認を通しているか。
• 未使用権限を継続監視し、しきい値で自動フラグ／自動失効しているか。
• 「設計図（付与）」と「実態（利用）」のドリフトを測っているか。
• 権限行使ごとに誰が・何を・なぜ・委任の連鎖を残しているか。
• タスク完了・プロジェクト終了に失効を紐づけているか。
• 孤児NHI（所有者不明・利用実績ゼロ）を定期検出しているか。
• 過剰権限をブラストラジウス＝コスト＝リスクとして説明できるか。
• 事故時に即時失効→原因ポリシー特定まで辿れるか。

よくある質問（Q&A）

Q1. 最小権限を最初にきちんと設計すれば、運用の話は要らないのでは？
設計は出発点にすぎません。最小権限は「設計した瞬間」がピークで、運用の中で膨張・陳腐化します。維持するには、ドリフト監視と失効を回し続ける必要があります。

Q2. JIT（都度付与）は、エージェントの動作を遅くしませんか？
都度付与を自動化すれば、体感の遅延はほぼ生じません。人手の承認を挟むのは、削除・送金・本番書き込みなど高リスク操作に限定します。低リスク操作は自動で付与・失効させます。

Q3. 「NHI管理」や「権限エスカレーション防止」の記事と、何が違うのですか？
それらはアイデンティティの棚卸しや攻撃の阻止といったセキュリティ実装の層です。⑥は、付与・行使・棚卸し・失効を日々回す運用規律の層に集中します。守る対象ではなく、回し方の話です。

Q4. 使っていない権限を残しておくのは、そんなに悪いことですか？
はい。未使用権限は事故時のブラストラジウスを押し上げ、監査負荷を増やし、漏洩・悪用のリスクを積み増します。「念のため残す」は、維持費とリスクを払い続ける在庫です。

Q5. まず何から手をつければいいですか？
可観測性（誰が・何を・なぜできたか）から始めてください。現状を測れて初めて、過剰権限が見え、剥がす判断ができます。その後、ドリフト監視→自動失効→高リスク操作のJIT化、の順に積むのがおすすめです。

まとめ——「付ける」を「運用する」に変える

要点は3つです。

1. 最小権限は生もの。 設計した瞬間がピークで、運用しなければ膨張・陳腐化する。JITで常設を減らし、ドリフト監視でズレを測り、卒業で確実に剥がす——この往復運動が最小権限を維持する。

2. 過剰権限はコストである。 ブラストラジウス＝監査負荷＝リスクとして、使っていない権限も維持費を払い続けている。④コストと同じ発想で、権限を「在庫」として圧縮する。

3. 可観測性が全ての土台。 「誰が・何を・なぜできたか」を残せていれば、ドリフトも測れ、事故時にも即時失効と原因特定ができる。まず測ることから始める。

権限は、エージェントが「何をできるか」を規定する運用の結節点です。②評価・③観測・④コスト・⑤メモリで積んできた規律を、「権限」という軸で束ね直す——それが、付けたら付けっぱなしを事故にしないための運用設計です。

参考リンク

• OWASP — Non-Human Identities Top 10
• OWASP — Top 10 for LLM Applications（Excessive Agency ほか）
• NIST SP 800-207 — Zero Trust Architecture
• CSA（Cloud Security Alliance）— Non-Human Identity Management

関連記事：AgentOps⑤・メモリ——「覚えるほど賢くなる」が裏返るとき／NHI管理・権限エスカレーション防止・Confused Deputy対策・鍵管理・人間承認レイヤーの各記事もあわせてどうぞ。