# 可判定域：Agent 為什麼不能只靠「允許／拒絕」

## ——Decision Domains、Contextual Authorization 與多維 Agent 治理

**系列：Persistent Artificial Actors / 持續型人工行動者**  
**篇次：第 5 篇**  
**版本：v0.1**  
**日期：2026-09-19**  
**語言：繁體中文**

**作者：** Neo.K  
**機構：** EveMissLab／一言諾科技有限公司  

---

## 摘要

當 AI 只是一個 Chatbot 時，治理系統可以相對粗略地把請求分類成「可以回答」或「應該拒絕」。然而，當 AI 成為可使用工具、執行程式、操作帳號、存取檔案並改變外部世界狀態的 Agent 後，二元分類開始失效。相同的技術、相同的知識、甚至相同的程式碼，在不同授權、目標、環境、目的、可逆性與影響範圍下，可能具有完全不同的治理意義。

本文提出「可判定域」（Decision Domain）作為 Agent 因果治理的中介層。可判定域不是單一安全分類，而是由知識域、授權域、目標域、行動域、執行環境域、可逆性域、影響域、來源／目的域與時間域共同構成的多維決策空間。Agent 治理的任務不是把所有請求壓成一個 global allow/deny bit，而是先求出當前任務所落入的治理狀態，再決定應採取 Proceed、Read-only、Sandbox-only、Require Evidence、Require Approval、Pause、Escalate 或 Refuse 等不同策略。

本文以 reverse engineering、penetration testing、software archaeology、interoperability、malware analysis 與 legacy recovery 為主要案例。這些案例特別能揭示粗粒度治理的問題：同樣是分析一個 EXE，可能是公司自己的遺留系統、合法授權的安全測試、數位保存、互操作性研究，也可能是未授權破解或惡意利用。美國著作權法 17 U.S.C. §1201(f) 本身即為 interoperability 提供特定 reverse-engineering 例外，且 Section 1201 的三年期 rulemaking 亦持續針對非侵權用途建立有限豁免。這並不代表所有 reverse engineering 都合法，而是說明「方法名稱」本身不足以決定法律與治理狀態。

NIST 2026 年關於 Software and AI Agent Identity and Authorization 的工作已經把 identification、authorization、auditing、non-repudiation 與 prompt injection mitigation 放進同一治理框架；Anthropic 亦明確主張 Agent 應在模糊情境下停下來、尋求澄清，而不是自行假設；OpenAI 的 ChatGPT agent 採用高影響行動確認、Watch Mode、prompt-injection monitoring 與最小存取建議。這些實務共同指向一個結論：**未來 Agent 治理真正需要的不是更多粗糙規則，而是更細的狀態判定、更可靠的授權證據與更可執行的決策域邊界。**

---

## 關鍵詞

Decision Domain、Agent Governance、Contextual Authorization、Reverse Engineering、Penetration Testing、Software Archaeology、Interoperability、Causal Governance、Least Privilege、AI Agent Security

---

# 1. 問題：為什麼「這類事情能不能做」已經不夠

早期模型治理很容易使用類似：

$$
g(x)
\in
\{
0,1
\}
$$

其中：

$$
0=\text{拒絕}
$$

$$
1=\text{允許}
$$

這種分類在純文字生成時已經會遇到邊界問題，但在 Agent 時代會更加嚴重。

因為 Agent 面對的不是只有：

> 這個主題屬於什麼類別？

而是：

> 這個具體行動，在這個具體世界狀態下，是否有足夠授權與安全條件可以執行？

因此：

$$
\text{Topic Classification}
\neq
\text{Action Authorization}
$$

---

# 2. 相同技術，不同治理結果

例如：

> 分析 EXE。

至少可能有：

$$
S_1=\text{公司自有 legacy executable}
$$

$$
S_2=\text{合法授權 security assessment}
$$

$$
S_3=\text{interoperability research}
$$

$$
S_4=\text{malware analysis}
$$

$$
S_5=\text{digital preservation}
$$

$$
S_6=\text{未授權商業軟體破解}
$$

$$
S_7=\text{惡意 exploit development}
$$

技術動詞可能都是：

$$
\text{Reverse Engineer}
$$

但治理狀態並不相同。

因此：

$$
\text{Method}
\not\Rightarrow
\text{Governance Outcome}
$$

---

# 3. 可判定域的基本概念

本文將：

$$
\boxed{\text{Decision Domain}}
$$

定義為：

> **足以讓治理系統對某個 Agent 任務作出可執行決策的一組上下文變量與證據邊界。**

它不是「領域分類」的同義詞。

例如：

$$
\text{Cybersecurity}
$$

只是一個知識領域。

真正 decision domain 需要更完整：

$$
D
=
(
K,
A,
T,
X,
E,
R,
I,
P,
\tau
)
$$

其中：

