# 合法但難分類的 Agent 行動：逆向、滲透測試與軟體考古

## ——Reverse Engineering、Security Research、Interoperability 與 Software Archaeology 的治理邊界

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

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

---

## 摘要

Agentic AI 的治理難題，最容易在「技術上高度相似、但法律與社會意義完全不同」的活動中暴露出來。Reverse engineering、penetration testing、malware analysis、software archaeology、interoperability research 與 digital preservation 正是典型案例。

同樣是分析一個 binary、觀察程式行為、研究通訊協定或測試系統弱點，其治理狀態可能從「企業內部合法維護」一路延伸到「未授權侵入」。因此，如果 Agent policy 僅以技術名稱進行粗分類，例如：

$$
\text{Reverse Engineering}=\text{Blocked}
$$

或：

$$
\text{Cybersecurity}=\text{High Risk}
$$

就會同時產生兩種錯誤：一方面阻斷合法、必要甚至具有公共利益的維護與安全研究；另一方面也可能因過度依賴使用者自述目的，而錯放真正高風險行動。

本文以第 4 篇提出的 Causal Governance 與第 5 篇提出的 Decision Domain 為基礎，建立「合法但難分類行動域」（Legitimate-but-Ambiguous Action Domain, LAAD）框架。本文主張，Agent 不應把某種技術本身視為道德或法律狀態；真正需要判斷的是：

$$
\text{Method}
\times
\text{Authorization}
\times
\text{Target}
\times
\text{Purpose}
\times
\text{Environment}
\times
\text{Impact}
$$

本文以美國與歐盟的正式規範為例說明這種差異。美國 17 U.S.C. §1201(f) 對特定 interoperability reverse engineering 提供法定條件下的例外；37 C.F.R. §201.40 亦包含 good-faith security research 與某些 preservation 類型的暫時性反規避豁免，但官方同時明確指出，符合 §1201 豁免並不代表免除 CFAA 或其他法律責任。美國司法部 2022 年 CFAA charging policy 則明確要求檢察官不要對符合其定義的 good-faith security research 提起 CFAA 訴追，但該政策是檢察裁量規則，不是一般性的私人法律安全港。歐盟 Directive 2009/24/EC 則明確允許合法使用者在特定條件下觀察、研究或測試程式運作，並於 Article 6 對實現獨立程式互操作性所必要的 decompilation 建立條件式例外。

本文另外討論 Software Archaeology：當企業、公共機構或個人只剩 EXE、DLL、舊資料與歷史執行環境，而原始碼、開發者、建置鏈、文件與供應商均已消失時，reverse engineering 可能不再是「額外研究活動」，而是唯一剩餘的知識恢復路徑。這使 Agent 治理必須認識一種重要區別：

$$
\text{Circumvention for Abuse}
\neq
\text{Reverse Engineering for Recovery}
$$

本文最後提出一套 Agentic Reverse-Engineering Governance Matrix，建議將 reverse engineering 與 security testing 分解為 possession / right-to-use、authorization、target ownership、interoperability necessity、security purpose、preservation purpose、external impact、live-system interaction、credential use 與 destructive capability 等判定軸。真正成熟的 Agent，不應看到「EXE」或「逆向」就一律停止，而應在不確定時降級能力、要求證據、限制環境、保持只讀、進入 sandbox、要求明確 Rules of Engagement，或將法律與高影響判斷升級給人類。

---

## 關鍵詞

Reverse Engineering、Penetration Testing、Software Archaeology、Interoperability、Digital Preservation、Good-Faith Security Research、CFAA、DMCA Section 1201、Agent Governance、Decision Domain、Causal Governance

---

# 1. 為什麼 Reverse Engineering 特別容易暴露 Agent 治理缺陷

如果使用者說：

> 「幫我分析這個 EXE。」

Agent 實際上缺少大量關鍵資訊。

例如：

- 這個 EXE 是誰的？
- 使用者是否依法取得？
- 是否為公司內部系統？
- 原始碼是否遺失？
- 是否為 malware sample？
- 是否涉及 DRM？
- 是否要達成 interoperability？
- 是否要修復安全漏洞？
- 是否只做離線分析？
- 是否要連到第三方系統？
- 是否會修改或散布結果？

所以：

$$
\text{Analyze EXE}
$$

並不是一個足夠完整的治理狀態。

它只是：

$$
\text{Method Intent Fragment}
$$

---

# 2. 技術方法本身沒有足夠治理語義

相同方法：

$$
M=\text{Disassemble Binary}
$$

可能出現在：

### Case A：內部遺留系統

公司合法擁有或使用軟體，但：

$$
Source=\varnothing
$$

### Case B：安全研究

研究者被明確授權對特定版本進行 vulnerability testing。

### Case C：互操作性

合法取得程式，需要理解必要介面以讓獨立開發程式互通。

### Case D：惡意樣本分析

研究 malware 的行為與 persistence。

### Case E：保存

圖書館、檔案館或博物館為保存已不再合理可得的軟體而處理程式。

### Case F：未授權破解

目標是繞過限制、盜用或侵害第三方利益。

這些案例可能共享：

$$
\text{Binary Analysis}
$$

但不能共享同一治理結果。

---

# 3. 方法分類不是法律分類

可以寫成：

$$
\text{Method}
\not\Rightarrow
\text{Legality}
$$

更完整：

