← Archive
lm-004345 · 2026-10

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

zh-Hant · md Raw source ↗ Metadata ↗
下載 MD 檔 ⬇

可判定域：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)∈{0,1}g(x) \in \{ 0,1 \}

其中：

0=拒絕0=\text{拒絕} 1=允許1=\text{允許}

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

因為 Agent 面對的不是只有：

這個主題屬於什麼類別？

而是：

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

因此：

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

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

例如：

分析 EXE。

至少可能有：

S1=公司自有 legacy executableS_1=\text{公司自有 legacy executable} S2=合法授權 security assessmentS_2=\text{合法授權 security assessment} S3=interoperability researchS_3=\text{interoperability research} S4=malware analysisS_4=\text{malware analysis} S5=digital preservationS_5=\text{digital preservation} S6=未授權商業軟體破解S_6=\text{未授權商業軟體破解} S7=惡意 exploit developmentS_7=\text{惡意 exploit development}

技術動詞可能都是：

Reverse Engineer\text{Reverse Engineer}

但治理狀態並不相同。

因此：

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

3. 可判定域的基本概念

本文將：

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

定義為：

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

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

例如：

Cybersecurity\text{Cybersecurity}

只是一個知識領域。

真正 decision domain 需要更完整：

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

其中：

  • KK：Knowledge Domain；
  • AA：Authorization Domain；
  • TT：Target Domain；
  • XX：Action Domain；
  • EE：Execution Environment；
  • RR：Reversibility；
  • II：Impact；
  • PP：Purpose / Provenance；
  • τ\tau：Temporal Scope。

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

第一個維度：

KK

可以包含：

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

但：

KK

只能告訴我們：

這是什麼類型的知識。

不能告訴我們：

能不能執行。

因此：

K≠AuthorizationK \neq \text{Authorization}

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

Authorization 不是一句：

我授權你。

完整授權至少應包含：

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

例如：

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

這比：

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

精確得多。

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

至少可以分：

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

其中：

Unknown\text{Unknown}

特別重要。

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

T=UnknownT=Unknown

就不應自動假設：

T=UserOwnedT=UserOwned

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

「分析網站」可能包含：

Read\text{Read} Browse\text{Browse} Scan\text{Scan} Fuzz\text{Fuzz} Exploit\text{Exploit} Persist\text{Persist} Modify\text{Modify}

這些 action 的治理意義不同。

因此：

X=Action TypeX = \text{Action Type}

必須獨立於 topic。

8. Execution Environment：在哪裡做？

至少可以分：

E1=Offline AnalysisE_1=\text{Offline Analysis} E2=SandboxE_2=\text{Sandbox} E3=Local Test EnvironmentE_3=\text{Local Test Environment} E4=StagingE_4=\text{Staging} E5=ProductionE_5=\text{Production} E6=External Third-Party SystemE_6=\text{External Third-Party System}

通常：

Risk(E1)<Risk(E2)<Risk(E4)<Risk(E5)Risk(E_1) < Risk(E_2) < Risk(E_4) < Risk(E_5)

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

9. Reversibility：做錯能否回復？

可逆性：

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

其中：

R=1R=1

代表高度可逆。

例如：

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

而：

R→0R\rightarrow0

代表接近不可逆。

例如：

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

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

Impact 可以拆成向量：

I=(IF,IS,IP,IA,IL,IR)I = ( I_F, I_S, I_P, I_A, I_L, I_R )

其中：

  • IFI_F：Financial；
  • ISI_S：Security；
  • IPI_P：Privacy；
  • IAI_A：Availability；
  • ILI_L：Legal；
  • IRI_R：Reputational。

因此：

同樣是刪檔案。

刪：

temp.log\text{temp.log}

與刪：

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

不能同類處理。

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

目的域：

PP

至少要回答：

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

這對 prompt injection 特別重要。

如果指令來源是：

Untrusted Web Content\text{Untrusted Web Content}

則其 authority：

Auth≈0Auth\approx0

即使內容看起來像命令。

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

權限可能只在：

[t0,t1][t_0,t_1]

有效。

例如：

今晚測試。

不應自動變成：

永久可以測試。

因此：

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

是 Decision Domain 的重要一維。

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

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

Allow/BlockAllow/Block

而可以進入：

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

這是一個：

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

14. Proceed：上下文已閉合

若：

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

則：

