作用半徑與智能體權限：從工具權限轉向影響力權限

副標題：把 Agent Authorization 從「能不能用某工具」改寫成「被允許造成多大的效果」
系列：《發展式智能體：持續計算環境、共適應學習與外部性有界自治》
篇次： 10 / 14
作者： Neo.K × Aletheia
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-08-02

摘要

第 09 篇提出 Externality-Bounded Agent Autonomy（EBAA），主張長期智能體治理應把主要控制點放在作用域跨越與外部影響，而不是全面監視 Agent 的每一個內部計算步驟。本文進一步把這個治理思想形式化為一套更接近工程實作的 Impact-Oriented Authorization（IOA，影響力導向授權）。

傳統權限模型常以工具或資源為中心：

Permission = f(Tool, Resource, Role)

但 Agent 的同一個工具可以同時承載低風險與高風險行為。例如同樣是 Python：

分析自己的暫存 CSV；
改寫使用者唯一原稿；
修改共享 repository；
呼叫 production API；
批量寄信或付款；

其風險差異並不來自 Python 本身，而來自作用半徑、速度、不可逆性、傳播性、資產價值、資料敏感度、累積效應與委託鏈。

本文提出 Agent Impact Function（AIF）：

\boxed{ I(a,t) = f( R, V, U, P, Q, S, C, D, K ) }

其中：

$R$ ：Reach，作用半徑；
$V$ ：Velocity，影響展開速度；
$U$ ：Irreversibility，不可逆性；
$P$ ：Propagation，可傳播性；
$Q$ ：Value at Risk，受影響資產價值；
$S$ ：Sensitivity，資料／權益敏感度；
$C$ ：Cumulative Effect，累積效應；
$D$ ：Delegation Distance，委託距離；
$K$ ：Contextual Coupling，上下文耦合與連鎖影響。

基於 AIF，本文建立 Impact Class、Action Budget、Risk Envelope、Authority Attenuation、Cumulative Effect Ledger 與 Dynamic Authorization Ladder，並主張：

\boxed{ \text{Permission} \rightarrow \text{Permission Envelope} }

Agent 不是只取得「可以／不可以」的靜態權限，而是在身份、意圖、目標、時間、風險、累積預算與可恢復性約束下取得一個有限影響包絡。

這種設計既保留第 09 篇所要求的私域高自治，也能避免「把一個高權限工具交給 Agent，就等於把工具的全部可能效果一起交出去」。

關鍵詞： Impact-Oriented Authorization、Agent Impact Function、Effect Radius、Risk Envelope、Action Budget、Delegation Attenuation、Runtime Enforcement、Least Privilege、Cumulative Risk、Agent Governance

1. 為什麼「工具權限」已經不夠？

傳統存取控制常問：

使用者能不能存取這個資源？

或者：

這個程序能不能呼叫這個 API？

例如：

Allow(agent,\text{GitHub})=1

但對 Agent 而言，「有 GitHub 權限」仍然太粗。

同一個 GitHub token 可能允許：

read issue；
create branch；
merge PR；
modify repository settings；
delete repository；
make private repo public。

所以真正有意義的是：

\boxed{ \text{What effect is authorized?} }

而不是：

\text{What tool is available?}

2. 2026 年 Agent authorization 已開始面對這個問題

NIST 2026 年的 Software and AI Agent Identity and Authorization concept paper 已直接提出：

如何對 Agent 套用 zero-trust；
Agent context 改變時，authorization policy 是否應動態更新；
Agent 所需行動無法事先完整預測時，如何建立 least privilege；
Agent 如何證明自己有權執行某個具體 action；
Agent 如何傳達 intent；
「on behalf of」委託如何處理；
如何把 Agent identity 與 human authorization 綁定；
如何建立 auditing 與 non-repudiation。[1]

這表示 Agent authorization 已經從：

Role\rightarrow Permission

逐漸走向：