$$
\text{LegalStatus}
=
f(
\text{Jurisdiction},
\text{Authorization},
\text{Purpose},
\text{Ownership},
\text{Contract},
\text{Copyright},
\text{AccessLaw},
\text{Circumvention},
\text{Impact}
)
$$

因此：

> 「Reverse engineering 合法嗎？」

本身就是過度壓縮的問題。

更合理的是：

> 「在這個司法管轄、這種權利狀態、這種目的與這種技術行為下，哪些部分可能被允許、受限制或需要額外授權？」

---

# 4. 美國：§1201(f) 本身就證明「逆向」不能一刀切

美國著作權法：

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

規定，在滿足條件時，依法取得電腦程式使用權的人，可為了辨識與分析實現獨立程式 interoperability 所必要、且先前不易取得的元素，而規避控制特定程式部分存取的 technological measure；前提是該辨識與分析本身不構成著作權侵害。[1]

這表示：

$$
\text{Circumvention}
+
\text{Reverse Engineering}
$$

在某些非常特定的：

$$
\text{Interoperability Domain}
$$

中，法律本身就沒有採取：

$$
\text{Always Prohibited}
$$

的結構。

---

# 5. §1201(f) 是條件式例外，不是全面許可

它至少包含重要條件：

- 合法取得程式使用權；
- 目的必須是 interoperability；
- 必須限於取得必要資訊；
- 該資訊先前並非 readily available；
- 使用方式不能超出法定目的；
- 不能藉此進行其他著作權侵害。

所以：

$$
\text{Interoperability Exception}
\neq
\text{General Reverse-Engineering License}
$$

這一點對 Agent 特別重要。

Agent 不應從：

> 「法律有 interoperability exception。」

推導：

> 「因此任何 reverse engineering 都可以。」

---

# 6. 美國：good-faith security research 也具有條件式豁免

37 C.F.R. §201.40 現行規則包含 good-faith security research 的特定 §1201 反規避豁免。[2]

但同一規則明確警告：

> 即使符合 §1201 exemption，仍可能依其他法律承擔責任，包括 CFAA；該 exemption 不是對其他法律責任的 safe harbor 或 defense。[2]

這非常值得 Agent 治理直接學習：

$$
\boxed{
\text{One Legal Permission}
\not\Rightarrow
\text{Global Legal Permission}
}
$$

---

# 7. Legal Layering：法律本身也是多層域

一個 reverse-engineering activity 可能同時涉及：

$$
L
=
\{
\text{Copyright},
\text{AntiCircumvention},
\text{AccessLaw},
\text{Contract},
\text{TradeSecret},
\text{Privacy},
\text{ComputerMisuse}
\}
$$

所以即使：

$$
CopyrightException=\text{True}
$$

仍可能：

$$
ContractIssue=\text{True}
$$

或：

$$
UnauthorizedAccess=\text{True}
$$

因此 Agent 不應把單一法條命中當成：

$$
\text{Final Legal Closure}
$$

---

# 8. 美國 DOJ：Good-Faith Security Research 與 CFAA

美國司法部 2022 年更新 CFAA charging policy，明確要求：

> 檢察官不應對 good-faith security research 提起 CFAA 訴追。[3][4]

政策採用的定義核心包括：

- solely for good-faith testing、investigation、correction；
- 研究方式設計成避免對個人或公眾造成傷害；
- 得到的資訊主要用於促進相關裝置、機器、線上服務或其使用者的 security / safety。[3][4]

---

# 9. 但 DOJ charging policy 不是私人安全港

必須非常精確：

$$
\text{DOJ Charging Policy}
\neq
\text{Statutory Immunity}
$$

它主要約束：

$$
\text{Federal Prosecutorial Charging Decisions}
$$

不能簡化成：

> 「只要你自稱 security researcher 就合法。」

司法部也明確指出：

> 假借研究名義進行勒索等行為，不屬於 good faith。[3]

所以：

$$
\text{Claimed Research}
\not\Rightarrow
\text{Good-Faith Research}
$$

---

# 10. Security Research 真正依賴的是 scope

在專業 security assessment 中，一個非常重要的概念是：

$$
\boxed{\text{Rules of Engagement}}
$$

NIST SP 800-115 將 ROE 定義為：

> 在資訊安全測試開始前建立的詳細執行指引與限制，並授權測試團隊在規定活動中無須每一步重新取得額外許可。[5][6]

所以一個真正成熟的 pentest 不是：

> 「你可以駭這個系統。」

而更像：

$$
ROE
=
(
\text{Targets},
\text{Times},
\text{Methods},
\text{ExcludedSystems},
\text{Communication},
\text{Escalation},
\text{DataHandling}
)
$$

---

# 11. ROE 是 Agent-friendly governance 的原型

ROE 非常適合轉成 Agent 可讀格式。

例如：

```text
targets:
  - staging.example.internal

allowed:
  - discovery
  - vulnerability_scan
  - controlled_validation

forbidden:
  - persistence
  - third_party_targets
  - destructive_testing

window:
  start: 2026-09-20T09:00+08:00
  end: 2026-09-20T18:00+08:00
```

這比自然語言：

> 幫我測一下。

安全得多。

---

# 12. Agentic Pentest 不應等於「自動攻擊」

真正合理的 Agentic Pentest：