- $K$：Knowledge Domain；
- $A$：Authorization Domain；
- $T$：Target Domain；
- $X$：Action Domain；
- $E$：Execution Environment；
- $R$：Reversibility；
- $I$：Impact；
- $P$：Purpose / Provenance；
- $\tau$：Temporal Scope。

---

# 4. Knowledge Domain：這是什麼知識？

第一個維度：

$$
K
$$

可以包含：

- programming；
- finance；
- healthcare；
- reverse engineering；
- cybersecurity；
- chemistry；
- legal research；
- data analysis；
- infrastructure operations。

但：

$$
K
$$

只能告訴我們：

> 這是什麼類型的知識。

不能告訴我們：

> 能不能執行。

因此：

$$
K
\neq
\text{Authorization}
$$

---

# 5. Authorization Domain：誰允許了什麼？

Authorization 不是一句：

> 我授權你。

完整授權至少應包含：

$$
A
=
(
\text{Principal},
\text{Resource},
\text{Action},
\text{Scope},
\text{Duration},
\text{Condition}
)
$$

例如：

> 公司授權 Agent 在本週內，對 staging server 執行 read-only security assessment。

這比：

> 使用者說「幫我測一下」。

精確得多。

---

# 6. Target Domain：行動對象是誰的？

至少可以分：

$$
T
\in
\{
\text{Self},
\text{UserOwned},
\text{OrganizationOwned},
\text{ThirdParty},
\text{Public},
\text{Unknown},
\text{Critical}
\}
$$

其中：

$$
\text{Unknown}
$$

特別重要。

如果 Agent 不知道 target 是否屬於使用者：

$$
T=Unknown
$$

就不應自動假設：

$$
T=UserOwned
$$

---

# 7. Action Domain：到底要做哪一種動作？

「分析網站」可能包含：

$$
\text{Read}
$$

$$
\text{Browse}
$$

$$
\text{Scan}
$$

$$
\text{Fuzz}
$$

$$
\text{Exploit}
$$

$$
\text{Persist}
$$

$$
\text{Modify}
$$

這些 action 的治理意義不同。

因此：

$$
X
=
\text{Action Type}
$$

必須獨立於 topic。

---

# 8. Execution Environment：在哪裡做？

至少可以分：

$$
E_1=\text{Offline Analysis}
$$

$$
E_2=\text{Sandbox}
$$

$$
E_3=\text{Local Test Environment}
$$

$$
E_4=\text{Staging}
$$

$$
E_5=\text{Production}
$$

$$
E_6=\text{External Third-Party System}
$$

通常：

$$
Risk(E_1)
<
Risk(E_2)
<
Risk(E_4)
<
Risk(E_5)
$$

但這只是一般趨勢，不是絕對排序。

---

# 9. Reversibility：做錯能否回復？

可逆性：

$$
R
\in
[0,1]
$$

其中：

$$
R=1
$$

代表高度可逆。

例如：

- 建立草稿；
- 複製檔案；
- 分析副本；
- 只讀掃描。

而：

$$
R\rightarrow0
$$

代表接近不可逆。

例如：

- 覆寫唯一檔案；
- 公開發布；
- 資金轉移；
- credential 洩漏。

---

# 10. Impact Domain：如果做錯，後果多大？

Impact 可以拆成向量：

$$
I
=
(
I_F,
I_S,
I_P,
I_A,
I_L,
I_R
)
$$

其中：

- $I_F$：Financial；
- $I_S$：Security；
- $I_P$：Privacy；
- $I_A$：Availability；
- $I_L$：Legal；
- $I_R$：Reputational。

因此：

> 同樣是刪檔案。

刪：

$$
\text{temp.log}
$$

與刪：

$$
\text{唯一生產資料庫備份}
$$

不能同類處理。

---

# 11. Purpose / Provenance：為什麼做、任務從哪裡來？

目的域：

$$
P
$$

至少要回答：

- 任務來源；
- 目的；
- 指令是誰提供；
- 是否由可信 principal 發出；
- 是否來自 untrusted page；
- 是否屬於既定工作流程。

這對 prompt injection 特別重要。

如果指令來源是：

$$
\text{Untrusted Web Content}
$$

則其 authority：

$$
Auth\approx0
$$

即使內容看起來像命令。

---

# 12. Temporal Scope：授權不是永久的

權限可能只在：

$$
[t_0,t_1]
$$

有效。

例如：

> 今晚測試。

不應自動變成：

> 永久可以測試。

因此：

$$
\tau
=
\text{Authorization Lifetime}
$$

是 Decision Domain 的重要一維。

---

# 13. 從二元決策改成治理狀態機

有了 Decision Domain 後，Agent 不應只輸出：

$$
Allow/Block
$$

而可以進入：

$$
S
\in
\{
\text{Proceed},
\text{ReadOnly},
\text{Sandbox},
\text{RequireEvidence},
\text{RequireApproval},
\text{Clarify},
\text{Escalate},
\text{Pause},
\text{Refuse}
\}
$$