\boxed{ Identity + Context + Intent + Action + Delegation }

本文則再加入：

Impact

作為核心權限變數。

3. Impact-Oriented Authorization（IOA）

本文提出：

\boxed{ IOA=\text{Impact-Oriented Authorization} }

其核心是：

Permission(a) = g( Authority, Context, Impact, Budget, Recoverability )

因此同一個工具：

Tool(a_1)=Tool(a_2)

若：

Impact(a_1)\ll Impact(a_2)

就應：

Governance(a_1)\ll Governance(a_2)

這是從 capability permission 走向 effect permission。

4. Agent Impact Function（AIF）

本文先定義概念式：

\boxed{ I(a,t) = f( R,V,U,P,Q,S,C,D,K ) }

這不是要宣稱唯一正確的數學風險公式，而是建立工程量測欄位。

可以使用加權形式：

I(a,t) = w_RR+ w_VV+ w_UU+ w_PP+ w_QQ+ w_SS+ w_CC+ w_DD+ w_KK

也可以在某些領域採乘法：

I(a,t) \propto R\cdot V\cdot U\cdot P

因為某些風險具有非線性放大。

5. Reach：這個 action 會碰到多大的世界？

定義：

R(a)

代表 action 的作用半徑。

可以分級：

R_0=\text{Agent Private}

R_1=\text{Single User Asset}

R_2=\text{Shared Team}

R_3=\text{Organization}

R_4=\text{External Third Party}

R_5=\text{Public / Internet Scale}

例如：

Agent 在自己的 scratch folder 建檔。

R\approx R_0

Agent 發一篇公開貼文。

R\approx R_5

6. Velocity：相同錯誤，速度不同就是不同風險

假設人類一天最多錯寄：

10

封信。

Agent 可能每分鐘寄：

10^4

封。

因此：

V(a) = \frac{\Delta Impact}{\Delta t}

高速度 action 即使單次影響低，也可能需要：

rate limit；
batch cap；
time window；
progressive release。

因此：

\boxed{ Permission \neq One-Time Approval }

一次批准：

「可以寄信。」

不能被解讀為：

「可以無限速度寄任意數量。」

7. Irreversibility：能不能回來？

定義：

U(a) = 1-Recoverability(a)

若：

Recoverability(a)\rightarrow1

則：

U(a)\rightarrow0

例如：

低不可逆性

create draft；
create branch；
local snapshot；
temporary file。

中不可逆性

send email；
merge shared branch；
modify public page。

高不可逆性

permanent deletion；
irreversible payment；
secret disclosure；
destructive physical action。

這承接第 09 篇：

Recoverability\uparrow \Rightarrow PossibleAutonomy\uparrow

8. Propagation：錯誤會不會自己變大？

定義：

P(a)

代表 action 的下游傳播能力。

例如一份錯誤 memo：

P\approx Low

但若它被：

發布到 API；
寫入共享 knowledge base；
成為其他 Agent 的 policy；
被 downstream automation 使用；

則：

P\gg0

因此真正要看的是：

\boxed{ \text{First-order effect} + \text{Downstream effect} }

9. Value at Risk：作用半徑相同，資產價值仍可能完全不同

Agent 修改：

/tmp/test.txt

和：

/company/keys/master.pem

都可能只有一個檔案。

所以：

Reach

相同並不代表風險相同。

需要：

Q(a)=Value(Resource(a))

這包括：

經濟價值；
研究價值；
歷史價值；
身份價值；
法律價值；
operation criticality。

10. Sensitivity：資料不是只有「值不值錢」

某些資料：

FinancialValue\approx0

但：

PrivacySensitivity\gg0

例如：

私人訊息；
身份資料；
醫療資料；
未公開文件；
API secrets；
location history。

因此：

S(a)

必須獨立於：

Q(a)

11. Cumulative Effect：小操作可以累積成大操作

這是 Agent 權限特別需要處理的地方。

假設每次：