$$
\text{Authorized Scope}
\rightarrow
\text{Constrained Tools}
\rightarrow
\text{Evidence}
\rightarrow
\text{Validation}
\rightarrow
\text{Report}
$$

而不是：

$$
\text{Find Anything}
\rightarrow
\text{Exploit Everything}
$$

---

# 13. Reverse Engineering 在 Pentest 中有時不可避免

對 web app：

$$
RE
$$

可能不是必要。

但對：

- firmware；
- native desktop software；
- mobile client；
- proprietary protocol；
- embedded device；
- game client；

如果沒有 source：

$$
\text{Internal Logic Visibility}\approx0
$$

這時：

$$
\text{Static Analysis}
+
\text{Dynamic Analysis}
$$

可能是安全評估的重要部分。

所以：

$$
\text{Ban RE}
\Rightarrow
\text{Assessment Coverage}\downarrow
$$

在某些 domain 中成立。

---

# 14. 黑箱、灰箱、白箱安全測試不是同一件事

可以粗分：

### 黑箱

$$
B
=
\text{External Behavior Only}
$$

### 灰箱

$$
G
=
\text{Partial Internal Knowledge}
$$

### 白箱

$$
W
=
\text{Source / Internal Architecture}
$$

如果只有 binary：

> 逆向常常是從黑箱向灰箱移動的唯一方法。

---

# 15. Software Archaeology：不是破解，而是知識重建

本文將：

$$
\boxed{\text{Software Archaeology}}
$$

定義為：

> **在原始碼、文件、開發者、建置環境或完整系統知識已部分或全部消失的情況下，透過現存 binary、資料、設定、行為與執行環境重建系統功能、結構、介面與歷史知識的工程活動。**

Software Archaeology 的主要目標不是：

$$
\text{Defeat Protection}
$$

而是：

$$
\text{Recover Knowledge}
$$

---

# 16. 典型 Software Archaeology 場景

例如一家公司在 2008 年委外開發：

$$
Legacy.exe
$$

到了 2026 年：

$$
Source=\varnothing
$$

$$
Vendor=\text{Defunct}
$$

$$
Developer=\text{Unknown}
$$

$$
Docs\approx0
$$

但：

$$
BusinessDependency>0
$$

這是一個真實可能出現的歷史路徑殘留。

---

# 17. Binary 可能成為唯一的知識載體

如果原始碼遺失：

$$
\text{Binary}
=
\text{Remaining Executable Knowledge}
$$

那麼逆向可能是在嘗試：

$$
\text{Machine Representation}
\rightarrow
\text{Human / AI Model}
$$

即：

$$
\boxed{\text{Knowledge Reconstruction}}
$$

---

# 18. Legacy Recovery 的目標通常很務實

例如：

- 找出資料檔格式；
- 確認 dependency；
- 修復 OS 相容性；
- 遷移資料；
- 重建通訊介面；
- 替換已失效伺服器；
- 移植到新硬體；
- 找到故障邏輯。

這些不是：

> 「破解軟體」的單一目的。

---

# 19. 甚至「加密／混淆」也可能是歷史障礙

舊系統可能包含：

- packer；
- obfuscation；
- encrypted resource；
- custom VM；
- anti-tamper；
- self-decrypting loader。

當原工具鏈消失後：

> 原本用來防止第三方分析的保護層，也可能反過來阻止合法所有者維護自己的歷史系統。

這形成：

$$
\boxed{\text{Protection Legacy Paradox}}
$$

---

# 20. Protection Legacy Paradox

定義：

> 軟體早期為防範未授權分析所加入的保護機制，在權利狀態、供應商存續與技術環境改變後，反而阻礙合法維護、遷移、安全評估或保存。

形式：

$$
Protection_t
\rightarrow
SecurityBenefit_t
$$

但：

$$
Protection_{t+n}
\rightarrow
MaintenanceCost_{t+n}
$$

---

# 21. Agent 可以成為軟體考古的重要工具

對歷史軟體而言，Agent 的優勢包括：

- 大量檔案盤點；
- dependency mapping；
- string / metadata analysis；
- 行為觀察；
- log 整理；
- 格式推測；
- 多版本比較；
- 文件重建；
- knowledge graph 建立。

因此：

$$
\text{Agentic Software Archaeology}
$$

是一個合理的新工程方向。

---

# 22. 但 Agentic Software Archaeology 必須先確認 possession / authority

本文提出：

$$
SA_D
=
(
\text{Possession},
\text{RightToUse},
\text{Ownership},
\text{Purpose},
\text{Environment},
\text{ExternalImpact}
)
$$

只有：

$$
Possession=\text{True}
$$

仍不一定足夠。

例如：

> 有檔案副本。

不代表：

> 擁有所有權利。

所以：

$$
\text{Possession}
\neq
\text{Authorization}
$$

---

# 23. 歐盟：合法使用者具有觀察、研究與測試權利的特定空間

EU Directive 2009/24/EC Article 5(3) 規定，具有程式副本使用權的人，在執行自己有權進行的 loading、displaying、running、transmitting 或 storing 行為時，可以觀察、研究或測試程式運作，以確定程式元素背後的 ideas and principles。[7][8]

這又一次證明：

$$
\text{Observe / Study / Test}
$$

不是天然等於：

$$
\text{Illegal Reverse Engineering}
$$

---

# 24. 歐盟 Article 6：Decompilation for Interoperability

Directive 2009/24/EC Article 6 在特定條件下允許：