D→ProceedD\rightarrow Proceed

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

例如：

分析 log。

若 write authority 不必要：

D→ReadOnlyD\rightarrow ReadOnly

這符合：

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

原則。

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

例如：

測試 exploit 概念。

可以：

D→SandboxD\rightarrow Sandbox

而不是：

D→ProductionD\rightarrow Production

這保留：

Research Capability\text{Research Capability}

同時降低：

External Impact\text{External Impact}

17. Require Evidence：授權聲稱不足

Agent 可能收到：

這台是我的。

但在高風險情況下：

Assertion≠Evidence\text{Assertion} \neq \text{Evidence}

所以可以進入：

RequireEvidence\text{RequireEvidence}

例如要求：

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

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

即使：

Authorization=TrueAuthorization=\text{True}

某些行動仍應：

RequireApproval\text{RequireApproval}

例如：

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

19. Clarify：語意不完整

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

因此：

Ambiguity→Clarify\text{Ambiguity} \rightarrow \text{Clarify}

不是失敗。

它是治理能力。

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

某些決策：

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

可能超出 Agent 自身 decision authority。

因此：

D→EscalateD\rightarrow Escalate

到：

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

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

如果：

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

最合理的是：

Pause\text{Pause}

而非：

RefuseForever\text{RefuseForever}

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

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

可判定域並不是：

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

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

D→RefuseD\rightarrow Refuse

例如：

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

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

而是讓邊界更準確。

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

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

但實務上：

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

這些不能只靠：

有沒有逆向。

判定。

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

假設公司只有：

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

但：

SourceCode=∅SourceCode=\varnothing OriginalDeveloper=∅OriginalDeveloper=\varnothing BuildPipeline=∅BuildPipeline=\varnothing

那麼：

Reverse Engineering\text{Reverse Engineering}

可能是唯一能恢復：

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

的方式。

因此：

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

在這個 decision domain 中成立。

25. Legacy Recovery

一個 legacy system 可能仍然：

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

但原始碼消失。

此時：

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

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

這說明：

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

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

美國著作權法：

17 U.S.C. §1201(f)17\ U.S.C.\ \S1201(f)

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

這不代表：

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

而是證明：

Reverse Engineering\text{Reverse Engineering}

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

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

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

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

這更進一步說明：

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

而不是：

Technique Name\text{Technique Name}

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

法律狀態：

LL

本身也可能不確定。

不同司法管轄：

LUS≠LEU≠LTWL_{US} \neq L_{EU} \neq L_{TW}

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

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

而不是：

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

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

Pentest 的技術可能包含：

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

這些技術如果：

Authorization=TrueAuthorization=\text{True}

可能是正式安全工作。

如果：

Authorization=FalseAuthorization=False

治理狀態可能完全不同。

所以：

Cyber Technique≠Cyber Intent≠Cyber Authorization\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：

Binary Analysis\text{Binary Analysis}

本身就是測試的一部分。

因此：

No Reverse Engineering\text{No Reverse Engineering}

可能導致：

Pentest Coverage↓\text{Pentest Coverage} \downarrow

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

而是：

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

31. Malware Analysis 又是另一個域

Malware analysis 幾乎天然需要：

  • unpacking；
  • deobfuscation；
  • disassembly；
  • behavior tracing。

若治理只看到：

Obfuscated Binary\text{Obfuscated Binary}

就拒絕，

防禦能力會被一起砍掉。

因此：

Defensive Analysis\text{Defensive Analysis}

必須與：

Offensive Deployment\text{Offensive Deployment}

分開。

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

這可以寫成：

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

但：

Purpose(A)≠Purpose(B)Purpose(A)\neq Purpose(B) Authorization(A)≠Authorization(B)Authorization(A)\neq Authorization(B)

因此：

Governance(A)≠Governance(B)Governance(A)\neq Governance(B)

這是 Decision Domain 的核心哲學。

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

使用者說：

我只是研究。

不代表：

Authorization=TrueAuthorization=\text{True}

也不代表：

Impact=LowImpact=Low

因此：

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

治理必須看：

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

34. 這就是 Contextual Authorization

本文提出：

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

定義：

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

即：

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

35. Authorization 應該是動態的

Agent 在任務中可能從：

Read\text{Read}

逐漸走到：

Modify\text{Modify}

所以：

Autht+1Auth_{t+1}

