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

**副標題：把 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 修改：

```text
/tmp/test.txt
```

和：

```text
/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 本身小，但連鎖關係很大

例如：

> 改一行設定。

本身很小。

但如果是：

```text
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

```text
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

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

### Template B：Email

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

### Template C：Git

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

### Template D：Money

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

這比：

```yaml
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 可以自己改寫成：

1. clone；
2. simulate；
3. diff；
4. snapshot；
5. incremental migration；
6. 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〈人類最後一公里〉