AIエージェントの「権限」は、なぜすぐ腐るのか

AIエージェントに「この仕事を任せる」と決め、必要な権限を与える。ここまでは比較的分かりやすい話です。

難しかったのは、その権限を24時間、数日、数週間と使い続けることでした。

Netsujoでは、ChatGPT、Codex、Claude Codeなど複数のAIを使い、Controllerが現在状態、担当、権限、Evidence、停止理由、復旧条件を管理する運用を続けています。Controllerはソフトウェア開発・運用のAgent制御基盤で、オンチェーン資産を扱う本番金融システムではありません。本稿のオンチェーン金融に関する議論は、公開仕様・研究との比較に基づく設計上の考察です。運用で繰り返し起きたのは、AIの判断品質だけの問題ではありませんでした。

昨日は正しかった権限が、今日も正しいとは限らない。

コードが変わる。実行環境が変わる。証拠が期限切れになる。前回の操作結果が分からない。再起動をまたぐ。こうした変化のたびに、権限を成立させていた前提が崩れます。

本稿では、この状態を平易に「権限が腐る」と呼びます。

焦点は、権限の上限を広げず、安全条件を保ったまま、変化する環境の中で実行可能性を継続する方法です。

2026年7月に公開されたプレプリントでは、長寿命AIエージェントの authorization continuity が研究課題として定式化されています。Ethereum周辺でも、Account Abstractionの再validation、AI Agent向けのtransaction-scoped attestation、時間・金額上限付きmandateが議論されています。

AIエージェント運用とオンチェーン金融は、同じ難所に近づいています。

「権限がある」は、一つの事実ではありません

「Ownerが許可した」「署名が正しい」「Agentにroleが付いている」。どれも重要ですが、それだけでは実行時の権限を説明できません。

Controllerを運用すると、実際には次のような条件を同時に見ます。

• 権限を受けた主体は、いま動いている主体と同じか
• 実行するコードやbinaryは、検証したものと同じか
• source HEADは、QC対象と一致しているか
• receiptやattestationはまだ有効か
• policyは発行時から変わっていないか
• restart後も同じgeneration・状態を引き継いでいるか
• 前の外部操作は本当に未実行なのか

考え方を単純化すると、実行時のAuthorityは次の積として捉えられます。

Authority(t) = Grant × Subject Integrity(t) × Runtime Integrity(t) × State Binding(t) × Evidence Freshness(t) × Policy Validity(t) × Outcome Certainty(t)

これは数学的な標準式ではなく、Netsujoで使っている設計上の見方です。どれか一つが成立しなければ、過去のGrantをそのまま実行権限として使いません。

重要なのは、Authorization at T0 と Authority at T1 は同じではないということです。

権限を腐らせる5つのDrift

実運用の問題を整理すると、権限の前提が崩れる経路は大きく5つに分けられます。

1. Subject Drift — 「誰に渡したか」が変わる

同じ名前のAgentでも、model、runtime、binary、実行host、起動generationが変われば、権限を与えたときに評価した主体と現在の主体が同一とは限りません。

2026年9月30日のController運用では、root側のbootstrap処理で、Git上では実行可能だったhelperのmodeがclone時の設定によって変化し、runtimeが期待するmetadataと一致しないためfail closedしました。修正後はsource HEAD自体が変わるため、以前のgenerationとauthorityをそのまま再利用せず、新しいsourceから作り直す必要がありました。

この事例では、Ownerの意思が同じでも、許可対象の実体が変わった時点でold authorityを流用できないと判断しました。

2. State Drift — 「何に対して許可したか」が変わる

レビューを通したHEADと、実行するHEADが違えば、そのレビューは現在の操作を正当化しません。

これはControllerでExact-head evidenceを持つ理由でもあります。

オンチェーン側にも似た問題があります。ERC-7562（2026年9月30日時点でReview）では、Account AbstractionのUserOperationについて、mempool受入前にfull validationを行い、bundle/blockへ含める前にも再度full validationを行うべき（should）としています。contract-based accountのvalidityはmutable stateへ依存でき、別のtransactionによって以前validだったUserOperationがinvalidになり得るためです。

一度validだったことは、現在もvalidであることを意味しません。

3. Evidence Drift — 「なぜ許せるか」の前提がずれる

receipt、attestation、QC、署名、計測値には鮮度と対象bindingがあります。既存の24時間運用でも、HEADが移動した後はold CI/QCを無効化し、fresh exact-head evidenceを取り直しました。

2026年9月29日のController修正では、provider runtimeへ渡すinstallation payloadがすでにcanonical formなのに、別の経路がraw inputとして再正規化しようとし、receipt issuance/readbackがfail closedする問題がありました。

証拠そのものを厳格にしても、発行・正規化・伝達・参照のどこかで前提がずれれば、正しい仕事まで止まります。

Evidenceは「あるか／ないか」だけでなく、どの対象に束縛され、どの表現で、いつまで有効かまで運用する必要があります。