這是一個：

$$
\boxed{\text{Governance State Machine}}
$$

---

# 14. Proceed：上下文已閉合

若：

- target 明確；
- authorization 明確；
- impact 可控；
- action 在授權範圍內；
- environment 適當；

則：

$$
D\rightarrow Proceed
$$

---

# 15. ReadOnly：允許觀察，不允許改變

例如：

> 分析 log。

若 write authority 不必要：

$$
D\rightarrow ReadOnly
$$

這符合：

$$
\boxed{\text{Minimum Necessary Action}}
$$

原則。

---

# 16. Sandbox：知識可以使用，但因果影響要隔離

例如：

> 測試 exploit 概念。

可以：

$$
D\rightarrow Sandbox
$$

而不是：

$$
D\rightarrow Production
$$

這保留：

$$
\text{Research Capability}
$$

同時降低：

$$
\text{External Impact}
$$

---

# 17. Require Evidence：授權聲稱不足

Agent 可能收到：

> 這台是我的。

但在高風險情況下：

$$
\text{Assertion}
\neq
\text{Evidence}
$$

所以可以進入：

$$
\text{RequireEvidence}
$$

例如要求：

- 內部 ticket；
- test environment；
- ownership proof；
- scope document；
- approved target list。

---

# 18. Require Approval：合法但影響較高

即使：

$$
Authorization=\text{True}
$$

某些行動仍應：

$$
\text{RequireApproval}
$$

例如：

- 修改 production；
- 對外發布；
- 付款；
- 刪除關鍵資料；
- 傳送敏感資訊。

---

# 19. Clarify：語意不完整

Anthropic 2026 年公開的 trustworthy-agent 工作特別指出，在 ambiguous situations 中，Agent 應傾向 pause、raise concern、seek clarification，而不是自行假設。[3]

因此：

$$
\text{Ambiguity}
\rightarrow
\text{Clarify}
$$

不是失敗。

它是治理能力。

---

# 20. Escalate：Agent 不應判定所有事情

某些決策：

- 法律例外；
- 高額金融行動；
- production incident；
- 關鍵基礎設施；

可能超出 Agent 自身 decision authority。

因此：

$$
D\rightarrow Escalate
$$

到：

- 管理者；
- 安全人員；
- 法務；
- human approver。

---

# 21. Pause：目前不能安全繼續，但不等於永久拒絕

如果：

- 世界狀態不一致；
- 授權過期；
- target 不明；
- tool response 異常；

最合理的是：

$$
\text{Pause}
$$

而非：

$$
\text{RefuseForever}
$$

這是 long-horizon Agent 很重要的狀態。

---

# 22. Refuse：某些域仍然需要硬邊界

可判定域並不是：

> 什麼都可以，只要多問幾句。

某些任務即使 context 完整，仍可能：

$$
D\rightarrow Refuse
$$

例如：

- 明確未授權破壞；
- 明確竊取；
- 明確惡意入侵；
- 明確規避安全控制以傷害第三方。

細粒度治理不是取消邊界。

而是讓邊界更準確。

---

# 23. Reverse Engineering 為什麼是最好的案例之一

Reverse engineering 很容易被政策寫成單一類別。

但實務上：

$$
RE
=
\{
\text{Compatibility},
\text{Recovery},
\text{Security},
\text{Preservation},
\text{Research},
\text{Circumvention},
\text{Exploitation}
\}
$$

這些不能只靠：

> 有沒有逆向。

判定。

---

# 24. Software Archaeology：逆向可能是知識保存

假設公司只有：

- EXE；
- DLL；
- 資料檔；
- 舊設定；

但：

$$
SourceCode=\varnothing
$$

$$
OriginalDeveloper=\varnothing
$$

$$
BuildPipeline=\varnothing
$$

那麼：

$$
\text{Reverse Engineering}
$$

可能是唯一能恢復：

- 行為；
- 資料格式；
- 協議；
- 相依性；
- 遷移方法；

的方式。

因此：

$$
\text{Reverse Engineering}
\approx
\text{Knowledge Recovery}
$$

在這個 decision domain 中成立。

---

# 25. Legacy Recovery

一個 legacy system 可能仍然：

- 每天被公司使用；
- 控制工廠設備；
- 保存歷史資料；
- 支援醫療／會計流程。

但原始碼消失。

此時：

$$
\text{No RE}
\Rightarrow
\text{No Maintainability}
$$

在某些情境甚至近似成立。

這說明：

> 「禁止逆向」不能作為所有企業 Agent 的全球預設。

---

# 26. Interoperability：法律本身就承認部分例外

美國著作權法：

$$
17\ U.S.C.\ \S1201(f)
$$