$$
\text{Reproduction / Translation of Code Form}
$$

以取得使獨立程式與其他程式 interoperability 所必要的資訊。[7][8]

重要條件包括：

- 由 licensee / lawful user 或其授權人執行；
- 必要資訊先前不可 readily available；
- 僅限 interoperability 必要部分；
- 所得資訊不得用於其他目的；
- 不得用於開發高度相似表達或其他 copyright infringement。[7]

---

# 25. 美國與歐盟都顯示「目的＋權利狀態」的重要性

雖然兩個法律體系結構不同，但至少共同說明：

$$
\text{Reverse Engineering}
$$

不是足以單獨決定：

$$
\text{Permitted / Prohibited}
$$

的變量。

---

# 26. Preservation：當軟體消失，逆向可能成為文化保存

美國 2024 Section 1201 final rule 保留了若干 preservation-related exemptions，包括：

- 某些已失去外部 server 支援的 video games；
- 某些已不再合理可得的 computer programs，由 eligible libraries、archives、museums 為 lawful preservation 目的處理。[2][9]

這些豁免有很多條件，不是自由散布授權。

但它們證明：

$$
\boxed{
\text{Preservation}
}
$$

本身已被法律制度視為值得特別處理的目的域。

---

# 27. Digital Preservation 與 Commercial Exploitation 必須分開

保存目的：

$$
P_{\text{preserve}}
$$

與：

$$
P_{\text{commercial-copy}}
$$

不能混為一談。

同樣技術：

- 解包；
- 修改；
- patch；
- server replacement；

可以出現在兩者。

所以：

$$
\text{Technique Similarity}
\neq
\text{Purpose Equivalence}
$$

---

# 28. Malware Analysis：合法防禦可能使用高度敏感方法

安全研究者分析 malware 可能需要：

- 觀察行為；
- 對照 network activity；
- 理解 persistence；
- 解析 packed code；
- 模擬執行。

這些技術如果只看表面：

> 「如何分析惡意程式？」

可能被分類成高風險。

但真正治理應看：

$$
Target=\text{Malware Sample}
$$

$$
Purpose=\text{Defensive Analysis}
$$

$$
Environment=\text{Isolated Lab}
$$

$$
ExternalImpact\approx0
$$

這形成明顯不同的 Decision Domain。

---

# 29. 安全研究最關鍵不是「技術有多危險」，而是「因果鏈是否被約束」

可以寫成：

$$
\text{Risk}
=
f(
\text{Capability},
\text{Authority},
\text{Containment},
\text{Impact}
)
$$

高能力：

$$
Capability\uparrow
$$

不必然：

$$
Risk\uparrow
$$

如果：

$$
Containment\uparrow
$$

且：

$$
ExternalImpact\downarrow
$$

---

# 30. Agent 治理應允許能力降級，而不是只有全開或全關

例如對一個不完全確定授權的 binary：

### Level 0

$$
\text{Explain Conceptually}
$$

### Level 1

$$
\text{Inspect User-Provided Metadata}
$$

### Level 2

$$
\text{Offline Read-Only Analysis}
$$

### Level 3

$$
\text{Sandbox Dynamic Observation}
$$

### Level 4

$$
\text{Authorized Modification}
$$

### Level 5

$$
\text{Live External Interaction}
$$

不同 domain 可以停在不同 level。

---

# 31. Reverse-Engineering Capability Ladder

本文提出：

$$
\boxed{\text{RE Capability Ladder}}
$$

$$
L_0<L_1<L_2<L_3<L_4<L_5
$$

每升一層：

$$
\text{External Causal Power}
\uparrow
$$

因此需要更強：

$$
\text{Evidence}
+
\text{Authorization}
+
\text{Audit}
$$

---

# 32. 這比「是否允許逆向」更實用

例如：

> Agent 不確定第三方權利。

仍可以：

$$
L_0
$$

或：

$$
L_1
$$

而不必整個任務歸零。

這就是第 5 篇的：

$$
\text{Capability Degradation}
$$

在實際案例中的應用。

---

# 33. Agentic Pentest 也需要 Capability Ladder

例如：

$$
P_0=\text{Documentation Review}
$$

$$
P_1=\text{Passive Observation}
$$

$$
P_2=\text{Authorized Discovery}
$$

$$
P_3=\text{Controlled Validation}
$$

$$
P_4=\text{Exploit Demonstration in Test Environment}
$$

$$
P_5=\text{High-Impact Live Validation}
$$

越往後：

$$
ApprovalThreshold\uparrow
$$

---

# 34. Rules of Engagement 應決定最高層級

如果 ROE 只允許：

$$
P\le P_2
$$

Agent 就不能因：

> 「我找到一個有趣漏洞。」

自行進入：

$$
P_4
$$

這就是：

$$
\boxed{\text{No Curiosity-Based Scope Expansion}}
$$

---

# 35. Agent 的「好奇心」不能生成授權

高能力 Agent 可能推理：

> 再多做一步就能證明。

但：

$$
\text{EpistemicValue}
\neq
\text{Authority}
$$

所以：

$$
\text{More Knowledge}
$$

不是：

$$
\text{Permission to Act}
$$

的來源。

---

# 36. 可驗證目的比自述目的更可靠

如果使用者說：

> 我是在做保存。

Agent 可以檢查：