可能需要重新檢查。

例如：

一開始只說分析。

中途 Agent 發現：

要修補漏洞。

那麼：

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

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

Agent 很容易推理：

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

但：

Need≠Authority\text{Need} \neq \text{Authority}

所以：

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

應該成為基礎原則。

37. 證據也需要域分類

Authorization Evidence 可以包含：

EA={User Assertion,Org Policy,Signed Token,Ticket,Scope File,Environment Label}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)Strength(UserAssertion) < Strength(SignedOrgAuthorization)

通常合理。

高風險 action 應要求較強 evidence。

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

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

例如 authority：

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

environment：

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

impact：

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

所以 Decision Domain 更接近：

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

而不是：

RiskScore=73RiskScore=73

單一分數容易失去語義。

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

假設：

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

平均分數可能仍然不高。

但：

Authorization=0Authorization=0

應該是硬條件。

因此：

Weighted Sum\text{Weighted Sum}

不一定適合所有治理。

某些維度應該是：

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

40. Hard Constraints 與 Soft Constraints

可以拆成：

DH=Hard ConstraintsD_H = \text{Hard Constraints}

與：

DS=Soft ConstraintsD_S = \text{Soft Constraints}

Hard：

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

Soft：

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

因此治理：

If DH fails⇒Stop\text{If }D_H\text{ fails} \Rightarrow \text{Stop}

否則：

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

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

第 4 篇提出：

Executable Governance\text{Executable Governance}

第 5 篇補上：

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

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

例如：

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

這才是完整閉環。

42. Decision Domain 可以生成 Tool Capability Set

令：

C(D)C(D)

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

例如 software archaeology：

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

但可能不包含：

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

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

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

例如高風險網站分析：

完整：

Browser+Login+WriteBrowser+Login+Write

可以降級成：

Browser+LoggedOut+ReadOnlyBrowser+LoggedOut+ReadOnly

若仍不夠：

StaticFetch\text{StaticFetch}

再不夠：

ManualUserProvidedData\text{ManualUserProvidedData}

這可以稱為：

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

44. Degradation 比全拒絕更有用

成熟治理：

Unsafe Full Action\text{Unsafe Full Action}

不一定直接：

Refuse\text{Refuse}

而可以：

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

這對 Agent 實用性非常重要。

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

同一個行動：

AA

供應商：

DP(A)D_P(A)

企業部署者：

DO(A)D_O(A)

使用者：

DU(A)D_U(A)

可能不同。

有效治理應是：

D∗=DP∩DO∩DU∩DRD^* = D_P \cap D_O \cap D_U \cap D_R

其中：

DRD_R

是 runtime 邊界。

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

即使都接受：

  • least privilege；
  • audit；
  • authorization；
  • user control；

不同公司仍可能：

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

所以：

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

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

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

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

一個 consumer assistant 公司可能切成：

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

一個 security company 可能切成：

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

因此：

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

是合理現象。

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

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

而是行為傾向。

例如：

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

使用者最後會感覺：

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

所以：

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

這又會回到前面 Identity 系列。

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

Persistent Agent 長期存在後：

Policy\text{Policy}

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

它會影響：

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

因此：

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

50. Decision Domain Resolver

本文提出一個概念模組：

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

輸入：

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

輸出：

DD

再由：

Policy(D)Policy(D)

決定：

ActionMode\text{ActionMode}

51. Resolver 的基本流程

Parse Intent\text{Parse Intent} ↓\downarrow Identify Target\text{Identify Target} ↓\downarrow Resolve Principal\text{Resolve Principal} ↓\downarrow Verify Authorization\text{Verify Authorization} ↓\downarrow Estimate Impact\text{Estimate Impact} ↓\downarrow Select Environment\text{Select Environment} ↓\downarrow Choose Action Mode\text{Choose Action Mode}

52. Resolver 需要允許 Unknown

很重要：

Unknown\text{Unknown}

不是：

False\text{False}

例如：

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

應該是：

Ownership=UnknownOwnership=Unknown

不是：

Ownership=FalseOwnership=False

這可以避免：

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

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

某些欄位可以：

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

例如：

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

若：

Authorized=UAuthorized=U

就進入：

RequireEvidence\text{RequireEvidence}

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

54. 更進一步：證據權重

可寫：

P(Auth∣Evidence)=qP(Auth|Evidence)=q

高風險 action 要求：

