治理是寫在公開記錄裡的。
一個標準的可信度，來自它的流程可以被任何人審查——不是來自單一權威說了算。ATR 是 MIT 授權的開放標準，不隸屬任何公司。誰維護、規則怎麼進、spec 怎麼改、首席維護者有什麼利益衝突，全部寫在這一頁，也全部寫在 GitHub 上可被審計。
負責規則品質、PR 審核、與發布。
ATR 的創始人與主要維護者。負責規則品質門檻設計（RFC-001）、社群外展、以及生態系整合審核。GitHub: eeee2345 (Adamthereal)。
[email protected]ATR 目前是單一維護者啟動的——和 Linus Torvalds 1991 年的 Linux、Florian Roth 的 Sigma 同一條路徑：一個人開頭，定義格式與品質門檻，社群再接手治理。這是誠實的現狀，不是道歉。第二位維護者的招募正在進行（見下方條件），把標準託管到中立基金會（Linux Foundation、OpenSSF 或同級）的評估也在路線圖上。終點是 Technical Steering Committee；起點本來就只能有一個人。
每條規則要過六道關才能 merge。
這些閘是機器執行的，每一道都在公開的 CI log 裡留痕——任何人都能看到一條規則為什麼通過、或為什麼被擋。品質不靠維護者的判斷力背書，而靠可重跑的測試。
合法 YAML schema、有效 regex（無 ReDoS）、至少 1 TP + 1 TN。
信心分數（精準度、野外驗證、覆蓋深度、已知規避手法的文件）決定規則進哪一條偵測車道。分數沒到，規則不會被升到 enforce——但仍可以 advisory 形式存在。門檻是公開的公式，不是維護者的喜好。
新規則必須在每個 PR 的良性語料閘上 0 誤報。這是 merge 時的最低門檻；發布後，誤報率會在更大的良性語料上逐車道公開量測，不靠單一數字蓋過。
新規則不得與現有規則在相同輸入產生矛盾結果。
維護者審核 regex 形狀、test case 覆蓋、以及來源文件。Stable 等級需要 human-reviewed provenance。
每個 PR 最多 10 條新規則。test_cases 必須包含 true_positives + true_negatives。
每種改動有自己的審核門檻。
改一條規則和改 spec 不是同一回事。規則錯了可以撤、可以修；spec 是每一個相容引擎共同遵守的契約，動它要給所有 implementer 看得到、來得及反應的時間。門檻的高低，照的是這個改動會牽動多少人。
規則 PR 走六道安全閘(見上面合併政策),通過後一位維護者人工 review 即可 merge。不需要二人核可,因為安全閘已經涵蓋了規則的客觀品質。
spec 是所有相容引擎的契約。任何 spec 變動都要先以 issue 形式提出 RFC、開 14 天公開評論窗口(複雜提案延長至 30 天)讓所有 implementer 看到,然後才接受 PR。在目前 BDFL 階段,「2 名核可」將由首席維護者加上一名外部 reviewer(待指定後)滿足。TSC 成立後改為 TSC 過半數核可。
任何破壞 rule schema、engine API、或既有 rule_id 語意的改動都算 breaking。提前 30 天在 GOVERNANCE.md 標題、CHANGELOG、@adopters 通知,讓上游採用者有時間應對。
目前只有一名維護者,所以加第二位維護者要這名維護者本人同意。當有 2+ 名維護者時,新增需要全員核可。撤換需要 2/3 多數(BDFL 階段不適用)。
deprecated 規則仍會留在 corpus 但 engine MUST NOT 預設啟用。30 天後可以從 corpus 刪除;之前已採用的下游可以 pin 到 deprecated 版本。
目前還沒有,但路徑開放。
OASIS CTI、OpenTelemetry SIG、OWASP Working Group 都開定期會議。ATR 還沒到需要排程會議的規模——目前所有討論都在 GitHub Issues 與 PR 上非同步、公開、留痕進行。一個只有少數 implementer 的標準，不該先有委員會再有需求。
成立工作小組的路徑是開放的，而且是需求驅動的：如果你有實際的整合工作、想推動 spec 的某個方向、或代表一個 implementer 想要在標準化過程中有結構化的話語權，開一個標題以 [WG-proposal] 開頭的 issue。當 3 個或以上獨立的 implementer 表達相同需求，維護者會發起固定週期（雙週）的工作小組會議。觸發條件寫在這裡，誰都能援引。
我們正在主動招募。
單一維護者是 ATR 目前已知的最大結構風險，這一點我們公開講。從一個人到一個 Technical Steering Committee（TSC），是每個開放標準都走過的路——分散治理的方式，是真的有人 merge 過足夠多的東西、值得拿到 commit 權。我們正在主動招募第二位、第三位維護者。
候選條件:
- 過去六個月內,在 ATR repo merge 過至少三個 substantive PR(新規則、schema 修正、engine 改進、或文件實質改寫)
- 熟悉 ATR-SPEC-v1 的內容到能解釋 conformance 條款的程度
- 能配合非同步審核(沒有實時要求,但 PR 平均應在 7 天內收到第一次審核回應)
- 在公開場合(GitHub、issue 留言、conference)代表 ATR 時,語氣維持中立、不暗示任何商業利益
申請方式:寄信至 [email protected] 主旨「ATR maintainer application」,內容包含你近期的 PR 連結與你想接哪一塊(rules / spec / engine / documentation)。
如果首席維護者無法履行職責。
短期（30 天內）：GitHub 的 CODEOWNERS 檔案與 CI 自動化維護繼續運作，已合併的規則繼續透過 npm 發布。ATR 不依賴單一伺服器或閉源系統——規則是純文字 YAML，任何人都可以 fork。
中期:第二位維護者(招募進行中)接任 PR 審核職責。如果 30 天後仍未找到正式維護者,外部臨時維護者的招募條件是:在過去六個月內 merge 過至少三個 substantive PR、對 schema 有實作熟悉度、且能配合非同步審核。具體人選不會在這個頁面公告;當邀請發出且對方同意後,姓名才會出現在「現任維護者」區塊。
長期：ATR 路線圖包含將標準轉移至中立基金會（Linux Foundation 或 OpenSSF）的評估。轉移條件：有兩名以上外部維護者，以及至少一個組織願意提供資源支持治理。
為什麼揭露這件事。
ATR（Agent Threat Rules）是 MIT 授權的開放標準，由 Agent-Threat-Rule GitHub 組織維護。首席維護者在 AI agent 安全領域另持有商業利益（commercial affiliation）。我們不掩蓋這件事，而是寫下來——揭露本身就是治理機制。一個標準的中立性，不靠維護者沒有利益來證明，而靠他的決策過程公開到任何人都能檢查有沒有被利益扭曲。
界限：ATR 的規則、CHANGELOG、benchmark 資料、以及文件不得被任何商業利益所操控。ATR 的 issue tracker 與 PR review 流程對所有人開放，包括該商業利益的競爭對手——他們可以提規則、可以審你的 PR、可以 fork 整套標準。GOVERNANCE.md 在 GitHub 上公開查閱。中立不是宣稱來的，是這些開放的入口逐一證成的。
如果你觀察到任何違反這個界限的情況，請在 GitHub 開 issue 或寄信至 [email protected]。
所有貢獻都以 MIT 授權發布。貢獻者保留以任何方式使用其攻擊研究的所有權利——ATR 只攜帶偵測，不佔有研究本身。
貢獻者的名字出現在規則的 author 欄位和 metadata_provenance.discovered_by 欄位。當 MISP 匯出到 STIX，當 NIST 引用規則，署名隨著傳遞。