4. Policy Drift — 「何を許したか」の意味が変わる

「このAgentに実行を許可する」というgrantがあっても、scope、destination、金額上限、Production可否、再委任可否が曖昧なら、時間が経つほど意味がずれます。

ERC-8226はDraft段階の提案で、トークン化された規制資産を扱うAI Agent向けのcompliance delegation layerとして、verified principalからon-chain agentへscope・時間・financial capを持つmandateを委任する設計を提示しています。

本稿の観点では、policyが変わったとき、古いgrantを更新で済ませるのか、再承認が必要なのかを分ける必要があります。

5. Outcome Ambiguity — 「前に何が起きたか」が分からない

外部APIに変更を送り、timeoutした。クライアント側には失敗に見える。しかし外部では成功しているかもしれない。

この状態で「失敗したからもう一度」と再実行すると、二重送信、二重課金、二重merge、二重migrationにつながります。

Controllerではこれを OUTCOME_UNCERTAIN として扱い、blind retryしません。

金融では二重送金などの副作用へ直結します。Error ≠ Not Executed. を前提に扱います。

失敗レスポンスを観測したことと、副作用が存在しないことは同じではありません。外部stateを一度見てeffectが見えなかっただけでも、遅延した元requestが後から成立する可能性があります。

安全にしたら、今度は止まりすぎました

Controllerでは、不確実なら止める、HEADが変わればEvidenceを取り直す、権限が分からなければfail closedする、という設計を積み重ねてきました。

このfail-closed設計は必要でした。ただ、長時間運用すると別の問題が現れます。

証拠が古くなる。runtimeが一時的に使えなくなる。restart後に再確認が必要になる。そのたびにControllerが止まり、人間が「再開」と入力する。

既存記事「AIエージェント開発で本当に難しいのは『状態管理』だった」では、recoverableなBLOCKED状態を人間が見回り、再開を押していた問題を扱いました。

ここで分かったのは、SafetyとLivenessは別のSLOだということです。

Safety failureは、やってはいけない操作を実行することです。

Liveness failureは、やってよい操作まで永続的に実行できなくなることです。

guardrailを増やすほどSafetyは上げやすくなります。一方で、そのguardrail自身が状態、期限、同期、依存関係を持てば、Livenessを壊す原因にもなります。

「安全だから止まる」で設計を終えると、人間が永遠に復旧係として残ります。

必要なのは「永続権限」ではなくAuthority Continuity

ここでいうAuthority Continuityは、権限の上限を広げず、状態・時間・再起動・証拠更新をまたいで、必要な権限だけを安全に継続させる性質です。権限を永久化する考え方ではありません。

2026年7月のプレプリント「Are You Still the Agent I Authorized?」は、長寿命Agentがlive grantの下で変化する問題を authorization continuity として定式化し、grant時にimmutable effect ceilingを固定するモデルを提案しています。

本稿では、Controller運用とオンチェーン金融の双方で扱う、もう少し広い運用概念としてAuthority Continuityという言葉を使います。標準化済みの正式用語として主張するものではありません。

設計上のポイントは、renewalとreauthorizationを分けることです。

自動renewalの候補

• 同じsource・同じbinaryを再hashする
• expiry到来後、対象・policy・effect ceilingが不変であることを再検証する
• restart後に同一generation・同一policyへ復帰したことを確認する
• 既存上限以下でEvidenceだけを更新する

自動renewalでは扱わない変更

• source HEADが変わる → fresh QC / reviewへ戻す
• privilegeが増える → reauthorization
• destinationが変わる → reauthorization
• 金額上限が増える → reauthorization
• policyの意味が変わる → reauthorization
• 未知のruntimeへ主体が移る → reauthorization
• 前回の副作用が確定できない → OUTCOME_UNCERTAINのままreconcileする

原則は、自動回復で既存の権限上限を越えないことです。

復旧の便利さを理由に、権限を黙って広げない。

ERC-8273が「長寿命authorizationを持たない」ことは示唆的です

ERC-8273もDraftですが、AI Agent向けにtransaction-scopedなattestationを提案しています。

この提案が面白いのは、identityだけでは「同じAgentがそのアカウントの背後に居続ける」ことを保証できないと明示している点です。さらに標準フローでは、active authorizationを一つのtransactionに閉じ込め、transaction終了時に消去します。長寿命・session型のattestationを持たせません。

ERC-8273はactive authorizationをoperation単位へ狭め、「権限が腐る時間」を短くする方向の設計と読めます。Authority Continuityそのものを直接解決する仕様だという主張ではありません。

しかし実際のAI Agentは、数秒で終わる一つのtransactionだけを仕事にしません。

市場を観測する。判断する。複数のAPIやwalletをまたぐ。bridgeやexchange、banking railと接続する。途中で再起動する。数時間後に次のactionへ進む。

そこで、transactionの外側にAuthority Continuityの問題が戻ってきます。

オンチェーン金融で必要になるのは「再試行」より「再照合」