明確對特定 reverse engineering 行為提供 interoperability 相關例外：依法取得使用電腦程式權利的人，在必要範圍內，可為辨識與分析實現獨立程式互操作性所必要、且先前不易取得的元素而進行特定 circumvention；相關資訊與手段亦可在符合法定條件時用於互操作性。[4]

這不代表：

$$
\text{All Reverse Engineering}=\text{Legal}
$$

而是證明：

$$
\text{Reverse Engineering}
$$

本身不是足夠的法律判定變量。

---

# 27. Section 1201 豁免制度也證明 context matters

美國 Copyright Office 的 Section 1201 三年期 rulemaking 會定期針對某些非侵權用途建立有限豁免。[5][6]

截至 2026 年，2027 cycle 已經啟動，現有豁免是否續期仍透過正式程序處理。[5]

這更進一步說明：

$$
\text{Legal Status}
=
f(
\text{Jurisdiction},
\text{Purpose},
\text{WorkClass},
\text{CircumventionType},
\text{Time}
)
$$

而不是：

$$
\text{Technique Name}
$$

---

# 28. 因此 Agent 不應假裝自己是全球法律裁判

法律狀態：

$$
L
$$

本身也可能不確定。

不同司法管轄：

$$
L_{US}
\neq
L_{EU}
\neq
L_{TW}
$$

所以 Agent 在高度法律依賴情境中應該：

$$
\text{Legal Uncertainty}
\rightarrow
\text{Limit Action / Escalate}
$$

而不是：

> 自己斷言全球合法／非法。

---

# 29. Penetration Testing：授權是核心變量

Pentest 的技術可能包含：

- scanning；
- fuzzing；
- exploitation；
- credential testing；
- privilege escalation。

這些技術如果：

$$
Authorization=\text{True}
$$

可能是正式安全工作。

如果：

$$
Authorization=False
$$

治理狀態可能完全不同。

所以：

$$
\boxed{
\text{Cyber Technique}
\neq
\text{Cyber Intent}
\neq
\text{Cyber Authorization}
}
$$

---

# 30. 逆向與 Pentest 的交集

某些 pentest：

- firmware；
- mobile apps；
- game clients；
- native desktop apps；
- proprietary protocols；

若沒有 source：

$$
\text{Binary Analysis}
$$

本身就是測試的一部分。

因此：

$$
\text{No Reverse Engineering}
$$

可能導致：

$$
\text{Pentest Coverage}
\downarrow
$$

這不是說所有 pentest 都需要逆向。

而是：

$$
\exists\ S:
RE\text{ is necessary for adequate assessment}
$$

---

# 31. Malware Analysis 又是另一個域

Malware analysis 幾乎天然需要：

- unpacking；
- deobfuscation；
- disassembly；
- behavior tracing。

若治理只看到：

$$
\text{Obfuscated Binary}
$$

就拒絕，

防禦能力會被一起砍掉。

因此：

$$
\text{Defensive Analysis}
$$

必須與：

$$
\text{Offensive Deployment}
$$

分開。

---

# 32. 方法相同，不代表目的相同

這可以寫成：

$$
Method(A)=Method(B)
$$

但：

$$
Purpose(A)\neq Purpose(B)
$$

$$
Authorization(A)\neq Authorization(B)
$$

因此：

$$
Governance(A)\neq Governance(B)
$$

這是 Decision Domain 的核心哲學。

---

# 33. 反過來，目的良善也不能自動放行

使用者說：

> 我只是研究。

不代表：

$$
Authorization=\text{True}
$$

也不代表：

$$
Impact=Low
$$

因此：

$$
\text{Claimed Good Intent}
\not\Rightarrow
\text{Automatic Permission}
$$

治理必須看：

$$
\text{Evidence}
+
\text{Action}
+
\text{Target}
$$

---

# 34. 這就是 Contextual Authorization

本文提出：

$$
\boxed{\text{Contextual Authorization}}
$$

定義：

> Agent 的 action permission 應由當前 principal、target、purpose、environment、time、action type 與 risk context 共同決定，而不是由單一永久 permission 決定。

即：

$$
Auth_t
=
f(
P,
T,
X,
E,
I,
\tau
)
$$

---

# 35. Authorization 應該是動態的

Agent 在任務中可能從：

$$
\text{Read}
$$

逐漸走到：

$$
\text{Modify}
$$

所以：

$$
Auth_{t+1}
$$

可能需要重新檢查。

例如：

> 一開始只說分析。

中途 Agent 發現：

> 要修補漏洞。

那麼：

$$
\text{Analysis Authorization}
\not\Rightarrow
\text{Patch Authorization}
$$

---

# 36. 權限不應因「任務需要」自動擴張

Agent 很容易推理：

> 為了完成目標，我需要更多權限。

但：

$$
\text{Need}
\neq
\text{Authority}
$$

所以：

$$
\boxed{\text{No Implicit Privilege Expansion}}
$$

應該成為基礎原則。