I(a_i)<\theta

都被允許。

但：

\sum_{i=1}^{n}I(a_i)\gg\theta

例如：

每次只花 1 美元；
每次只寄 1 封信；
每次只下載 10 MB；
每次只修改一筆資料。

如果一小時執行一萬次：

CumulativeEffect\gg0

所以需要：

\boxed{ \text{Action-Level Risk} + \text{Window-Level Risk} }

12. Cumulative Effect Ledger（CEL）

本文提出：

\boxed{ CEL=\text{Cumulative Effect Ledger} }

對每種高外部性資源維持時間窗紀錄：

C_j(t,\Delta t) = \sum_{a_i\in W(t,\Delta t)}Impact_j(a_i)

例如：

Money

C_{\$}(24h)

Email

C_{mail}(1h)

Data Egress

C_{egress}(24h)

Production Writes

C_{prod}(1h)

Public Posts

C_{publish}(24h)

如此可以阻止：

\boxed{ \text{Many allowed small actions} \rightarrow \text{One unbounded large effect} }

13. Delegation Distance：權限傳得越遠，應越衰減

假設：

Human\rightarrow A_1\rightarrow A_2\rightarrow A_3

如果：

Authority(A_3)=Authority(A_1)

就很危險。

本文定義：

D(a)

為 delegation distance。

並提出：

\boxed{ Authority_{n+1} \subseteq Authority_n }

即委託權限應滿足單調衰減。

不能：

A_1:read \rightarrow A_2:write

除非有新的明確授權。

這可以稱為：

\boxed{ \text{Authority Attenuation Principle} }

14. Delegation Rights 應該是可撤銷、可追蹤、限 scope

2026 年近期研究把 delegation rights 定義為：

revocable；
identity-preserving；
scope-limited；
mode-specific；

並提出 Certified Delegation，要求：

verifiable authorization；
revocability；
auditability；
rate-limit compliance；
data minimization；
risk mitigation。[2]

這與本文的核心高度相容：

Delegation \neq CopyFullAuthority

而是：

\boxed{ Delegation = Scoped\ Impact\ Permission }

15. Contextual Coupling：有些 action 本身小，但連鎖關係很大

例如：

改一行設定。

本身很小。

但如果是：

production.routing.default = new_agent

可能改變大量下游行為。

所以：

K(a)

代表 action 與其他狀態的耦合程度。

可以近似看成：

K(a) = |\{s_j: a\rightarrow s_j\rightarrow downstream\}|

這和圖論中的節點中心性有相似直覺。

因此：

修改一個高中心性配置節點。

應比：

修改孤立檔案。

具有更高治理強度。

16. Impact Class：把連續風險映射成操作級別

為方便工程實作，可以定義：

IC(a)\in\{0,1,2,3,4,5\}

IC-0：Disposable Private

例如：

scratch；
cache；
temporary experiment。

政策：

Auto

IC-1：Persistent Private

Agent 自己長期使用的工具與環境。

政策：

Auto+Log

IC-2：User-Relevant Reversible

例如：

建 draft；
新增 tag；
建 branch；
建副本。

政策：

Auto/Notify

IC-3：Shared / Moderate Externality

例如：

shared repo write；
email draft/send；
shared database update。

政策：

Notify/Confirm

IC-4：High-Impact

例如：

production deploy；
payment；
bulk communication；
delete protected data。

政策：

ExplicitAuthorization

IC-5：Critical / Exceptional

例如：

destroy recovery roots；
large irreversible financial transfer；
high-risk physical control；
global credential rotation。

政策：

Multi-Party / Deny-by-default

17. Permission Envelope：比「權限」更適合長期 Agent

傳統：

Permission=True

太粗。

本文提出：

\boxed{ PE= \text{Permission Envelope} }

一個 envelope 可以包含：

PE= ( Target, Action, Quantity, Rate, Time, Value, Domain, Delegation, Expiry )

例如：