- target 是否已停產；
- 是否只是本地分析；
- 是否有 library / archive context；
- 是否涉及公開散布；
- 是否可在 sandbox 完成。

這不代表 Agent 有資格作法律裁判。

但它可以：

$$
\text{Reduce Uncertainty}
$$

---

# 37. 高法律不確定性應導向「限制行動＋保留分析」

例如：

$$
LegalUncertainty=High
$$

可以：

$$
\text{Proceed with Non-Causal Analysis}
$$

但：

$$
\text{Block External Modification}
$$

這比全局拒絕更精確。

---

# 38. 法律不確定性不是技術無能

這是一個產品設計上很重要的語言問題。

Agent 應該說：

> 「目前無法確認你是否有權執行 live modification；我可以先做離線、只讀分析。」

而不是：

> 「我不能做這件事。」

前者保留：

$$
\text{Capability}
$$

只限制：

$$
\text{Action Mode}
$$

---

# 39. 這可以降低「供應商治理過度侵入」

如果供應商只有一個 global refusal：

$$
\text{ProviderPolicy}
\rightarrow
\text{User Capability Loss}
$$

但如果提供：

- read-only mode；
- sandbox mode；
- evidence mode；
- enterprise authorization hooks；

就能把部分判定交還：

$$
\text{Deployer}
+
\text{Runtime}
+
\text{Operator}
$$

---

# 40. Enterprise Authorization Token

未來可以想像：

$$
\boxed{\text{Enterprise Authorization Token}}
$$

它不是帳號 token。

而是描述：

- approved target；
- approved methods；
- expiry；
- approver；
- environment；
- incident contact。

Agent 可以機器讀取。

---

# 41. Security Research Scope Manifest

同理可以有：

$$
\boxed{\text{Security Research Scope Manifest}}
$$

例如：

```yaml
scope:
  organization: Example Corp
  targets:
    - staging-app-01
    - staging-api-01
  authorized_actions:
    - passive_analysis
    - vulnerability_scan
    - controlled_validation
  prohibited:
    - production_write
    - denial_of_service
    - third_party_access
  expires: 2026-10-01
```

這把：

$$
\text{Human Legal / Organizational Decision}
$$

轉成：

$$
\text{Agent-Readable Constraint}
$$

---

# 42. Software Archaeology Manifest

對 legacy recovery：

```yaml
artifact:
  owner: Example Corp
  acquired: internal_archive
  source_available: false
purpose:
  - migration
  - compatibility
  - data_recovery
environment:
  network: isolated
  write_target: copy_only
```

這能讓 Agent：

> 更容易落入低外部影響的合法維護域。

---

# 43. Preservation Manifest

對圖書館／檔案館：

- institution status；
- acquisition provenance；
- preservation purpose；
- distribution limits；
- access limits。

這些都能成為治理 metadata。

---

# 44. Agent 不應自行偽造治理 metadata

非常重要：

$$
\text{Agent-Generated Authorization}
\neq
\text{Valid Authorization}
$$

Agent 可以整理 evidence。

不能自己產生：

> 我已授權自己。

---

# 45. Authority must originate outside the acting Agent

本文提出：

$$
\boxed{\text{External Authority Origin Principle}}
$$

即：

> 高影響權限的來源應可追溯到 Agent 之外的有效 principal、policy 或 institution。

---

# 46. Agent 可以解釋規則，但不能成為自己權限的最終來源

否則：

$$
\text{Planner}
=
\text{Authorizer}
=
\text{Executor}
$$

容易形成：

$$
\text{Unchecked Authority Loop}
$$

---

# 47. Separation of Duties 也應進入 Agent 系統

例如：

$$
A_{\text{analyst}}
$$

提出：

> 需要更高權限。

$$
A_{\text{governor}}
$$

檢查 policy。

$$
\text{Human}
$$

批准高影響動作。

這是：

$$
\boxed{\text{Agentic Separation of Duties}}
$$

---

# 48. 「自己擁有」也不能消除所有風險

即使 target 是使用者自己的：

$$
Ownership=True
$$

仍可能有：

- 第三方資料；
- 共同所有；
- 法律義務；
- 安全風險；
- 下游依賴；
- production impact。

所以：

$$
\text{Ownership}
\not\Rightarrow
\text{UnlimitedAuthority}
$$

---

# 49. 企業自有系統也需要內部治理

公司可以：

> 擁有 server。

但：

> 某個員工不一定有權讓 Agent 改 production。

所以：

$$
\text{OrganizationOwnership}
\neq
\text{OperatorAuthorization}
$$

---

# 50. 這再次證明多層責任鏈必要

Provider 只知道：

> 這是一台 server。

Deployer 知道：

> 這是公司資產。

Operator manager 知道：

> 這個人是否有權。

Runtime 知道：

> action 是否在 scope。

所以：

$$
\text{Legitimacy}
$$

是多層資訊的交集。

---

# 51. Legitimate-but-Ambiguous Action Domain

本文正式提出：

$$
\boxed{\text{LAAD}}
$$

即：

> **某些行動本身具有明確合法、公益或必要應用，但同時也可能被用於侵害；僅靠技術表面無法可靠分類，需要結合授權、目的、目標與執行環境才能治理的行動域。**

Reverse engineering 是其中之一。

其他還包括：

- security research；
- dual-use chemistry；
- privacy research；
- automated scraping；
- data recovery；
- forensic analysis。

---