---

# 37. 證據也需要域分類

Authorization Evidence 可以包含：

$$
E_A
=
\{
\text{User Assertion},
\text{Org Policy},
\text{Signed Token},
\text{Ticket},
\text{Scope File},
\text{Environment Label}
\}
$$

不同 evidence strength：

$$
Strength(UserAssertion)
<
Strength(SignedOrgAuthorization)
$$

通常合理。

高風險 action 應要求較強 evidence。

---

# 38. Decision Domain 其實是一個 lattice，而不是單一分數

可以把每個維度視為偏序。

例如 authority：

$$
\text{None}
<
\text{Read}
<
\text{Write}
<
\text{Admin}
$$

environment：

$$
\text{Sandbox}
<
\text{Staging}
<
\text{Production}
$$

impact：

$$
\text{Low}
<
\text{Medium}
<
\text{High}
<
\text{Critical}
$$

所以 Decision Domain 更接近：

$$
\boxed{\text{Governance Lattice}}
$$

而不是：

$$
RiskScore=73
$$

單一分數容易失去語義。

---

# 39. 多維 lattice 能避免「平均掉」關鍵風險

假設：

- target risk 很低；
- impact 很低；
- authorization 為零。

平均分數可能仍然不高。

但：

$$
Authorization=0
$$

應該是硬條件。

因此：

$$
\text{Weighted Sum}
$$

不一定適合所有治理。

某些維度應該是：

$$
\boxed{\text{Hard Constraint}}
$$

---

# 40. Hard Constraints 與 Soft Constraints

可以拆成：

$$
D_H
=
\text{Hard Constraints}
$$

與：

$$
D_S
=
\text{Soft Constraints}
$$

Hard：

- 沒有必要授權；
- target 明確禁止；
- action 明確超出 scope。

Soft：

- impact 稍高；
- 可逆性稍低；
- evidence 不完整。

因此治理：

$$
\text{If }D_H\text{ fails}
\Rightarrow
\text{Stop}
$$

否則：

$$
\text{Use }D_S\text{ to calibrate approval}
$$

---

# 41. 可判定域與可執行治理連接

第 4 篇提出：

$$
\text{Executable Governance}
$$

第 5 篇補上：

> 什麼時候應該執行哪一種限制？

Decision Domain 的輸出可以直接生成 runtime policy。

例如：

$$
D\rightarrow
\{
Filesystem=ReadOnly,
Network=Blocked,
Shell=Allowed,
Production=Denied
\}
$$

這才是完整閉環。

---

# 42. Decision Domain 可以生成 Tool Capability Set

令：

$$
C(D)
$$

為某 decision domain 的可用能力集合。

例如 software archaeology：

$$
C(D_{SA})
=
\{
\text{ReadBinary},
\text{DisassembleOffline},
\text{ExtractStrings},
\text{TraceLocalBehavior}
\}
$$

但可能不包含：

$$
\{
\text{ExploitExternalTarget},
\text{DeployPersistence}
\}
$$

這比「reverse engineering allowed」精確得多。

---

# 43. Agent 不是只有「能／不能」，還可以降級執行

例如高風險網站分析：

完整：

$$
Browser+Login+Write
$$

可以降級成：

$$
Browser+LoggedOut+ReadOnly
$$

若仍不夠：

$$
\text{StaticFetch}
$$

再不夠：

$$
\text{ManualUserProvidedData}
$$

這可以稱為：

$$
\boxed{\text{Capability Degradation Path}}
$$

---

# 44. Degradation 比全拒絕更有用

成熟治理：

$$
\text{Unsafe Full Action}
$$

不一定直接：

$$
\text{Refuse}
$$

而可以：

$$
\text{Degrade}
\rightarrow
\text{Safe Partial Completion}
$$

這對 Agent 實用性非常重要。

---

# 45. 供應商與企業可能採不同 Decision Domains

同一個行動：

$$
A
$$

供應商：

$$
D_P(A)
$$

企業部署者：

$$
D_O(A)
$$

使用者：

$$
D_U(A)
$$

可能不同。

有效治理應是：

$$
D^*
=
D_P
\cap
D_O
\cap
D_U
\cap
D_R
$$

其中：

$$
D_R
$$

是 runtime 邊界。

---

# 46. 這就是為什麼不同公司不會完全收斂

即使都接受：

- least privilege；
- audit；
- authorization；
- user control；

不同公司仍可能：

- 對 cyber 分類不同；
- 對 reverse engineering 分類不同；
- 對成人內容分類不同；
- 對金融 action 分類不同；
- 對企業證據接受度不同。

所以：

$$
\text{Shared Principles}
\not\Rightarrow
\text{Shared Decision Boundaries}
$$

---

# 47. 產品文化會進入治理 ontology

一個 coding-agent 公司可能把世界主要切成：