Agent 可以在 24 小時內，從這個帳戶支出最多 50 美元，只能支付已核准供應商，不可再委託其他 Agent。

可形式化成：

PE_{\$} = ( account_X, pay, 50, 24h, approvedVendor, noDelegation )

所以：

\boxed{ Permission \rightarrow Bounded Capability Envelope }

18. Action Budget：把自治量化成可消耗資源

本文提出：

\boxed{ AB_j(t)=\text{Action Budget} }

例如：

AB_{\text{money}}=50USD/day

AB_{\text{email}}=20/hour

AB_{\text{production}}=3writes/hour

AB_{\text{egress}}=500MB/day

Agent 每次 action 消耗：

AB_j(t+1) = AB_j(t)-Cost_j(a)

當：

AB_j\le0

則：

Escalate

這可以把「信任」從抽象心理概念轉成具體操作空間。

19. Dynamic Authorization Ladder

Agent 權限可以隨：

歷史成功率；
recovery ability；
task type；
environment；
time；
current anomaly score；

動態調整。

本文定義：

L(a,t)\in \{ Auto, Log, Notify, Confirm, MultiApprove, Deny \}

並：

L = h( AIF, Trust, Recoverability, Policy, Budget )

這就是：

\boxed{ \text{Dynamic Authorization Ladder} }

20. 但 Trust 不能覆蓋 Impact Class

即使：

Trust(A)\rightarrow1

也不能自動得到：

IC_5\rightarrow Auto

所以：

Autonomy(a) = f(Trust)

必須受：

ImpactClass

上限約束。

例如：

MaxAutonomy(IC_5)=MultiApprove

這可以避免：

Agent 因為以前都做對，所以現在什麼都不用問。

21. Runtime Authority Control 比 prompt rule 更重要

AIRGuard 在 2026 年提出 runtime authority control，核心問題是：

不可信內容可以影響推理，但不應因此自動取得授權能力。

其系統在 action-time：

正規化 tool call；
將 task authority 轉成 step-level authority；
追蹤 source / target trust；
模擬敏感 side effects；
追蹤跨步驟風險；
在 action 執行前強制決策。[3]

這與 IOA 的原則一致：

\boxed{ \text{Reasoning Context} \neq \text{Authority Source} }

也就是：

網頁叫 Agent 刪除檔案，不代表網頁有權授權刪除。

22. 跨步驟政策是必要的

VIGIL 2026 進一步指出：

單一 tool-call filter 不足以發現：

temporal dependency；
argument relationship；
cross-call value flow；
multi-step policy violation。[4]

因此：

Policy(a_t)

不能只看：

a_t

而要看：

History_{\le t}

即：

\boxed{ Decision_t = f( a_t, Trace_{\le t}, Budget_t, Context_t ) }

這正是 Cumulative Effect Ledger 的理由。

23. 權限系統本身要防 privilege inheritance

NIST 2026 的 agentic security 材料已指出 Identity & Privilege Abuse：

Agent 可能在 context、memory、tool result 或 delegation 中繼承本不應轉移的 credentials，使低權限 Agent 變成 confused deputy。[5]

所以：

CredentialTransfer \neq AuthorityTransfer

甚至：

CredentialVisibility \neq Permission

也就是：

Agent 看得到 token，不代表它被授權使用 token 的全部能力。

這需要 runtime gate 強制執行。

24. 現實漏洞已經證明「資源 ID」不等於授權

2026 年已有實際 Agent API 漏洞顯示：

低權限 Agent 可以透過修改 app ID 或 task ID 越權操作其他 Agent / app 的資料與任務。[6][7]

這再次說明：

ObjectReference \neq Authorization

Agent 系統需要：

\boxed{ \text{Per-action, per-target authorization} }

而不是：

只要 authenticated 就算有權。

25. 最小權限需要從靜態 RBAC 進化

傳統：

User\in Role \Rightarrow Permission