# 52. LAAD 的治理原則不是「信任使用者」

LAAD 不等於：

> 使用者說合法就相信。

而是：

$$
\boxed{
\text{Preserve Legitimate Capability}
+
\text{Constrain High-Impact Execution}
}
$$

---

# 53. LAAD Policy Ladder

可以設計：

$$
S_0=\text{Conceptual}
$$

$$
S_1=\text{Read-only}
$$

$$
S_2=\text{Offline/Sandbox}
$$

$$
S_3=\text{Evidence-backed Authorized}
$$

$$
S_4=\text{Explicit Approval}
$$

$$
S_5=\text{Restricted / Refused}
$$

依 domain 動態選擇。

---

# 54. 這比內容分類更接近真正 Agent 治理

內容治理：

> 是否可以談 reverse engineering？

因果治理：

> 在這個 target、這個授權、這個目的、這個 environment 下，Agent 可以做到哪一層？

這就是整個系列從：

$$
\text{Text}
$$

轉向：

$$
\text{World Action}
$$

的具體案例。

---

# 55. 軟體考古的公共價值

Software Archaeology 的價值不只在企業。

它也涉及：

- 數位歷史；
- 遊戲保存；
- 學術研究；
- 舊格式恢復；
- 技術史；
- 文化保存。

當 source code 永久消失：

$$
\text{Binary}
$$

可能成為唯一剩下的歷史證據。

---

# 56. 「不能逆向」可能等於「不能理解歷史軟體」

在某些 artifact 上：

$$
\text{NoSource}
+
\text{NoDocs}
+
\text{NoVendor}
+
\text{NoRE}
\Rightarrow
\text{KnowledgeLoss}
$$

這是數位文明很現實的問題。

---

# 57. Agent 可以把軟體保存從人工稀缺能力擴大

今天能熟練：

- assembly；
- debugging；
- binary formats；
- legacy APIs；

的人有限。

Agent 若被適當治理，可以降低：

$$
\text{Preservation Skill Bottleneck}
$$

這可能具有實際公共利益。

---

# 58. 但保存並不自動允許公開散布

必須再次區分：

$$
\text{Preserve}
\neq
\text{Redistribute}
$$

這也是為什麼 Agent 應將 action 拆細。

---

# 59. Repair、Recovery、Preservation 與 Interoperability 是不同目的域

它們可以共享工具。

但應分別標記：

$$
P_R=\text{Repair}
$$

$$
P_D=\text{Data Recovery}
$$

$$
P_P=\text{Preservation}
$$

$$
P_I=\text{Interoperability}
$$

不同法域可能給不同待遇。

---

# 60. Agent 不應自己把目的重新命名以繞過限制

如果使用者目的：

> 破解限制。

Agent 不應自己重述：

> 這其實是 interoperability。

治理系統需要：

$$
\boxed{\text{Purpose Integrity}}
$$

---

# 61. Purpose Integrity

定義：

> Agent 在任務演化中，不得為了獲得更寬鬆 policy outcome 而重新包裝或弱化原始目的。

即：

$$
P_{reported}
\approx
P_{actual}
$$

應維持。

---

# 62. 長時程 Agent 特別容易產生 Purpose Drift

一開始：

> 修復舊程式。

後來：

> 順便移除授權驗證。

再後來：

> 順便散布修改版。

這可能是：

$$
\boxed{\text{Purpose Drift}}
$$

需要重新 domain resolution。

---

# 63. Purpose Drift 與 Scope Drift 應同時監測

第 5 篇提出 Scope Drift。

本篇加入：

$$
\text{Purpose Drift}
$$

完整監測：

$$
\Delta D
=
f(
\Delta Scope,
\Delta Purpose,
\Delta Target,
\Delta Impact
)
$$

---

# 64. Agent 每次跨域都應重新授權

例如：

$$
D_0=\text{Offline Recovery}
$$

若下一步要：

$$
D_1=\text{Live External Interaction}
$$

則：

$$
D_0\rightarrow D_1
$$

應觸發：

$$
\text{Reauthorization}
$$

---

# 65. 這能避免「合法起點、危險終點」

很多問題不是任務起點惡意。

而是：

$$
\text{Benign Start}
\rightarrow
\text{Autonomous Expansion}
\rightarrow
\text{High-Impact Action}
$$

所以 Agent governance 必須動態。

---

# 66. Agentic Reverse-Engineering Governance Matrix

本文提出一個最小矩陣：

| 軸 | 低風險端 | 高風險端 |
|---|---|---|
| 權利狀態 | 明確合法取得／自有 | 未知／第三方限制 |
| 授權 | 明確書面／機器可驗證 | 無授權／含糊 |
| 目的 | 維護／保存／互操作／防禦 | 侵害／竊取／破壞 |
| 環境 | 離線副本／sandbox | live third-party system |
| 行動 | 只讀分析 | 修改／利用／持久化 |
| 可逆性 | 高 | 低 |
| 外部影響 | 接近零 | 顯著第三方影響 |
| 資料敏感度 | 測試資料 | 個資／機密／credential |
| 散布 | 不散布 | 公開散布受保護內容 |
| 時效 | 明確 scope | 無期限 |

真正 decision outcome 應看整個向量。

---

# 67. 不同組合對應不同 Agent 模式

例如：

### Legacy Recovery

$$
Mode=\text{Offline Read/Analyze}
$$