Agentic Financeを考えると、OUTCOME_UNCERTAINは避けて通れません。

たとえば、

Agent → wallet → RPC → chain → bridge → exchange

と処理が続くとします。

途中で通信が切れたとき、Agentが持つべき状態は「失敗」だけではありません。

1. action IDを固定する
2. mutation前に実行予定をdurableに記録する
3. 実行する
4. 結果が分からなければOUTCOME_UNCERTAINへ移す
5. chain、nonce、tx hash、counterparty APIなど外部stateを照合する
6. 実行済みならreceiptとstateを確定する
7. retryは、元の実行がもう成立し得ないことを確認できた場合、または同じaction ID / idempotency key / nonceで重複効果を拒否できる場合に限る
8. 判定できなければOUTCOME_UNCERTAINに留める。retry直前にはAuthorityをcurrent stateへ再bindする

これは reconciliation-aware execution の考え方です。

finalityに達したblockに含まれたtransaction receiptは強力なEvidenceになります（tx hashだけでは実行の証明になりません）。一方で、off-chain intentからon-chain settlementまでの全境界が同じtransaction semanticsを持つわけではありません。

オンチェーン化しても、境界の外側にある「結果不明」は残ります。

Persistent authorizationには、逆方向のリスクもあります

権限が早く腐るとLivenessが落ちます。

古い権限を残し続けると、逆方向のリスクが生じます。

2026年9月27日にarXivへ投稿されたプレプリント「When Consent Outlives Context」は、長寿命Agentで承認が元のcontextより長く残ることで residual authority が再利用される問題を検証しています。これは一つの研究結果であり、そのまま全システムへ一般化はできませんが、重要な対称性を示します。

• 早く失効させすぎると、正しい仕事が止まる
• 長く残しすぎると、古い承認が別contextで再利用される

Authority Continuityの要点は、必要なAuthorityだけを現在のcontextへ再束縛し続けることです。

オンチェーン化で検証可能になる範囲と、残る範囲

ブロックチェーンは、grant、nonce、cap、revocation、settlement、evidence commitmentを第三者が検証できる形で持つのに向いています。

しかし、次のことまで自動的に証明してくれるわけではありません。

• いま動いているmodel/runtimeが、評価したものと同じか
• off-chain binaryが期待どおりか
• sourceとQC対象が一致しているか
• 外部APIのmutationが完了したか
• policy engineが正しい設定を読んでいるか

On-chain authorizationはAuthority stateの一部を独立検証可能にします。Authority Continuity全体は、on-chainとoff-chainをまたいで設計する必要があります。

Controller実運用から得た7つの原則

最後に、現在の設計判断を7つにまとめます。

1. Authority is state-bound

権限をAgentの名前だけでなく、source、runtime、policy、Evidenceなど現在stateへ束縛する。

2. Freshness must be explicit

いつまで、何が変わるまで有効なのかを曖昧にしない。

3. Renewal is not reauthorization

同じ上限のEvidence更新と、新しい権限の付与を同じ処理にしない。

4. Authority must never silently expand

自動回復やAgent自身のEvidenceによって、Ownerが設定したeffect ceilingを越えさせない。

5. Fail closed needs a recovery path

止める条件だけでなく、誰が何を確認すれば再開できるかまで設計する。

6. Safety and liveness are separate SLOs

不正実行を防げたかと、正しい仕事を継続できたかを別々に測る。

7. Unknown outcome must reconcile before retry

結果不明を「失敗」に丸めず、外部stateと照合してから次のmutationを決める。

長寿命Agentの難所は「権限付与」の後にあります

AI Agentに権限を与える方法は、かなり分かってきました。

scopeを狭くする。期限を付ける。金額上限を持たせる。operationへattestationを束縛する。現在stateを再validationする。

次の問いは、その権限を24時間、1週間、1年と安全に使い続けるにはどうすればいいのかです。

状態は変わります。コードは変わります。証拠は古くなります。外部システムは曖昧に失敗します。Agent自身も変わります。

Controllerを実運用してきて、長寿命Agentで最も重要だと考えているのが、Authorityを拡大せず、現在のstateへ再束縛し続けるAuthority Continuityです。

参考

• ERC-7562: Account Abstraction Validation Scope Rules（Review） — https://eips.ethereum.org/EIPS/eip-7562
• ERC-8273: Attestation-Gated Agentic Actions（Draft） — https://eips.ethereum.org/EIPS/eip-8273
• ERC-8226: Regulated Agent Mandate（Draft） — https://eips.ethereum.org/EIPS/eip-8226
• Are You Still the Agent I Authorized? Earned Authority under a Fixed Ceiling for Evolving Agents — https://arxiv.org/abs/2607.23586
• When Consent Outlives Context: Residual Authority Replay in Long-Lived Agents — https://arxiv.org/abs/2609.33910
• Netsujo「CodexとClaude Codeを並列で動かして分かった。AIエージェント開発で本当に難しいのは『状態管理』だった」 — https://netsujo.jp/blog/ai-controller-3months