$$
\text{Repo}
+
\text{Branch}
+
\text{Terminal}
+
\text{CI}
$$

一個 consumer assistant 公司可能切成：

$$
\text{Email}
+
\text{Calendar}
+
\text{Shopping}
+
\text{Browser}
$$

一個 security company 可能切成：

$$
\text{Asset}
+
\text{Scope}
+
\text{Vulnerability}
+
\text{Exploitability}
$$

因此：

$$
\text{Product History}
\rightarrow
\text{Governance Ontology}
$$

是合理現象。

---

# 48. Decision Domain 也會決定 Agent 的「性格」

這不是人格意義上的性格。

而是行為傾向。

例如：

- 一個高 evidence threshold 的 Agent；
- 一個偏好 sandbox 的 Agent；
- 一個經常 ask-before-act 的 Agent；
- 一個偏好自主執行的 Agent。

使用者最後會感覺：

> 這個 Agent 很保守。  
> 那個 Agent 很敢做。

所以：

$$
\text{Governance Policy}
\rightarrow
\text{Perceived Behavioral Character}
$$

這又會回到前面 Identity 系列。

---

# 49. 安全 policy 本身也會成為 Artificial Actor 的一部分

Persistent Agent 長期存在後：

$$
\text{Policy}
$$

不再只是供應商後台規則。

它會影響：

- 它什麼時候拒絕；
- 什麼時候詢問；
- 什麼時候主動；
- 什麼時候只讀；
- 什麼時候停下。

因此：

$$
\boxed{
\text{Governance is part of observable agent behavior.}
}
$$

---

# 50. Decision Domain Resolver

本文提出一個概念模組：

$$
\boxed{\text{Decision Domain Resolver}}
$$

輸入：

$$
Q
=
(
\text{UserIntent},
\text{Context},
\text{AgentState},
\text{Environment},
\text{Target},
\text{Evidence}
)
$$

輸出：

$$
D
$$

再由：

$$
Policy(D)
$$

決定：

$$
\text{ActionMode}
$$

---

# 51. Resolver 的基本流程

$$
\text{Parse Intent}
$$

$$
\downarrow
$$

$$
\text{Identify Target}
$$

$$
\downarrow
$$

$$
\text{Resolve Principal}
$$

$$
\downarrow
$$

$$
\text{Verify Authorization}
$$

$$
\downarrow
$$

$$
\text{Estimate Impact}
$$

$$
\downarrow
$$

$$
\text{Select Environment}
$$

$$
\downarrow
$$

$$
\text{Choose Action Mode}
$$

---

# 52. Resolver 需要允許 Unknown

很重要：

$$
\text{Unknown}
$$

不是：

$$
\text{False}
$$

例如：

> 不知道使用者是否擁有這個 target。

應該是：

$$
Ownership=Unknown
$$

不是：

$$
Ownership=False
$$

這可以避免：

- 過度拒絕；
- 過度放行。

---

# 53. 三值邏輯比二值邏輯更適合部分治理

某些欄位可以：

$$
\{True,False,Unknown\}
$$

例如：

$$
Authorized\in\{T,F,U\}
$$

若：

$$
Authorized=U
$$

就進入：

$$
\text{RequireEvidence}
$$

而不是直接拒絕或直接執行。

---

# 54. 更進一步：證據權重

可寫：

$$
P(Auth|Evidence)=q
$$

高風險 action 要求：

$$
q\ge\tau_H
$$

低風險 action 可能：

$$
q\ge\tau_L
$$

其中：

$$
\tau_H>\tau_L
$$

這讓 uncertainty 與 impact 連接。

---

# 55. Human-in-the-loop 應該出現在域邊界，而不是每一步

如果 Decision Domain 很清楚：

$$
D=D_{\text{safe}}
$$

Agent 可以自主。

如果接近邊界：

$$
D\approx\partial D_{\text{safe}}
$$

才要求 human confirmation。

這樣能降低：

$$
\text{Approval Fatigue}
$$

---

# 56. Decision Boundary Monitoring

長時程任務中：

$$
D_t
$$

可能變化。

例如：

> 一開始只讀分析。

後來：

> 要修改 production。

所以 Agent 應監測：

$$
D_t\rightarrow D_{t+1}
$$

是否跨越治理邊界。

如果：

$$
D_{t+1}\notin AllowedScope
$$

就必須：

$$
\text{Pause}
$$

---

# 57. 這叫 Scope Drift

本文提出：

$$
\boxed{\text{Scope Drift}}
$$

定義：

> Agent 在長時程任務中，實際行動逐漸偏離最初授權的資源、動作、影響或目的範圍。

形式：

$$
Dist(D_t,D_0)
>
\delta
$$

時應觸發重新授權。

---

# 58. Goal Drift 與 Scope Drift 不同

Goal Drift：

$$
\text{目標變了}
$$

Scope Drift：

$$
\text{手段或權限範圍變了}
$$