q≥τHq\ge\tau_H

低風險 action 可能：

q≥τLq\ge\tau_L

其中：

τH>τL\tau_H>\tau_L

這讓 uncertainty 與 impact 連接。

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

如果 Decision Domain 很清楚：

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

Agent 可以自主。

如果接近邊界：

D≈∂DsafeD\approx\partial D_{\text{safe}}

才要求 human confirmation。

這樣能降低：

Approval Fatigue\text{Approval Fatigue}

56. Decision Boundary Monitoring

長時程任務中：

DtD_t

可能變化。

例如：

一開始只讀分析。

後來：

要修改 production。

所以 Agent 應監測：

Dt→Dt+1D_t\rightarrow D_{t+1}

是否跨越治理邊界。

如果：

Dt+1∉AllowedScopeD_{t+1}\notin AllowedScope

就必須：

Pause\text{Pause}

57. 這叫 Scope Drift

本文提出：

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

定義：

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

形式：

Dist(Dt,D0)>δ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

因為它會：

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

因此：

Autonomy↑⇒Scope Drift Risk↑\text{Autonomy} \uparrow \Rightarrow \text{Scope Drift Risk} \uparrow

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

如果任務：

發一張世界卡。

第一次上傳失敗。

Agent重試。

再失敗。

再重試。

若實際上第一次已成功：

Retry\text{Retry}

就從：

Recovery\text{Recovery}

變成：

Duplicate Publication\text{Duplicate Publication}

所以 Decision Domain 還必須加入：

World State Verification\text{World State Verification}

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

61. Domain Resolution 應與 Causal Closure 連接

第 4 篇：

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

本篇：

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

因此完整循環：

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

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

不是：

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

而是：

D0→D1→D2→…D_0 \rightarrow D_1 \rightarrow D_2 \rightarrow \dots

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

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

如果 domain 很清楚：

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

Agent 可以得到：

High Autonomy\text{High Autonomy}

反而不必每一步問人。

所以：

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

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

第一種：

False Positive\text{False Positive}

合法工作被拒絕。

第二種：

False Negative\text{False Negative}

危險行動被放行。

治理品質可以寫成：

QG=1−(αFP+βFN)Q_G = 1 - ( \alpha FP + \beta FN )

不同產品可調：

α,β\alpha,\beta

但不能只追求其中一邊。

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

例如企業 Agent：

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

會產生：

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

因此：

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

也應被納入治理。

66. 過度自治則是另一端

若：

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

Agent 就可以：

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

則：

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

上升。

所以目標是：

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

67. Decision Domains 與公司治理責任

供應商只看到：

DPD_P

部署者掌握：

DOD_O

操作者知道：

DUD_U

現場 runtime 知道：

DRD_R

因此有效 domain resolution 是：

D∗=Φ(DP,DO,DU,DR)D^* = \Phi( D_P, D_O, D_U, D_R )

這再次證明：

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

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

例如：

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

這些 metadata 能讓 Agent：

Guess Less\text{Guess Less} Verify More\text{Verify More}

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

系統不只提供 API。

也可能提供：

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

這可以稱為：

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

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

例如：

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

並提供：

Constraints(Resource)Constraints(Resource)

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

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

未來 Agent OS 可能需要：

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

這不是 safety plugin。

而是 runtime kernel-level concern。

72. 本篇核心命題

命題一

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

命題二

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

命題三

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

命題四

Agent 治理輸出應該是：

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

而不只是：

{Allow,Deny}\{Allow,Deny\}

命題五

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

命題六

Authorization\text{Authorization}

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

命題七

Scope Drift\text{Scope Drift}

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

命題八

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

而不是只有更多限制。

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

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

可以做／不能做。

的表格。

真正成熟的 Agent 需要知道：

我現在代表誰？

目標是誰的？

我擁有哪一種授權？

我正在做什麼類型的 action？

這是在 sandbox 還是 production？

做錯能不能回復？

影響有多大？

這個指令從哪裡來？

授權還有效嗎？

這些共同構成：

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

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

「這種技術允不允許？」

而是：

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

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

真正的結論更廣：

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

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

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

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

而是：

更準確地知道自己正在什麼 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 的法律狀態可能依目的、工作類型、條件與司法制度而異；本文不主張任何特定個案必然合法。對具體法律問題仍應依實際司法管轄與事實判斷。