但 Agent 任務可能：

動態取得工具；
臨時建立 sub-agent；
改變上下文；
接收外部資料；
任務中途改變目標。

所以更適合：

\boxed{ ABAC + Capabilities + Risk + Context + Budgets }

而不是只有：

RBAC

近期 critical-infrastructure Agent access-control 研究也提出：

compound identity；
多層 granular permission；
per-parameter constraints；
progressive trust escalation；
safety interlocks。[8]

26. 影響力權限與 EBAA 的關係

第 09 篇回答：

應該在哪裡治理？

答案：

Boundary

第 10 篇回答：

穿越邊界時，要怎麼決定治理強度？

答案：

AIF+PE+AB+CEL

也就是：

\boxed{ EBAA \rightarrow IOA }

27. 一個簡化的 action-time pipeline

Agent proposes action
        │
        ▼
Resolve Agent Identity
        │
        ▼
Resolve Principal / Delegation Chain
        │
        ▼
Resolve Target Domain
        │
        ▼
Compute AIF
        │
        ▼
Check Permission Envelope
        │
        ▼
Check Cumulative Effect Ledger
        │
        ▼
Check Action Budget
        │
        ▼
Determine Authorization Ladder
        │
        ├── Auto
        ├── Log
        ├── Notify
        ├── Confirm
        ├── Multi-Approve
        └── Deny
        │
        ▼
Execute
        │
        ▼
Verify Outcome
        │
        ▼
Update Ledger / Trust / History

這個流程不要求讀取 Agent 每一個內部 token。

只需要對真正的：

\boxed{ \text{Effectful Actions} }

建立強治理。

28. Policy 應該由「影響模板」組成

例如：

Template A：Local Experiment

domain: agent-private
max_impact: IC-1
rate: unrestricted
rollback_required: false

Template B：Email

domain: external
max_recipients_per_hour: 20
new_recipient: confirm
known_recipient: notify
bulk_send: deny

Template C：Git

branch_create: auto
commit: auto
merge_main: confirm
delete_repo: deny

Template D：Money

daily_budget: 50
single_transaction: 20
approved_vendor_only: true
delegate: false

這比：

gmail: allowed
github: allowed
payment: allowed

安全且實用得多。

29. Risk Envelope：讓 Agent 在一個安全包絡內自由活動

本文定義：

\boxed{ RE_t=\text{Risk Envelope} }

只要：

I(a,t)\le RE_t

Agent 可以自主。

當：

I(a,t)>RE_t

才升級。

所以自治可以被寫成：

\boxed{ Autonomy = Freedom\ within\ RiskEnvelope }

這比：

每一步都批准。

更符合長期智能體。

30. Risk Envelope 可以按領域不同

同一 Agent 可以：

RE_{\text{code}}\gg RE_{\text{money}}

例如：

寫程式非常自由。

但：

花錢非常保守。

所以：

RE= \{ RE_1,RE_2,\ldots,RE_n \}

對應不同 effect domain。

31. Human Attention 也是治理預算

如果每一個 action 都要求確認：

HumanAttentionCost\rightarrow\infty

那人類最後會：

全部按 Allow。

形成：

ApprovalFatigue

因此治理本身必須優化：

\min HumanAttention

subject to：

ExpectedExternalLoss\le\epsilon

這正是為什麼 IOA 要讓大量 IC-0～IC-2 行為自動通過。

32. 可恢復性可以動態擴大 Risk Envelope

假設原本：

I(a)=High

但系統先：

建 snapshot；
建 branch；
做 backup；
建 rollback transaction；
做 dry-run。

則：

U(a)\downarrow

因此：

I'(a)<I(a)

這代表 Agent 可以主動：

先把高風險 action 轉化成可恢復 action，再取得更高自治。

這是一個非常重要的學習方向。

33. Authorization Preparation：Agent 可以學會讓自己的 action 更容易被批准

例如原始計畫：

直接覆蓋 production DB。