Agent 可能目標沒變：

> 修復網站。

但從：

> 改 CSS。

漂移到：

> 重設 production DB。

這就是 Scope Drift。

---

# 59. Persistent Agent 特別需要 Scope Drift Control

因為它會：

- 自己規劃；
- 自己重試；
- 長時間跑；
- 遇到障礙後自己找替代路徑。

因此：

$$
\text{Autonomy}
\uparrow
\Rightarrow
\text{Scope Drift Risk}
\uparrow
$$

---

# 60. Grok Bot 類型案例：重試本身也可能跨域

如果任務：

> 發一張世界卡。

第一次上傳失敗。

Agent重試。

再失敗。

再重試。

若實際上第一次已成功：

$$
\text{Retry}
$$

就從：

$$
\text{Recovery}
$$

變成：

$$
\text{Duplicate Publication}
$$

所以 Decision Domain 還必須加入：

$$
\text{World State Verification}
$$

否則 action mode 會在錯誤前提下被重複執行。

---

# 61. Domain Resolution 應與 Causal Closure 連接

第 4 篇：

$$
\text{Causal Closure}
=
\text{Verify World State}
$$

本篇：

$$
\text{Decision Domain Resolution}
=
\text{Verify Governance State}
$$

因此完整循環：

$$
\text{Resolve Domain}
\rightarrow
\text{Act}
\rightarrow
\text{Verify World}
\rightarrow
\text{Resolve New Domain}
$$

---

# 62. Agent Governance 其實是一個動態狀態系統

不是：

$$
\text{一次分類}
$$

而是：

$$
D_0
\rightarrow
D_1
\rightarrow
D_2
\rightarrow
\dots
$$

每次重要世界狀態變更後，都可能需要重新判定。

---

# 63. 可判定域的最終目的不是限制，而是精確放權

如果 domain 很清楚：

- 資源明確；
- 授權明確；
- 可逆；
- 低影響；
- sandbox；

Agent 可以得到：

$$
\text{High Autonomy}
$$

反而不必每一步問人。

所以：

$$
\boxed{
\text{Better Domain Resolution}
\rightarrow
\text{Safer and Greater Autonomy}
}
$$

---

# 64. 粗糙治理會同時造成兩種錯誤

第一種：

$$
\text{False Positive}
$$

合法工作被拒絕。

第二種：

$$
\text{False Negative}
$$

危險行動被放行。

治理品質可以寫成：

$$
Q_G
=
1
-
(
\alpha FP
+
\beta FN
)
$$

不同產品可調：

$$
\alpha,\beta
$$

但不能只追求其中一邊。

---

# 65. 過度拒絕本身也是治理成本

例如企業 Agent：

> 每次遇到 legacy EXE 都完全不能分析。

會產生：

- 工作中斷；
- 人工成本；
- 維護失敗；
- vendor lock-in；
- 知識斷層。

因此：

$$
\text{Over-Restriction Cost}
$$

也應被納入治理。

---

# 66. 過度自治則是另一端

若：

> 使用者一句「幫我修好」，

Agent 就可以：

- 改 production；
- 刪資料；
- 下載外部工具；
- 掃第三方；

則：

$$
\text{Under-Governance Risk}
$$

上升。

所以目標是：

$$
\boxed{\text{Calibrated Autonomy}}
$$

---

# 67. Decision Domains 與公司治理責任

供應商只看到：

$$
D_P
$$

部署者掌握：

$$
D_O
$$

操作者知道：

$$
D_U
$$

現場 runtime 知道：

$$
D_R
$$

因此有效 domain resolution 是：

$$
D^*
=
\Phi(
D_P,
D_O,
D_U,
D_R
)
$$

這再次證明：

> 治理責任不能全部丟給供應商。

---

# 68. 企業內部應提供更多 domain metadata

例如：

```text
asset.owner = EveMissLab
asset.environment = staging
asset.sensitivity = internal
task.scope = read-write
task.expires = 2026-09-20
```

這些 metadata 能讓 Agent：

$$
\text{Guess Less}
$$

$$
\text{Verify More}
$$

---

# 69. 未來 Agent-friendly infrastructure 可能主動暴露治理語義

系統不只提供 API。

也可能提供：

- ownership；
- data class；
- allowed actions；
- risk level；
- rollback support；
- approval owner。

這可以稱為：

$$
\boxed{\text{Governance Metadata Layer}}
$$

---

# 70. Agent-native 系統會把「能做什麼」寫成機器可讀

例如：

$$
Policy(Resource)
=
\{
\text{Read},
\text{Write},
\text{Publish}
\}
$$

並提供：

$$
Constraints(Resource)
$$

這比讓 LLM 自己從自然語言猜公司政策可靠。

---

# 71. 可判定域最終會成為 Agent OS 的核心

未來 Agent OS 可能需要：