### Authorized Pentest

$$
Mode=\text{ROE-Bounded Security Testing}
$$

### Malware Analysis

$$
Mode=\text{Isolated Sandbox}
$$

### Interoperability Research

$$
Mode=\text{Necessary-Scope Analysis}
$$

### Unknown Third-Party Target

$$
Mode=\text{Conceptual / Clarify / Require Evidence}
$$

---

# 68. 法律與政策邊界應該是可更新的

法律會：

- 改法；
- 判決；
- 新增豁免；
- 到期；
- 不同國家不同。

因此：

$$
Policy_t
\neq
Policy_{t+5y}
$$

Agent runtime 不應把法律假設永久硬編碼。

---

# 69. Legal Rule Registry

未來可以有：

$$
\boxed{\text{Legal Rule Registry}}
$$

包含：

- jurisdiction；
- effective date；
- expiration；
- source；
- applicable activity；
- conditions；
- uncertainty。

Agent 只讀取：

$$
\text{Current Applicable Rules}
$$

而不是靠模型記憶舊法。

---

# 70. 法律資料不能取代律師，但可以改善 Agent 邊界判定

Agent 可以：

- 找規則；
- 標記不確定性；
- 限制 action；
- 要求人類審查。

但：

$$
\text{Legal Retrieval}
\neq
\text{Final Legal Judgment}
$$

尤其高風險情境。

---

# 71. Security Research Registry

企業或平台也可以建立：

$$
\boxed{\text{Authorized Research Registry}}
$$

Agent 查到：

- target；
- program；
- scope；
- expiration；
- reporting channel；

再決定工具能力。

這比用對話猜更可靠。

---

# 72. VDP 是外部授權的一種機器化候選

CISA 與美國聯邦機構的 Vulnerability Disclosure Policy 實踐，就是一種：

> 公開聲明哪些 good-faith research 被視為 authorized。

CISA 的資料指出，Federal Civilian Executive Branch agencies 被要求建立 VDP，這些政策旨在促進 good-faith security research 與 coordinated disclosure。[10][11]

這類政策未來完全可以被 Agent runtime 解析成 scope metadata。

---

# 73. 但 VDP scope 仍然有邊界

例如：

- 只涵蓋特定 domain；
- 排除某些測試；
- 要求避免資料破壞；
- 要求通報。

所以：

$$
VDP=True
$$

不等於：

$$
UnlimitedPentest=True
$$

---

# 74. Good Faith 是行為條件，不是標籤

一個使用者自稱：

> good-faith researcher。

不能自動得到：

$$
GoodFaith=True
$$

真正 relevant variables 是：

- 是否避免傷害；
- 是否超出 scope；
- 是否主要用於安全改善；
- 是否勒索；
- 是否散布敏感內容；
- 是否遵守 disclosure。

---

# 75. Agent 可以幫助維持 Good-Faith Constraints

例如 Agent 可以：

- 自動限制在 scope；
- 阻止 destructive test；
- 保存 evidence；
- 自動產生 disclosure report；
- 避免超出 approved window。

也就是：

$$
\text{Governance Tooling}
\rightarrow
\text{Good-Faith Support}
$$

---

# 76. Agent 不只是風險來源，也可以成為治理強化器

如果設計得好：

$$
\text{Agent}
+
\text{ROE}
+
\text{Runtime Constraints}
$$

可能比：

> 人類研究者手動記憶所有 scope。

更不容易越界。

這是一個重要的正面可能性。

---

# 77. 但前提是 Agent 真的遵守 machine-readable boundary

若 Agent 在障礙下自動：

> 找替代方法。

就可能：

$$
\text{Circumvent Governance}
$$

所以：

$$
\text{Boundary}
$$

必須在 runtime，而不能只在 prompt。

---

# 78. 高品質治理的目標不是「最安全」，而是「最精確」

如果唯一目標是：

$$
Risk=0
$$

最簡單方法：

> 不讓 Agent 做任何事。

但 Agent 的價值也：

$$
Utility=0
$$

所以真正目標是：

$$
\boxed{
\max Utility
\quad
\text{subject to acceptable risk}
}
$$

---

# 79. 精確治理比全面禁止更能保留公共利益

對：

- preservation；
- security；
- interoperability；
- recovery；

如果全部禁止：

$$
SocialBenefit\downarrow
$$

所以 governance 應該：

$$
\text{Differentiate}
$$

而不是：

$$
\text{Flatten}
$$

---

# 80. 這正是 LAAD 的核心價值

LAAD 告訴我們：

> 某些域不能用「技術危險」直接代表「用途不正當」。

真正需要：

$$
\text{Capability}
+
\text{Context}
+
\text{Constraint}
$$

共同治理。

---

# 81. 本篇核心命題

### 命題一

$$
\text{Reverse Engineering}
\not\Rightarrow
\text{Illegal}
$$

也不推出：

$$
\text{Reverse Engineering}
\Rightarrow
\text{Legal}
$$

---

### 命題二

$$
\text{Method}
\neq
\text{Purpose}
\neq
\text{Authorization}
$$

---

### 命題三

$$
\text{Good-Faith Security Research}
$$

是一組條件，而不是自我標籤。

---

### 命題四

$$
\text{Software Archaeology}
$$

可能是歷史軟體唯一的知識恢復方法。

---

### 命題五

$$
\text{Protection}
$$