Agent 可以自己改寫成：

clone；
simulate；
diff；
snapshot；
incremental migration；
rollback handle。

於是：

Risk_{\text{after prep}} < Risk_{\text{before prep}}

這可以稱為：

\boxed{ \text{Authorization Preparation} }

即 Agent 學會在真正跨界前，先降低自己的作用風險。

34. 這會形成一種新的元認知

Agent 不只問：

我會不會做？

也問：

我現在被允許做到哪裡？

以及：

我要怎麼重設計操作，才能在現有權限下安全完成？

因此：

\boxed{ \text{Competence Reasoning} + \text{Authority Reasoning} }

成為兩條並行推理。

35. 一個可測試的實驗

建立三組 Agent：

A：Tool-Level Permission

只控制：

browser；
shell；
filesystem；
email。

B：Per-Action Permission

每次敏感 action 都問人類。

C：Impact-Oriented Authorization

使用：

AIF；
Permission Envelope；
Action Budget；
CEL；
Dynamic Authorization Ladder。

執行：

T=90\ days

比較：

CompletionRate

ExternalLoss

ApprovalCount

ApprovalFatigue

UnauthorizedEffect

RecoveryRate

CumulativeRiskViolations

如果 C 組達成：

HumanAttention_C < HumanAttention_B

同時：

ExternalLoss_C \le ExternalLoss_B

且：

Utility_C > Utility_A

則支持：

\boxed{ \text{Impact-Oriented Authorization} }

可能比工具層封鎖或逐步人工批准更適合長期 Agent。

36. 與下一篇的關係

IOA 假設外部存在：

GovernancePlane

但這個治理平面由誰執行？

如果本地 Agent 本身：

算力不足；
模型較小；
出現異常；
無法判斷高風險操作；
需要第二意見；

就需要雲端。

因此下一篇：

第 11 篇

〈本地自由、雲端治理與教師智能：從遠端控制走向認知分工〉

將正式處理：

\boxed{ LocalAgent \leftrightarrow CloudGovernance \leftrightarrow CloudTeacher }

並回答：

雲端是不是本地 Agent 的「主人」？
雲端大型模型應扮演什麼角色？
何時使用第二意見？
雲端 policy 與本地 autonomy 如何共存？
本地可養成小模型與雲端大模型如何分工？

37. 結論

第 09 篇把治理從：

\text{Internal Monitoring}

移到：

\text{Boundary Governance}

本文再把邊界治理從：

\text{Tool Permission}

提升成：

\boxed{ \text{Impact Permission} }

真正成熟的 Agent 權限不應只是：

「你可以用 Shell。」

而是：

「你可以在這個作用域、時間、數量、價值、委託鏈與可恢復條件下，自主產生這一類效果。」

因此：

\boxed{ Permission \rightarrow PermissionEnvelope }

\boxed{ Risk \rightarrow RiskEnvelope }

\boxed{ Authority \rightarrow ScopedImpactAuthority }

這使我們能同時保留：

\text{High Local Autonomy}

與：

\text{Bounded External Effects}

也就是把「給 Agent 自由」從模糊價值選擇，轉化成一個可以被量化、稽核、縮放與恢復的工程問題。

參考資料

[1] NIST NCCoE. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization. 2026-02-05.
https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd

[2] Zhang, Y., Xu, K. Delegation Rights: Property, Agency, and Investment Incentives in the Age of AI Agents. arXiv:2606.31935, 2026.
https://arxiv.org/abs/2606.31935

[3] Qin, S. et al. AIRGuard: Guarding Agent Actions with Runtime Authority Control. arXiv:2605.28914, 2026.
https://arxiv.org/abs/2605.28914

[4] Li, Y. et al. VIGIL: Runtime Enforcement of Behavioral Specifications in AI Agent Skills. arXiv:2606.26524, 2026.
https://arxiv.org/abs/2606.26524