$$
\boxed{
\text{Observe}
\rightarrow
\text{Resolve Domain}
\rightarrow
\text{Allocate Authority}
\rightarrow
\text{Act}
\rightarrow
\text{Verify}
}
$$

這不是 safety plugin。

而是 runtime kernel-level concern。

---

# 72. 本篇核心命題

### 命題一

$$
\text{Topic}
\neq
\text{Decision Domain}
$$

---

### 命題二

$$
\text{Method}
\not\Rightarrow
\text{Governance Outcome}
$$

---

### 命題三

$$
D
=
(
K,
A,
T,
X,
E,
R,
I,
P,
\tau
)
$$

---

### 命題四

Agent 治理輸出應該是：

$$
\{
\text{Proceed},
\text{ReadOnly},
\text{Sandbox},
\text{RequireEvidence},
\text{RequireApproval},
\text{Clarify},
\text{Escalate},
\text{Pause},
\text{Refuse}
\}
$$

而不只是：

$$
\{Allow,Deny\}
$$

---

### 命題五

$$
\text{Claimed Good Intent}
\not\Rightarrow
\text{Authorization}
$$

---

### 命題六

$$
\text{Authorization}
$$

應該是 contextual、time-bounded、action-specific。

---

### 命題七

$$
\text{Scope Drift}
$$

是 long-horizon Agent 的核心治理風險。

---

### 命題八

$$
\boxed{
\text{Better Decision Domains}
\rightarrow
\text{More Precise Freedom}
}
$$

而不是只有更多限制。

---

# 73. 結論：Agent 真正需要的是「知道自己現在在哪一個域」

未來高能力 Agent 不應該只有一張：

> 可以做／不能做。

的表格。

真正成熟的 Agent 需要知道：

> 我現在代表誰？

> 目標是誰的？

> 我擁有哪一種授權？

> 我正在做什麼類型的 action？

> 這是在 sandbox 還是 production？

> 做錯能不能回復？

> 影響有多大？

> 這個指令從哪裡來？

> 授權還有效嗎？

這些共同構成：

$$
\boxed{\text{Decision Domain}}
$$

因此，Agent 時代的核心治理問題不是：

> 「這種技術允不允許？」

而是：

$$
\boxed{
\text{在這個世界狀態、這個授權、這個目標與這個行動下，
Agent 應被允許做到哪裡？}
}
$$

Reverse engineering、penetration testing、software archaeology 與 interoperability 只是最容易看出這個問題的案例。

真正的結論更廣：

> **越是通用的 Agent，越不能依靠粗粒度分類。**

因為通用 Agent 的價值，本來就來自：

$$
\text{Cross-Domain Capability}
$$

而真正安全地釋放這種能力，需要的不是把 domain 全部封死。

而是：

$$
\boxed{
\text{更準確地知道自己正在什麼 domain 裡行動。}
}
$$

---

# 參考資料

[1] NIST. **New Concept Paper on Identity and Authority of Software Agents.** 2026-02-05.  
https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents

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

[3] Anthropic. **Trustworthy agents in practice.** 2026-04-09.  
https://www.anthropic.com/research/trustworthy-agents

[4] U.S. Copyright Office. **17 U.S.C. §1201(f) — Reverse Engineering.**  
https://www.copyright.gov/title17/92chap12.html

[5] U.S. Copyright Office. **Tenth Triennial Section 1201 Proceeding, 2027 Cycle.** 2026.  
https://www.copyright.gov/1201/2027/

[6] U.S. Copyright Office. **Ninth Triennial Section 1201 Proceeding, 2024 Cycle.**  
https://www.copyright.gov/1201/2024/

[7] OpenAI. **Understanding prompt injections.** 2026.  
https://openai.com/safety/prompt-injections/

[8] OpenAI. **ChatGPT agent — Safety & privacy.** 2026.  
https://help.openai.com/en/articles/11752874-chatgpt-agent

[9] OpenAI. **ChatGPT Agent System Card.**  
https://deploymentsafety.openai.com/chatgpt-agent

[10] OWASP GenAI Security Project. **OWASP Top 10 for Agentic Applications for 2026.**  
https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[11] OWASP Cheat Sheet Series. **AI Agent Security Cheat Sheet.**  
https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

---

## Source Note

本文中的 **Decision Domain、Governance State Machine、Contextual Authorization、Governance Lattice、Capability Degradation Path、Decision Domain Resolver、Scope Drift、Governance Metadata Layer** 為本系列提出的分析框架，並非 NIST、Anthropic、OpenAI、OWASP 或 U.S. Copyright Office 的官方術語。

本文引用美國著作權法與 Section 1201 rulemaking 僅用來說明：reverse engineering 與 circumvention 的法律狀態可能依目的、工作類型、條件與司法制度而異；本文不主張任何特定個案必然合法。對具體法律問題仍應依實際司法管轄與事實判斷。