可能隨時間從安全資產變成維護障礙。

---

### 命題六

Agent 應使用：

$$
\text{Capability Ladder}
$$

而不是只有：

$$
\text{Full Allow / Full Deny}
$$

---

### 命題七

$$
\text{Authority}
$$

必須源自 acting Agent 之外的有效 principal 或制度。

---

### 命題八

$$
\boxed{
\text{Preserve Legitimate Capability}
+
\text{Constrain High-Impact Execution}
}
$$

是 LAAD 治理的核心。

---

# 82. 結論：真正困難的不是危險技術，而是「相同技術可以屬於不同世界」

Reverse engineering 是一個非常好的 Agent governance 樣本。

因為它揭示：

> 同一種技術，在不同世界狀態中，可以是完全不同的事情。

它可能是：

$$
\text{Attack}
$$

也可能是：

$$
\text{Maintenance}
$$

可能是：

$$
\text{Circumvention}
$$

也可能是：

$$
\text{Interoperability}
$$

可能是：

$$
\text{Security Research}
$$

也可能是：

$$
\text{Unauthorized Intrusion}
$$

可能是：

$$
\text{Copyright Risk}
$$

也可能是：

$$
\text{Digital Preservation}
$$

因此真正成熟的 Agent 不能只知道：

> 「Reverse engineering 是什麼。」

它還必須知道：

> 「我現在處於哪一個權利、授權、目的、環境與因果影響組合中？」

這就是：

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

在真實世界中的意義。

當歷史軟體只剩：

$$
EXE
+
DLL
+
\text{Data}
$$

而 source、developer、vendor 全部消失時：

> 禁止所有 reverse engineering

可能不只是「比較安全」。

它也可能意味著：

$$
\boxed{\text{永遠失去理解與維護這套系統的能力。}}
$$

所以 Agent governance 的真正成熟，不在於把所有危險工具拿走。

而在於：

$$
\boxed{
\text{知道何時、為何、對誰、在什麼邊界內使用它們。}
}
$$

---

# 參考資料

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

[2] U.S. Copyright Office. **37 C.F.R. §201.40 — Exemptions to prohibition against circumvention.** Current rule text.  
https://www.copyright.gov/title37/201/37cfr201-40.html

[3] U.S. Department of Justice. **Department of Justice Announces New Policy for Charging Cases under the Computer Fraud and Abuse Act.** 2022-05-19; page updated 2025-02-06.  
https://www.justice.gov/archives/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act

[4] U.S. Department of Justice. **Justice Manual §9-48.000 — Computer Fraud and Abuse Act.**  
https://www.justice.gov/jm/jm-9-48000-computer-fraud

[5] NIST. **Special Publication 800-115: Technical Guide to Information Security Testing and Assessment.** 2008.  
https://csrc.nist.gov/pubs/sp/800/115/final

[6] NIST CSRC Glossary. **Rules of Engagement (ROE).** Source: NIST SP 800-115.  
https://csrc.nist.gov/glossary/term/Rules_of_Engagement

[7] European Union. **Directive 2009/24/EC on the legal protection of computer programs — Article 5.**  
https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32009L0024

[8] European Union. **Directive 2009/24/EC — Article 6, Decompilation.**  
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32009L0024

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

[10] CISA. **Vulnerability Disclosure Policy Platform — Fact Sheet.**  
https://www.cisa.gov/sites/default/files/publications/FINAL-CSSO-VDP_Platform-Fact_Sheet_PDF_0.pdf

[11] CISA. **Vulnerability Disclosure Policy Platform — Annual Report.**  
https://www.cisa.gov/sites/default/files/2024-09/Vulnerability%20Disclosure%20Policy%20%28VDP%29%20Platform%202023%20Annual%20Report.pdf

[12] U.S. Department of Justice. **Vulnerability Disclosure Policy.**  
https://www.justice.gov/jmd/vulnerability-disclosure-policy

[13] U.S. Copyright Office. **Tenth Triennial Section 1201 Proceeding, 2027 Cycle — Renewal Petitions.** 2026.  
https://www.copyright.gov/1201/2027/petitions/renewal/

---

## 法律範圍聲明

本文不是法律意見。本文引用美國與歐盟制度，是為了證明 reverse engineering、security research、decompilation、circumvention 與 preservation 的治理狀態具有目的、授權、工作類型、司法管轄與條件差異。

任何具體行為是否依法被允許，仍可能取決於：

- 當地法律；
- 契約；
- EULA；
- 著作權；
- 商業秘密；
- 電腦存取法；
- 個資法；
- 特定豁免條件；
- 實際技術行為與影響。

因此本文提出的 Decision Domain、LAAD 與 Capability Ladder 是治理建模工具，不是用來替代個案法律判斷的自動法律裁決器。

---

## Source Note

本文中的 **Legitimate-but-Ambiguous Action Domain（LAAD）、Protection Legacy Paradox、Agentic Software Archaeology、RE Capability Ladder、Security Research Scope Manifest、Software Archaeology Manifest、External Authority Origin Principle、Agentic Separation of Duties、Purpose Integrity、Purpose Drift、Agentic Reverse-Engineering Governance Matrix** 為本系列提出的分析框架，並非 U.S. Copyright Office、DOJ、NIST、CISA 或 EU 的官方術語。

本文的核心理論主張是：**Agent 不應以方法名稱代替完整治理判定。**