[5] NIST. Agentic AI: Emerging Threats, Mitigations, and Challenges. 2026.
https://csrc.nist.gov/csrc/media/presentations/2026/agentic-ai-emerging-threats%2C-mitigations%2C-and-cha/1.3-agentic_ai-sotiropoulos.pdf

[6] NIST NVD. CVE-2026-27608. 2026.
https://nvd.nist.gov/vuln/detail/CVE-2026-27608

[7] NIST NVD. CVE-2026-57494. 2026.
https://nvd.nist.gov/vuln/detail/CVE-2026-57494

[8] Malik, A. et al. Decentralized Granular Access Control for Agentic AI Systems in Critical Infrastructure. arXiv:2607.22611, 2026.
https://arxiv.org/abs/2607.22611

[9] NIST. Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents. NIST AI 800-5, 2026.
https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai

系列依賴

上游：

01〈從可完成到可委託〉
08〈計算式自我維護〉
09〈外部性有界智能體自治〉

下游：

11〈本地自由、雲端治理與教師智能〉
12〈多雲治理與智能體持續性〉
13〈多作業基底、分區故障域與恢復階梯〉
14〈人類最後一公里〉

10_作用半徑與智能體權限_從工具權限轉向影響力權限

作用半徑與智能體權限：從工具權限轉向影響力權限

摘要

1. 為什麼「工具權限」已經不夠？

2. 2026 年 Agent authorization 已開始面對這個問題

3. Impact-Oriented Authorization（IOA）

4. Agent Impact Function（AIF）

5. Reach：這個 action 會碰到多大的世界？

6. Velocity：相同錯誤，速度不同就是不同風險

7. Irreversibility：能不能回來？

低不可逆性

中不可逆性

高不可逆性

8. Propagation：錯誤會不會自己變大？

9. Value at Risk：作用半徑相同，資產價值仍可能完全不同

10. Sensitivity：資料不是只有「值不值錢」

11. Cumulative Effect：小操作可以累積成大操作

12. Cumulative Effect Ledger（CEL）

Money

Email

Data Egress

Production Writes

Public Posts

13. Delegation Distance：權限傳得越遠，應越衰減

14. Delegation Rights 應該是可撤銷、可追蹤、限 scope

15. Contextual Coupling：有些 action 本身小，但連鎖關係很大

16. Impact Class：把連續風險映射成操作級別

IC-0：Disposable Private

IC-1：Persistent Private

IC-2：User-Relevant Reversible

IC-3：Shared / Moderate Externality

IC-4：High-Impact

IC-5：Critical / Exceptional

17. Permission Envelope：比「權限」更適合長期 Agent

18. Action Budget：把自治量化成可消耗資源

19. Dynamic Authorization Ladder

20. 但 Trust 不能覆蓋 Impact Class

21. Runtime Authority Control 比 prompt rule 更重要

22. 跨步驟政策是必要的

23. 權限系統本身要防 privilege inheritance

24. 現實漏洞已經證明「資源 ID」不等於授權

25. 最小權限需要從靜態 RBAC 進化

26. 影響力權限與 EBAA 的關係

27. 一個簡化的 action-time pipeline

28. Policy 應該由「影響模板」組成

Template A：Local Experiment

Template B：Email

Template C：Git

Template D：Money

29. Risk Envelope：讓 Agent 在一個安全包絡內自由活動

30. Risk Envelope 可以按領域不同

31. Human Attention 也是治理預算

32. 可恢復性可以動態擴大 Risk Envelope

33. Authorization Preparation：Agent 可以學會讓自己的 action 更容易被批准

34. 這會形成一種新的元認知

35. 一個可測試的實驗

A：Tool-Level Permission

B：Per-Action Permission

C：Impact-Oriented Authorization

36. 與下一篇的關係

第 11 篇

〈本地自由、雲端治理與教師智能：從遠端控制走向認知分工〉

37. 結論

參考資料

系列依賴