自托管Treg的密鑰暗礁Fernet加密、ACL與四級角色配錯一步照樣裸奔【免費下載鏈接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn項目地址: https://gitcode.com/GitHub_Trending/treg/treg把 3000 個外部 API 端點收斂到一個網(wǎng)關(guān)、把幾十家供應(yīng)商的密鑰托管在服務(wù)器上——treg 這套OpenRouter for agent tools的設(shè)計聽起來很美Agent 只需一個 token就能替你調(diào)用 SEO、社媒、廣告、數(shù)據(jù)富集等真實世界的工具密鑰永不出服務(wù)器。但密鑰不出服務(wù)器有個前提服務(wù)器上那一坨加密落盤的密鑰以及決定誰能用它們的那套權(quán)限必須配得對。社區(qū)里流傳的各種 treg 教程大多停留在怎么把一個 token 調(diào)通的層面真正讓自托管實例裸奔的往往是四件事Fernet 主密鑰沒設(shè)或丟了、角色權(quán)限給了寬、審計日志根本沒被當成安全數(shù)據(jù)看、以及部署時踩了那些默認值暗坑。這篇基于 treg 倉庫源碼逐一拆解最后給一份可以直接照著執(zhí)行的自檢清單。一、Fernet 主密鑰全庫密鑰的總開關(guān)treg 落盤加密選的是 Fernet——對稱加密一個 32 字節(jié) urlsafe base64 主密鑰加密所有 Secret 值?？?crypto.py 的實現(xiàn)整個模塊只有幾十行def _fernet() - Fernet: key get_settings().secret_key return Fernet(key.encode() if key else _EPHEMERAL) def encrypt(plaintext: str) - str: return _fernet().encrypt(plaintext.encode()).decode() def new_key() - str: return Fernet.generate_key().decode()關(guān)鍵就在_fernet()里那個兜底secret_key為空時進程會現(xiàn)場鑄一把臨時密鑰_EPHEMERAL。這意味著什么沒配TREG_SECRET_KEY的服務(wù)照樣能跑、密鑰照樣加密落盤——但重啟后所有密文都無法解密。這不是悄悄丟失而是一個響亮的安全信號代碼注釋原話是secrets wont survive a restart, which is the intended loud signal to set TREG_SECRET_KEY。更狠的防線在 infra/db.py 的verify_db()if not settings.secret_key and sqlite not in settings.database_url: raise RuntimeError( TREG_SECRET_KEY is not set on a non-SQLite database - stored secrets would be lost on the next restart. Set a key (treg keygen) before starting. )也就是說SQLite 本地模式允許臨時密鑰反正數(shù)據(jù)在本機、丟了重連即可但只要你不是 SQLite啟動直接拒絕。這個設(shè)計堵住了拿 Postgres 當生產(chǎn)庫卻不設(shè)密鑰的最蠢路徑。生成與保存密鑰的正確姿勢倉庫自己給的 self-host 腳本寫得很標準見 selfhost.shKEY$($VENV/bin/python -m treg keygen) cat $ENV_FILE EOF TREG_SECRET_KEY$KEY EOF chmod 600 $ENV_FILEpython -m treg keygen見main.py就是new_key()的 CLI 出口.env權(quán)限收成 600。這套流程值得照抄因為大部分自托管事故恰恰反著來密鑰明文進 shell history、.env 權(quán)限 644、或者干脆沒設(shè)。輪換主密鑰輪換其實無解所以要在鑰匙環(huán)里做文章必須直說一個殘酷事實treg 的 Fernet 主密鑰不支持原地輪換。encrypt()與decrypt()用的是同一個TREG_SECRET_KEY一旦換新密鑰舊密文全部解不開唯一的補救是重新錄入/重連所有供應(yīng)商密鑰。倉庫文檔auth-secrets.md和代碼都沒有提供雙密鑰滾動解密的能力。所以對自托管者而言密鑰輪換的現(xiàn)實答案分兩層主密鑰層面能做的只有用 KMS/密鑰管理服務(wù)注入環(huán)境變量 文件權(quán)限 600 備份到密碼管理器把TREG_SECRET_KEY當根 CA 私鑰一樣對待。丟了它 丟了一庫供應(yīng)商憑據(jù)。真正的輪換粒度在 API Key 層面treg 把誰調(diào)用的憑據(jù)treg_xxx開頭的 token和調(diào)用什么的供應(yīng)商憑據(jù)分開管理。調(diào)用方 token 只存 SHA-256 哈希hash_token()見 crypto.py庫中永遠沒有明文 token輪換走rotate_agent_key/rotate_human_keyapi_keys.py用條件 UPDATE 做跨進程原子占鎖result await db.execute( update(ApiKey).where( ApiKey.id old.id, ApiKey.state.in_((ACTIVE, DISABLED)), ApiKey.replacement_key_id.is_(None), ).values(stateREVOKED, revoked_atnow, deleted_atnow) ) if result.rowcount ! 1: raise RotationConflict舊行置為REVOKED并掛replacement_key_id舊 token 當場失效同時保留審計痕跡。對Default key每名成員每團隊一張的簽名 token輪換走default_generation自增rotate_default_generationtoken 里簽的kgclaim 對不上就直接 401revoked key。教訓把輪換的預(yù)期放在調(diào)用方 token 上而不是主密鑰上。主密鑰設(shè)計成不可輪換意味著你必須保證它從一開始就不會泄露——這比能輪換更考驗部署紀律。另外注意 config.py 里一個極易被忽略的細節(jié)session_secret簽名會話 cookie 的 HMAC 密鑰未設(shè)置時回退到secret_key。也就是說如果你只設(shè)了一個強secret_key而session_secret為空那么拿到secret_key的人同時能偽造會話 cookie——密鑰隔離形同虛設(shè)。生產(chǎn)環(huán)境兩個都應(yīng)顯式設(shè)置成不同的隨機值。二、四級角色與 ACL最危險的權(quán)限不是給了 admintreg 的角色模型是四級owner admin member viewer定義在 models.pyROLE_RANK {viewer: 0, member: 1, admin: 2, owner: 3}角色的分界點在哪里看 access.py 的_require_can_registerdef _require_can_register(caller: Caller) - None: if not _role_at_least(caller.role, member): raise HTTPException(status_code403, detailviewers can call and read, but cannot register)一句話概括viewer 能調(diào)用、能讀但什么都不能注冊不能建 Secret、不能注冊工具、不能發(fā)起 OAuth。routers/api_keys.py里 viewer 連創(chuàng)建附加 key都被拒絕viewers cannot create additional keys。invite 的--role可選值也只有viewer/member/admincli.pyowner 只能通過改角色接口授予。兩個最容易被誤解的坑坑一owner 不受任何 ACL 限制而 deny 規(guī)則連 owner 都攔?？?access.pydef _tool_allowed(caller: Caller, tool_name: str) - bool: if caller.role owner: return True access caller.membership.tool_access return access is None or tool_name in accessowner 在工具級 ACL 和項目級 ACL_project_allowed面前一律放行——這是刻意的owner is never restricted但意味著把一個人升成 owner就等于把團隊所有密鑰的使用權(quán)都交給他。反過來enforce_deny的注釋寫得明明白白deny 規(guī)則對包括 owner 在內(nèi)的所有角色生效因為deny rule is a guardrail, not a permission tier?？佣募壗巧皇亲詸?quán)限的標尺真正的精細管控在 Membership 行上。每個成員有一行Membershipmodels.py上面可以單獨釘三樣東西tool_accessNULL 團隊全部工具JSON 列表 只允許列出的工具project_accessNULL 整個 orgJSON 列表 只允許這些項目里的工具daily_call_cap每人每日調(diào)用上限-1 不限配合local_run_enabled控制能否走本地 run 授權(quán)。兩把 ACL 鎖的關(guān)系是AND 組合_tool_usable_tool_allowed且_project_allowed。換句話說最小權(quán)限的正確姿勢不是給 viewer 還是 member而是給協(xié)作方 member 角色 tool_access釘?shù)絺€別工具 project_access釘?shù)絾蝹€項目 daily_call_cap設(shè)上限。四級角色管能不能注冊ACL 管能用哪些缺一不可。還有一個隱蔽的坑invite 接口models.py 的Invite在tool_access字段上就能預(yù)置 ACL——發(fā)邀請時就釘好工具名單而不是等人進來再逐項改。自托管團隊如果靠先發(fā) member 邀請、事后收權(quán)邀請窗口期就是權(quán)限敞口。別忽視機器身份這條暗線treg 里 Agent 是不可登錄的機器身份郵箱掛在agents.treg.local這種不可路由域上access.py任何登錄門都解析不到它而它作為 User 卻能繼承 Membership 的所有能力。require_identity里專門防了一手if user is not None and _is_machine_email(user.email): raise HTTPException(status_code403, detail( this token belongs to a machine identity — it can call this teams tools, but cannot act as a user))機器 token 不能建 org、不能收邀請——因為機器能建 org 就自動成為 ownerowner 又豁免所有 ACL。這是倉庫里自己寫明的逃逸路徑自托管時給 Agent 發(fā) key 也請遵循同樣的最小權(quán)限專用 token、釘死的tool_access、獨立的daily_call_cap。三、審計日志的盲區(qū)它是盡力而為的不是證據(jù)鏈如果你把CallRecordmodels.py當誰在什么時候調(diào)了什么的完整賬本那就踩進最大的盲區(qū)了。審計子系統(tǒng)audit.py的設(shè)計哲學模塊 docstring 第一句就是Audit writes — deferred and fire-and-forget (rule #2: never block the proxied response).具體機制是單進程單 writer、批量落庫、后臺連接池以及背壓丟行_MAX_PENDING 5000 # shed load past this: drop the audit row rather than grow unbounded _BATCH 200隊列超過 5000 條就直接丟審計行只記一個遞增計數(shù)器并打日志。這是刻意的取舍——audit is best-effort; never OOM or wedge the server for it。所以審計表可能缺行。峰值流量下丟的正是最需要查的那幾筆。做安全復盤時不能把審計表里沒有當成沒發(fā)生。審計與計費分離。CallRecord注釋明確錢在 ledger 里同步落地審計表是允許丟行的分析數(shù)據(jù)the money landed in the ledger synchronously... losing a row here costs analytics, not accounting。查成本走 ledger查行為走 audit兩套數(shù)據(jù)源對不齊時別慌。失敗靜默但有 ERROR 日志。寫庫失敗不會打斷調(diào)用an audit hiccup must never break a real call但會打ERROR級日志。運維上必須把 treg 的 ERROR 日志當警報接住——正常流量下 audit writer 不該報錯一旦出現(xiàn)說明審計鏈路已破。對安全審計而言更值得盯的三張表/字段ApiKeyEventappend-only 的 key 管理審計記錄 created / rotated / revoked / membership_revoked且從不含完整密鑰材料——輪換、吊銷都有痕。CallRecord.refused_by凡是 treg 主動拒絕的調(diào)用ACL 拒絕、deny 規(guī)則、密鑰失效都標refused_by。大量refused_by就是攻擊探測的信號比正常調(diào)用日志值錢得多。refresh token 重用檢測application/auth.py已輪換的 refresh token 被再次使用會吊銷整條 grant family并記oauth.refresh_reuse審計行——這是倉庫內(nèi)置的憑據(jù)被復制檢測器看到它基本等于有人在偷用你的授權(quán)。另一個盲區(qū)在本地 run 授權(quán)treg run --local的 grant 是唯一被允許把密鑰值交給客戶端的路徑api.py但它有兩道閘——local_run_enabled成員開關(guān) 共享密鑰必須通過持有X-Treg-Run-Proof的隔離 runner。審計里對應(yīng)GRANT/DENY事件。自托管時如果開了--server運行run_allowed_bins允許列表務(wù)必盯RunRecord的argv它是服務(wù)器以服務(wù)賬號執(zhí)行了哪些命令的唯一記錄。四、自托管安全自檢清單基于以上源碼證據(jù)給一份能直接照著執(zhí)行的清單。按會導致裸奔的嚴重程度排序第一優(yōu)先密鑰與加密用python -m treg keygen生成TREG_SECRET_KEY寫入.env并chmod 600不要進 shell history、不要進代碼倉庫。非 SQLite 數(shù)據(jù)庫未設(shè)密鑰會拒絕啟動——請把這條當成部署回歸測試跑一遍故意去掉變量確認它拒絕。顯式設(shè)置獨立的session_secret不要讓它回退到secret_keyconfig.py 第 601 行附近。主密鑰不可輪換備份到密碼管理器/KMS一旦疑似泄露按全量重新錄入供應(yīng)商憑據(jù) 輪換全部調(diào)用方 token處理。調(diào)用方 token 只存哈?？吹絫reg_明文出現(xiàn)在任何日志/備份里即為事故。第二優(yōu)先角色與 ACL按能注冊才 member、只調(diào)用就 viewer分派角色invite 時就釘好tool_access/project_access不留先進來后收權(quán)的窗口。給協(xié)作方和 Agent 用member/專用 key 工具白名單 項目白名單 每日調(diào)用上限四件套而不是簡單發(fā) owner/admin。記住 owner 豁免所有 ACL_tool_allowed對 owner 恒真——owner 名額是團隊內(nèi)最敏感的權(quán)限。Agent 用機器身份agents.treg.local域 token永遠別給機器身份發(fā)能建 org的權(quán)限。檢查require_superadmin依賴的TREG_ADMIN_TOKENconfig.py 注釋it sees ALL orgs——這個 env 兜底如果設(shè)得短或泄露等于跨租戶 admin 全開。默認留空、靠is_superadmin用戶是更穩(wěn)的姿勢。第三優(yōu)先審計與運行審計是盡力而為且會在背壓時丟行把 treg 進程的ERROR日志接進監(jiān)控audit back-pressure出現(xiàn)即擴容或排查。定期掃CallRecord.refused_by非空的行、oauth.refresh_reuse審計事件、ApiKeyEvent的 revoked/rotated 記錄。若啟用treg run --server嚴格維護run_allowed_bins白名單默認不允許任意二進制注釋明確a member cant namebash/pythonand run arbitrary code as the server user。檢查.env里TREG_BLOCKED_EMAIL_DOMAINS、TREG_PAUSED_PROVIDERS、webhook 目標是否按需配置——這些默認都是不攔/不暫停/不告警的安全面配置。最后一條紀律treg 的 selfhost.sh 里那句話值得反復讀——Never point TREG_PUBLIC_URL at a public domain while TREG_SINGLE_USER is true: the no-login dashboard refuses to run anywhere but loopback sqlite。單用戶免登錄模式是被代碼強制鎖在 loopback 的你只要把TREG_SINGLE_USERtrue的實例暴露到公網(wǎng)域名就等于親手拆掉認證。配錯一步照樣裸奔的每一個字都對應(yīng)上面某一條默認值或某個我以為沒關(guān)系的開關(guān)。把這四組檢查放進部署流水線treg 的密鑰永不出服務(wù)器才真正成立?！久赓M下載鏈接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn項目地址: https://gitcode.com/GitHub_Trending/treg/treg創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 自托管Treg的密鑰暗礁：Fernet加密、ACL與四級角色，配錯一步照樣裸奔
自托管Treg的密鑰暗礁Fernet加密、ACL與四級角色配錯一步照樣裸奔【免費下載鏈接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn項目地址: https://gitcode.com/GitHub_Trending/treg/treg把 3000 個外部 API 端點收斂到一個網(wǎng)關(guān)、把幾十家供應(yīng)商的密鑰托管在服務(wù)器上——treg 這套OpenRouter for agent tools的設(shè)計聽起來很美Agent 只需一個 token就能替你調(diào)用 SEO、社媒、廣告、數(shù)據(jù)富集等真實世界的工具密鑰永不出服務(wù)器。但密鑰不出服務(wù)器有個前提服務(wù)器上那一坨加密落盤的密鑰以及決定誰能用它們的那套權(quán)限必須配得對。社區(qū)里流傳的各種 treg 教程大多停留在怎么把一個 token 調(diào)通的層面真正讓自托管實例裸奔的往往是四件事Fernet 主密鑰沒設(shè)或丟了、角色權(quán)限給了寬、審計日志根本沒被當成安全數(shù)據(jù)看、以及部署時踩了那些默認值暗坑。這篇基于 treg 倉庫源碼逐一拆解最后給一份可以直接照著執(zhí)行的自檢清單。一、Fernet 主密鑰全庫密鑰的總開關(guān)treg 落盤加密選的是 Fernet——對稱加密一個 32 字節(jié) urlsafe base64 主密鑰加密所有 Secret 值?？?crypto.py 的實現(xiàn)整個模塊只有幾十行def _fernet() - Fernet: key get_settings().secret_key return Fernet(key.encode() if key else _EPHEMERAL) def encrypt(plaintext: str) - str: return _fernet().encrypt(plaintext.encode()).decode() def new_key() - str: return Fernet.generate_key().decode()關(guān)鍵就在_fernet()里那個兜底secret_key為空時進程會現(xiàn)場鑄一把臨時密鑰_EPHEMERAL。這意味著什么沒配TREG_SECRET_KEY的服務(wù)照樣能跑、密鑰照樣加密落盤——但重啟后所有密文都無法解密。這不是悄悄丟失而是一個響亮的安全信號代碼注釋原話是secrets wont survive a restart, which is the intended loud signal to set TREG_SECRET_KEY。更狠的防線在 infra/db.py 的verify_db()if not settings.secret_key and sqlite not in settings.database_url: raise RuntimeError( TREG_SECRET_KEY is not set on a non-SQLite database - stored secrets would be lost on the next restart. Set a key (treg keygen) before starting. )也就是說SQLite 本地模式允許臨時密鑰反正數(shù)據(jù)在本機、丟了重連即可但只要你不是 SQLite啟動直接拒絕。這個設(shè)計堵住了拿 Postgres 當生產(chǎn)庫卻不設(shè)密鑰的最蠢路徑。生成與保存密鑰的正確姿勢倉庫自己給的 self-host 腳本寫得很標準見 selfhost.shKEY$($VENV/bin/python -m treg keygen) cat $ENV_FILE EOF TREG_SECRET_KEY$KEY EOF chmod 600 $ENV_FILEpython -m treg keygen見main.py就是new_key()的 CLI 出口.env權(quán)限收成 600。這套流程值得照抄因為大部分自托管事故恰恰反著來密鑰明文進 shell history、.env 權(quán)限 644、或者干脆沒設(shè)。輪換主密鑰輪換其實無解所以要在鑰匙環(huán)里做文章必須直說一個殘酷事實treg 的 Fernet 主密鑰不支持原地輪換。encrypt()與decrypt()用的是同一個TREG_SECRET_KEY一旦換新密鑰舊密文全部解不開唯一的補救是重新錄入/重連所有供應(yīng)商密鑰。倉庫文檔auth-secrets.md和代碼都沒有提供雙密鑰滾動解密的能力。所以對自托管者而言密鑰輪換的現(xiàn)實答案分兩層主密鑰層面能做的只有用 KMS/密鑰管理服務(wù)注入環(huán)境變量 文件權(quán)限 600 備份到密碼管理器把TREG_SECRET_KEY當根 CA 私鑰一樣對待。丟了它 丟了一庫供應(yīng)商憑據(jù)。真正的輪換粒度在 API Key 層面treg 把誰調(diào)用的憑據(jù)treg_xxx開頭的 token和調(diào)用什么的供應(yīng)商憑據(jù)分開管理。調(diào)用方 token 只存 SHA-256 哈希hash_token()見 crypto.py庫中永遠沒有明文 token輪換走rotate_agent_key/rotate_human_keyapi_keys.py用條件 UPDATE 做跨進程原子占鎖result await db.execute( update(ApiKey).where( ApiKey.id old.id, ApiKey.state.in_((ACTIVE, DISABLED)), ApiKey.replacement_key_id.is_(None), ).values(stateREVOKED, revoked_atnow, deleted_atnow) ) if result.rowcount ! 1: raise RotationConflict舊行置為REVOKED并掛replacement_key_id舊 token 當場失效同時保留審計痕跡。對Default key每名成員每團隊一張的簽名 token輪換走default_generation自增rotate_default_generationtoken 里簽的kgclaim 對不上就直接 401revoked key。教訓把輪換的預(yù)期放在調(diào)用方 token 上而不是主密鑰上。主密鑰設(shè)計成不可輪換意味著你必須保證它從一開始就不會泄露——這比能輪換更考驗部署紀律。另外注意 config.py 里一個極易被忽略的細節(jié)session_secret簽名會話 cookie 的 HMAC 密鑰未設(shè)置時回退到secret_key。也就是說如果你只設(shè)了一個強secret_key而session_secret為空那么拿到secret_key的人同時能偽造會話 cookie——密鑰隔離形同虛設(shè)。生產(chǎn)環(huán)境兩個都應(yīng)顯式設(shè)置成不同的隨機值。二、四級角色與 ACL最危險的權(quán)限不是給了 admintreg 的角色模型是四級owner admin member viewer定義在 models.pyROLE_RANK {viewer: 0, member: 1, admin: 2, owner: 3}角色的分界點在哪里看 access.py 的_require_can_registerdef _require_can_register(caller: Caller) - None: if not _role_at_least(caller.role, member): raise HTTPException(status_code403, detailviewers can call and read, but cannot register)一句話概括viewer 能調(diào)用、能讀但什么都不能注冊不能建 Secret、不能注冊工具、不能發(fā)起 OAuth。routers/api_keys.py里 viewer 連創(chuàng)建附加 key都被拒絕viewers cannot create additional keys。invite 的--role可選值也只有viewer/member/admincli.pyowner 只能通過改角色接口授予。兩個最容易被誤解的坑坑一owner 不受任何 ACL 限制而 deny 規(guī)則連 owner 都攔?？?access.pydef _tool_allowed(caller: Caller, tool_name: str) - bool: if caller.role owner: return True access caller.membership.tool_access return access is None or tool_name in accessowner 在工具級 ACL 和項目級 ACL_project_allowed面前一律放行——這是刻意的owner is never restricted但意味著把一個人升成 owner就等于把團隊所有密鑰的使用權(quán)都交給他。反過來enforce_deny的注釋寫得明明白白deny 規(guī)則對包括 owner 在內(nèi)的所有角色生效因為deny rule is a guardrail, not a permission tier?？佣募壗巧皇亲詸?quán)限的標尺真正的精細管控在 Membership 行上。每個成員有一行Membershipmodels.py上面可以單獨釘三樣東西tool_accessNULL 團隊全部工具JSON 列表 只允許列出的工具project_accessNULL 整個 orgJSON 列表 只允許這些項目里的工具daily_call_cap每人每日調(diào)用上限-1 不限配合local_run_enabled控制能否走本地 run 授權(quán)。兩把 ACL 鎖的關(guān)系是AND 組合_tool_usable_tool_allowed且_project_allowed。換句話說最小權(quán)限的正確姿勢不是給 viewer 還是 member而是給協(xié)作方 member 角色 tool_access釘?shù)絺€別工具 project_access釘?shù)絾蝹€項目 daily_call_cap設(shè)上限。四級角色管能不能注冊ACL 管能用哪些缺一不可。還有一個隱蔽的坑invite 接口models.py 的Invite在tool_access字段上就能預(yù)置 ACL——發(fā)邀請時就釘好工具名單而不是等人進來再逐項改。自托管團隊如果靠先發(fā) member 邀請、事后收權(quán)邀請窗口期就是權(quán)限敞口。別忽視機器身份這條暗線treg 里 Agent 是不可登錄的機器身份郵箱掛在agents.treg.local這種不可路由域上access.py任何登錄門都解析不到它而它作為 User 卻能繼承 Membership 的所有能力。require_identity里專門防了一手if user is not None and _is_machine_email(user.email): raise HTTPException(status_code403, detail( this token belongs to a machine identity — it can call this teams tools, but cannot act as a user))機器 token 不能建 org、不能收邀請——因為機器能建 org 就自動成為 ownerowner 又豁免所有 ACL。這是倉庫里自己寫明的逃逸路徑自托管時給 Agent 發(fā) key 也請遵循同樣的最小權(quán)限專用 token、釘死的tool_access、獨立的daily_call_cap。三、審計日志的盲區(qū)它是盡力而為的不是證據(jù)鏈如果你把CallRecordmodels.py當誰在什么時候調(diào)了什么的完整賬本那就踩進最大的盲區(qū)了。審計子系統(tǒng)audit.py的設(shè)計哲學模塊 docstring 第一句就是Audit writes — deferred and fire-and-forget (rule #2: never block the proxied response).具體機制是單進程單 writer、批量落庫、后臺連接池以及背壓丟行_MAX_PENDING 5000 # shed load past this: drop the audit row rather than grow unbounded _BATCH 200隊列超過 5000 條就直接丟審計行只記一個遞增計數(shù)器并打日志。這是刻意的取舍——audit is best-effort; never OOM or wedge the server for it。所以審計表可能缺行。峰值流量下丟的正是最需要查的那幾筆。做安全復盤時不能把審計表里沒有當成沒發(fā)生。審計與計費分離。CallRecord注釋明確錢在 ledger 里同步落地審計表是允許丟行的分析數(shù)據(jù)the money landed in the ledger synchronously... losing a row here costs analytics, not accounting。查成本走 ledger查行為走 audit兩套數(shù)據(jù)源對不齊時別慌。失敗靜默但有 ERROR 日志。寫庫失敗不會打斷調(diào)用an audit hiccup must never break a real call但會打ERROR級日志。運維上必須把 treg 的 ERROR 日志當警報接住——正常流量下 audit writer 不該報錯一旦出現(xiàn)說明審計鏈路已破。對安全審計而言更值得盯的三張表/字段ApiKeyEventappend-only 的 key 管理審計記錄 created / rotated / revoked / membership_revoked且從不含完整密鑰材料——輪換、吊銷都有痕。CallRecord.refused_by凡是 treg 主動拒絕的調(diào)用ACL 拒絕、deny 規(guī)則、密鑰失效都標refused_by。大量refused_by就是攻擊探測的信號比正常調(diào)用日志值錢得多。refresh token 重用檢測application/auth.py已輪換的 refresh token 被再次使用會吊銷整條 grant family并記oauth.refresh_reuse審計行——這是倉庫內(nèi)置的憑據(jù)被復制檢測器看到它基本等于有人在偷用你的授權(quán)。另一個盲區(qū)在本地 run 授權(quán)treg run --local的 grant 是唯一被允許把密鑰值交給客戶端的路徑api.py但它有兩道閘——local_run_enabled成員開關(guān) 共享密鑰必須通過持有X-Treg-Run-Proof的隔離 runner。審計里對應(yīng)GRANT/DENY事件。自托管時如果開了--server運行run_allowed_bins允許列表務(wù)必盯RunRecord的argv它是服務(wù)器以服務(wù)賬號執(zhí)行了哪些命令的唯一記錄。四、自托管安全自檢清單基于以上源碼證據(jù)給一份能直接照著執(zhí)行的清單。按會導致裸奔的嚴重程度排序第一優(yōu)先密鑰與加密用python -m treg keygen生成TREG_SECRET_KEY寫入.env并chmod 600不要進 shell history、不要進代碼倉庫。非 SQLite 數(shù)據(jù)庫未設(shè)密鑰會拒絕啟動——請把這條當成部署回歸測試跑一遍故意去掉變量確認它拒絕。顯式設(shè)置獨立的session_secret不要讓它回退到secret_keyconfig.py 第 601 行附近。主密鑰不可輪換備份到密碼管理器/KMS一旦疑似泄露按全量重新錄入供應(yīng)商憑據(jù) 輪換全部調(diào)用方 token處理。調(diào)用方 token 只存哈?？吹絫reg_明文出現(xiàn)在任何日志/備份里即為事故。第二優(yōu)先角色與 ACL按能注冊才 member、只調(diào)用就 viewer分派角色invite 時就釘好tool_access/project_access不留先進來后收權(quán)的窗口。給協(xié)作方和 Agent 用member/專用 key 工具白名單 項目白名單 每日調(diào)用上限四件套而不是簡單發(fā) owner/admin。記住 owner 豁免所有 ACL_tool_allowed對 owner 恒真——owner 名額是團隊內(nèi)最敏感的權(quán)限。Agent 用機器身份agents.treg.local域 token永遠別給機器身份發(fā)能建 org的權(quán)限。檢查require_superadmin依賴的TREG_ADMIN_TOKENconfig.py 注釋it sees ALL orgs——這個 env 兜底如果設(shè)得短或泄露等于跨租戶 admin 全開。默認留空、靠is_superadmin用戶是更穩(wěn)的姿勢。第三優(yōu)先審計與運行審計是盡力而為且會在背壓時丟行把 treg 進程的ERROR日志接進監(jiān)控audit back-pressure出現(xiàn)即擴容或排查。定期掃CallRecord.refused_by非空的行、oauth.refresh_reuse審計事件、ApiKeyEvent的 revoked/rotated 記錄。若啟用treg run --server嚴格維護run_allowed_bins白名單默認不允許任意二進制注釋明確a member cant namebash/pythonand run arbitrary code as the server user。檢查.env里TREG_BLOCKED_EMAIL_DOMAINS、TREG_PAUSED_PROVIDERS、webhook 目標是否按需配置——這些默認都是不攔/不暫停/不告警的安全面配置。最后一條紀律treg 的 selfhost.sh 里那句話值得反復讀——Never point TREG_PUBLIC_URL at a public domain while TREG_SINGLE_USER is true: the no-login dashboard refuses to run anywhere but loopback sqlite。單用戶免登錄模式是被代碼強制鎖在 loopback 的你只要把TREG_SINGLE_USERtrue的實例暴露到公網(wǎng)域名就等于親手拆掉認證。配錯一步照樣裸奔的每一個字都對應(yīng)上面某一條默認值或某個我以為沒關(guān)系的開關(guān)。把這四組檢查放進部署流水線treg 的密鑰永不出服務(wù)器才真正成立?！久赓M下載鏈接】tregOpenRouter for agent tools. Join community here: https://discord.gg/6mQYYfFMAn項目地址: https://gitcode.com/GitHub_Trending/treg/treg創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考