指南)
為 AI 代理的 Review 動作編寫 Cedar 審批門控策略review-agent-governance 策略編寫實戰(zhàn)指南【免費下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文面向需要為 Claude Code 等 AI 代理配置「審查面review-surface門控」的團隊系統(tǒng)講解如何基于 Cedar 授權(quán)語言編寫、擴展與審計 review-governance 策略把 AI 代理發(fā)布 PR 評論、審批合并、編輯 CI 配置等高危動作牢牢關(guān)在人類審批這道門之后并借助 Ed25519 簽名收據(jù)鏈實現(xiàn)可離線驗證的審計證據(jù)。一、為什么需要「審查面門控」本文要解決的故障模式AI 代理一旦擁有對 GitHub CLI 或 GitHub API 的無限制訪問權(quán)限就可能出現(xiàn)一系列嚴重后果發(fā)布幻覺式 review 評論、以虛構(gòu)的理由審批 PR、錯誤地關(guān)閉 issue或悄悄改寫 workflow 文件從而繞過其他安全控制。這類事故的特點是即時、可見且往往被歸責(zé)到運行代理的那個賬號頭上——這正是 review-agent-governance 插件中review-policy-author代理定義于 agents/review-policy-author.md所針對的核心故障模式。review-policy-author是一個專門負責(zé)編寫、審計和擴展 Cedar 審查面門控策略的專家代理。它的職責(zé)范圍是決定 AI 代理在未經(jīng)人類審批的情況下是否被允許發(fā)布 review、評論 issue、合并 PR、修改 CI 配置。審查面門控review-surface gating正是防止這一類事故的通用模式。二、審查面由哪些「命令模式與路徑」構(gòu)成要寫出有效的門控策略必須先完整枚舉各大平臺的審查面命令模式。review-policy-author明確了以下幾類必須被門控的路徑GitHub通過ghCLIgh pr review、gh pr comment、gh pr merge、gh pr close、gh pr edit、gh pr ready、gh issue comment、gh issue close、gh issue edit、gh release create、gh release edit、gh api repos/.../comments、gh api repos/.../reviews、gh api repos/.../pulls/.../mergeGitLab通過glabglab mr comment、glab mr approve、glab mr merge、glab mr close、glab issue comment、glab issue close、glab release createBitbucket通過bbCLI 或直接 API 調(diào)用。必須人工門控的 CI/CD 路徑.github/workflows/、.github/CODEOWNERS、.gitlab-ci.yml、.circleci/config.yml、buildkite/pipeline.yml、Jenkinsfile、azure-pipelines.yml必須門控的保護分支main、master、release、production、prod、stable通知面容易放大幻覺的傳播渠道Slack webhookshooks.slack.com、Discord webhooks、Teams webhooks、PagerDuty 事件、任何郵件 API這些枚舉不是空談——插件自帶的默認策略 review-agent-governance.cedar 就把其中的核心子集落成了可執(zhí)行的forbid規(guī)則詳見下文第四節(jié)。三、編寫 review-governance 策略的六條原則review-policy-author給出了編寫策略時的六條操作準則這也是把「審查面」落成 Cedar 策略的標準流程1. 從插件的默認策略起步。將plugins/review-agent-governance/policies/review-agent-governance.cedar復(fù)制到項目根目錄的./review-governance.cedar再開始編輯。默認策略已覆蓋 GitHub / GitLab、保護分支與 CI 路徑是一個可靠的基線。2. 針對項目特有的審查面做擴展。如果團隊使用 Linear、Jira、Notion 或自研 review 工具為這些工具用到的 CLI 命令模式或 WebFetch 主機補充forbid規(guī)則。3. 絕不門控只讀操作。gh pr view、gh issue list、API GET 請求都允許代理無人值守地執(zhí)行門控只針對 write / post / merge / close 這類寫動作。4. 按分支名而非路徑門控分支。使用context.target_branch in [main, ...]而不是context.resource_path starts with refs/heads/main——分支名才是人類推理的依據(jù)。5. 必須包含通知面。Slack 與 Discord webhook 是 review-bot 幻覺被放大的地方要門控對這些主機的 POST 請求。6. 不要動非 review 動作。該策略聚焦于審查面在末尾放一條寬松的permit (principal, action, resource);讓其余一切放行。如需更廣泛的策略強制與protect-mcp插件組合使用。四、默認策略逐條拆解審查面門控的落地實現(xiàn)默認策略 review-agent-governance.cedar 是理解這套門控體系的最佳入口它包含 5 條forbid規(guī)則與 1 條兜底permit。每條規(guī)則的作用域與實現(xiàn)要點如下規(guī)則 1門控ghCLI 的審查面動作forbid ( principal, action Action::Bash, resource ) when { [gh pr review, gh pr comment, gh pr close, gh pr merge, gh pr edit, gh issue comment, gh issue close, gh issue edit, gh release create, gh release edit, gh api repos].contains(context.command_pattern) };注意gh api repos是刻意保留的通配前綴它攔截任意 GitHub REST 調(diào)用防止代理用gh api repos/X/Y/pulls/42/reviews繞過基于命令模式command-pattern的規(guī)則。規(guī)則 2門控 GitLab / Bitbucket CLIforbid ( principal, action Action::Bash, resource ) when { [glab mr comment, glab mr approve, glab mr merge, glab issue comment].contains(context.command_pattern) };規(guī)則 3門控對保護分支的 git pushforbid ( principal, action Action::Bash, resource ) when { [git push, git push --force, git push -f].contains(context.command_pattern) context has target_branch [main, master, release, production].contains(context.target_branch) };注意context has target_branch這一存在性判斷——只有命令上下文確實攜帶目標分支信息時才觸發(fā)判斷。規(guī)則 4門控對 CI/CD 配置文件的直接寫入forbid ( principal, action in [Action::Write, Action::Edit], resource ) when { [.github/workflows/, .github/CODEOWNERS, .gitlab-ci.yml, .circleci/config.yml, buildkite/pipeline.yml].contains(context.path_starts_with) };修改這些文件等于讓代理改變未來構(gòu)建與 review 的運行方式從而繞過其他所有防護因此必須無條件要求人類審批。規(guī)則 5門控對已知 review / 聊天平臺的 WebFetch POSTforbid ( principal, action Action::WebFetch, resource ) when { context.method POST [api.github.com, api.gitlab.com, api.bitbucket.org, hooks.slack.com, discord.com].contains(context.url_host) };兜底規(guī)則放行一切其他動作permit (principal, action, resource);這印證了review-policy-author的原則 6該插件聚焦審查面非 review 動作原樣放行如需通用工具調(diào)用策略強制可并排安裝 protect-mcp。策略的 Schema 契約與策略配套的 review-agent-governance.cedarschema 定義了策略引用的實體與動作上下文類型它決定了每條規(guī)則可用的context字段entity User; entity Resource; action Bash appliesTo { principal: [User], resource: [Resource], context: { command_pattern: String, target_branch?: String } }; action Write appliesTo { principal: [User], resource: [Resource], context: { path_starts_with: String } }; action Edit appliesTo { principal: [User], resource: [Resource], context: { path_starts_with: String } }; action WebFetch appliesTo { principal: [User], resource: [Resource], context: { method: String, url_host: String } };可以看到Bash動作攜帶command_pattern與可選的target_branchWrite/Edit攜帶path_starts_withWebFetch攜帶method與url_host。默認策略中的 5 條 forbid 規(guī)則正是精確消費這些上下文字段——這也是為什么審計策略時必須保證 schema 與實際使用的 context 屬性一致。一個值得警惕的語言陷阱in-on-String 會被靜默丟棄倉庫的測試 test/README.md 與 run-tests.sh 專門防護了一個 Cedar 語言陷阱對應(yīng)上游 issue #598在forbid規(guī)則里寫context.attr in [ ... ]形式Cedar 會靜默丟棄該規(guī)則導(dǎo)致門控悄悄失效。正確寫法是[ ... ].contains(context.attr)。測試腳本的 Part A只需要grep任何環(huán)境都能跑做兩件事一是斷言策略中不存在context.attr in [的 bug 形態(tài)先扁平化空白防止跨行換行繞過檢查二是斷言策略確實使用了[ ... ].contains(context.attr)的修正寫法。Part B 則僅在安裝了cedarCLI 時運行cedar validate --policies ... --schema ...利用 schema 中 context 屬性為String類型這一事實在加載期拒絕in-on-String 形式、接受.contains()形式。默認策略中大量.contains(context.command_pattern)寫法正是這一防御的直接體現(xiàn)。五、三類典型擴展把默認策略適配到你的項目review-policy-author給出了三個可直接復(fù)制的擴展模板。5.1 使用 Linear 做 issue 分診的團隊禁止代理用 CLI 操作 Linear并禁止對api.linear.app發(fā)起寫型 WebFetchforbid ( principal, action Action::Bash, resource ) when { context.command_pattern starts with linear }; forbid ( principal, action Action::WebFetch, resource ) when { context.method POST context.url_host api.linear.app };5.2 使用自研內(nèi)部 review bot 的團隊forbid ( principal, action Action::WebFetch, resource ) when { context.method in [POST, PUT, PATCH, DELETE] context.url_host in [ review-bot.internal.company.com, code-review.internal.company.com ] };5.3 允許專用 bot 賬號、禁止個人賬號當團隊希望讓運行在專屬「automation」身份下的代理執(zhí)行 review而不允許開發(fā)者個人賬號執(zhí)行時可用「精確permit 兜底forbid」的組合permit ( principal Principal::gh-bot-reviewer, action Action::Bash, resource ) when { context.command_pattern in [gh pr comment] }; forbid ( principal, action Action::Bash, resource ) unless { principal Principal::gh-bot-reviewer || context.human_approved true };注意這個forbid ... unless結(jié)構(gòu)除 bot 賬號外其余主體只有攜帶human_approved true上下文時才能通過。六、審計一份既有策略的五個檢查點當需要審查一份review-governance.cedar時review-policy-author建議按以下順序逐項核對命令覆蓋確認團隊使用的每一條審查面 CLI 命令都有對應(yīng)的forbid規(guī)則。API 覆蓋缺口檢查gh api repos這類通配規(guī)則是否在。缺少它代理可以用gh api repos/X/Y/pulls/42/reviews繞過所有基于命令模式的規(guī)則。保護分支覆蓋驗證保護分支的git push規(guī)則覆蓋了倉庫設(shè)置中實際處于保護狀態(tài)的所有分支。CI/CD 路徑匹配確認 CI/CD 路徑規(guī)則與本項目真正起門控作用的文件一致例如有些團隊用deployment/而非.github/workflows/。默認放行規(guī)則不覆蓋先前的 forbid檢查末尾的默認放行規(guī)則不會覆蓋更早的forbid。Cedar 中forbid是權(quán)威的后續(xù)的permit無法解除它。七、門控體系如何運轉(zhuǎn)從策略到鉤子到收據(jù)鏈策略本身只是一半另一半是運行時執(zhí)行機制。該插件通過兩個鉤子定義于 hooks/hooks.json包住 Claude Code 的每一次工具調(diào)用PreToolUse 鉤子門控決策if [ -f ${REVIEW_APPROVAL_FLAG:-./.review-approved} ]; then exit 0; fi; \ npx protect-mcp0.7.4 evaluate --policy ${REVIEW_GOVERNANCE_POLICY:-./review-governance.cedar} \ --tool $TOOL_NAME --input $TOOL_INPUT --fail-on-missing-policy false若存在./.review-approved審批標記文件或REVIEW_APPROVAL_FLAG指定的替代路徑直接exit 0放行否則調(diào)用protect-mcp evaluate用 Cedar 策略評估該工具調(diào)用Cedar 判定 deny 時工具調(diào)用以退出碼 2 結(jié)束Claude Code 隨即阻止它。PostToolUse 鉤子簽名取證npx protect-mcp0.7.4 sign --tool $TOOL_NAME --input $TOOL_INPUT --output $TOOL_OUTPUT \ --receipts ${REVIEW_GOVERNANCE_RECEIPTS:-./review-receipts/} \ --key ${REVIEW_GOVERNANCE_KEY:-./review-governance.key}無論該次工具調(diào)用被批準、拒絕還是跳過都會產(chǎn)生一條 Ed25519 簽名收據(jù)收據(jù)鏈精確記錄了什么動作在何時被授權(quán)。審批窗口的打開與關(guān)閉審批窗口通過兩種方式打開方式一標記文件最簡touch ./.review-approved # 讓代理執(zhí)行被批準的動作 rm ./.review-approved方式二斜杠命令Claude Code 內(nèi)/approve-review Posting the code review for #123/approve-review實現(xiàn)見 commands/approve-review.md創(chuàng)建./.review-approved并把審批理由寫入文件與./review-receipts/approvals/下的時間戳 JSON 條目。關(guān)于審批日志的重要提醒./review-receipts/approvals/*.json是明文 JSON 記錄不是簽名收據(jù)。它們不經(jīng)過protect-mcp sign因此veritasacta/verify不覆蓋它們審批日志屬于「操作者信任」——它記錄人類意圖批準什么但事后被編輯也無法被偵測。真正具備防篡改能力的是 PostToolUse 為每次動作無論放行還是拒絕生成的./review-receipts/*.json工具調(diào)用收據(jù)它們才是權(quán)威審計線索。對于受監(jiān)管環(huán)境需要簽名審批記錄的場合可改用npx protect-mcplatest sign --tool approve-review --input ...直接簽名。查看被拒動作/list-pending實現(xiàn)見 commands/list-pending.md遍歷./review-receipts/收據(jù)鏈打印最近的decision: deny條目默認最近 10 條可用--last N調(diào)整展示工具名、命令模式與時間戳并提示可配合/approve-review人工放行后重試。一個完整的「拒絕 → 批準 → 放行」會話以代理想在 PR 上發(fā)布 review 評論為例。未批準時$ agent: gh pr review 42 --comment --body LGTM → PreToolUse hook 運行 → 無 ./.review-approved 文件策略被評估 → Cedar: 對 context.command_pattern gh pr review 判 forbid → 退出碼 2Claude Code 阻止該工具調(diào)用 → PostToolUse 運行簽名一條 decisiondeny 的收據(jù)批準后$ touch ./.review-approved $ agent: gh pr review 42 --comment --body LGTM → PreToolUse hook 運行 → 檢測到 ./.review-approvedexit 0 → 工具調(diào)用執(zhí)行 → PostToolUse 簽名收據(jù)decisionallow, reasonhuman_approved $ rm ./.review-approved關(guān)于簽名鏈的一個審計預(yù)期當審批標記存在時PreToolUse 鉤子短路為exit 0不會調(diào)用protect-mcp evaluate。因此被批準動作對應(yīng)的 PostToolUse 收據(jù)會是decision: allow但沒有policy_digest字段因為沒有評估任何 Cedar 策略。審計人員遍歷收據(jù)鏈時應(yīng)預(yù)期這一現(xiàn)象被批準的工具調(diào)用顯示為帶簽名的收據(jù)、reason: human_approved、無策略引用而被拒絕的工具調(diào)用與非 review 動作它們確實經(jīng)過 Cedar則照常攜帶policy_digest。八、收據(jù)鏈的離線驗證與組合使用驗證整條鏈npx veritasacta/verify ./review-receipts/*.json退出碼語義0表示每條收據(jù)都真實且鏈完整1表示某條收據(jù)被篡改2表示收據(jù)格式損壞。任何持有公鑰的一方都能離線驗證不依賴操作者。與 protect-mcp 組合該插件聚焦審查面若要對所有 Claude Code 工具調(diào)用做通用策略強制可并排安裝 protect-mcp。兩個鉤子都會運行、都會產(chǎn)出收據(jù)可配置不同的收據(jù)目錄如./receipts/與./review-receipts/保持鏈條分離。任一策略判 deny工具調(diào)用即被阻止。九、技術(shù)選型依據(jù)為什么是 Cedar Ed25519 收據(jù)CedarAWS 的開源授權(quán)引擎以聲明式、形式化的方式表達策略審查者閱讀策略即可精確了解什么被門控?zé)o需讀代碼策略可通過cedar validate做類型檢查策略變更可 diff。Ed25519 收據(jù)RFC 8032 簽名、RFC 8785 JCS 確定性規(guī)范化、hash-chained提供不依賴操作者的防篡改證據(jù)。任何篡改都會導(dǎo)致驗證退出碼 1。涉及的完整標準棧Ed25519RFC 8032、JCSRFC 8785、CedarAWS、IETF 草案 draft-farley-acta-signed-receipts收據(jù)格式。十、參考資料與進一步閱讀策略作者代理定義plugins/review-agent-governance/agents/review-policy-author.md插件默認策略plugins/review-agent-governance/policies/review-agent-governance.cedar策略 Schemaplugins/review-agent-governance/policies/review-agent-governance.cedarschema運行時鉤子配置plugins/review-agent-governance/hooks/hooks.json插件完整說明含安裝步驟、審批窗口、示例會話plugins/review-agent-governance/README.md一次性安裝與每會話工作流plugins/review-agent-governance/skills/review-agent-setup/SKILL.md策略語言陷阱防護測試plugins/review-agent-governance/test/run-tests.sh通用策略強制插件可與本插件組合plugins/protect-mcp實際安裝時可先執(zhí)行claude plugin install wshobson/agents/review-agent-governance隨后將默認策略復(fù)制到項目根目錄./review-governance.cedar并按第四節(jié)、第五節(jié)的方法定制最后按第七節(jié)的方式投入運行。如需強制所有工具調(diào)用都走策略評估禁用審批旁路可設(shè)置REVIEW_APPROVAL_FLAG./.never-approve——這在 CI 或鎖定的審計運行中尤為有用?！久赓M下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 為 AI 代理的 Review 動作編寫 Cedar 審批門控策略：review-agent-governance 策略編寫實戰(zhàn)指南
為 AI 代理的 Review 動作編寫 Cedar 審批門控策略review-agent-governance 策略編寫實戰(zhàn)指南【免費下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文面向需要為 Claude Code 等 AI 代理配置「審查面review-surface門控」的團隊系統(tǒng)講解如何基于 Cedar 授權(quán)語言編寫、擴展與審計 review-governance 策略把 AI 代理發(fā)布 PR 評論、審批合并、編輯 CI 配置等高危動作牢牢關(guān)在人類審批這道門之后并借助 Ed25519 簽名收據(jù)鏈實現(xiàn)可離線驗證的審計證據(jù)。一、為什么需要「審查面門控」本文要解決的故障模式AI 代理一旦擁有對 GitHub CLI 或 GitHub API 的無限制訪問權(quán)限就可能出現(xiàn)一系列嚴重后果發(fā)布幻覺式 review 評論、以虛構(gòu)的理由審批 PR、錯誤地關(guān)閉 issue或悄悄改寫 workflow 文件從而繞過其他安全控制。這類事故的特點是即時、可見且往往被歸責(zé)到運行代理的那個賬號頭上——這正是 review-agent-governance 插件中review-policy-author代理定義于 agents/review-policy-author.md所針對的核心故障模式。review-policy-author是一個專門負責(zé)編寫、審計和擴展 Cedar 審查面門控策略的專家代理。它的職責(zé)范圍是決定 AI 代理在未經(jīng)人類審批的情況下是否被允許發(fā)布 review、評論 issue、合并 PR、修改 CI 配置。審查面門控review-surface gating正是防止這一類事故的通用模式。二、審查面由哪些「命令模式與路徑」構(gòu)成要寫出有效的門控策略必須先完整枚舉各大平臺的審查面命令模式。review-policy-author明確了以下幾類必須被門控的路徑GitHub通過ghCLIgh pr review、gh pr comment、gh pr merge、gh pr close、gh pr edit、gh pr ready、gh issue comment、gh issue close、gh issue edit、gh release create、gh release edit、gh api repos/.../comments、gh api repos/.../reviews、gh api repos/.../pulls/.../mergeGitLab通過glabglab mr comment、glab mr approve、glab mr merge、glab mr close、glab issue comment、glab issue close、glab release createBitbucket通過bbCLI 或直接 API 調(diào)用。必須人工門控的 CI/CD 路徑.github/workflows/、.github/CODEOWNERS、.gitlab-ci.yml、.circleci/config.yml、buildkite/pipeline.yml、Jenkinsfile、azure-pipelines.yml必須門控的保護分支main、master、release、production、prod、stable通知面容易放大幻覺的傳播渠道Slack webhookshooks.slack.com、Discord webhooks、Teams webhooks、PagerDuty 事件、任何郵件 API這些枚舉不是空談——插件自帶的默認策略 review-agent-governance.cedar 就把其中的核心子集落成了可執(zhí)行的forbid規(guī)則詳見下文第四節(jié)。三、編寫 review-governance 策略的六條原則review-policy-author給出了編寫策略時的六條操作準則這也是把「審查面」落成 Cedar 策略的標準流程1. 從插件的默認策略起步。將plugins/review-agent-governance/policies/review-agent-governance.cedar復(fù)制到項目根目錄的./review-governance.cedar再開始編輯。默認策略已覆蓋 GitHub / GitLab、保護分支與 CI 路徑是一個可靠的基線。2. 針對項目特有的審查面做擴展。如果團隊使用 Linear、Jira、Notion 或自研 review 工具為這些工具用到的 CLI 命令模式或 WebFetch 主機補充forbid規(guī)則。3. 絕不門控只讀操作。gh pr view、gh issue list、API GET 請求都允許代理無人值守地執(zhí)行門控只針對 write / post / merge / close 這類寫動作。4. 按分支名而非路徑門控分支。使用context.target_branch in [main, ...]而不是context.resource_path starts with refs/heads/main——分支名才是人類推理的依據(jù)。5. 必須包含通知面。Slack 與 Discord webhook 是 review-bot 幻覺被放大的地方要門控對這些主機的 POST 請求。6. 不要動非 review 動作。該策略聚焦于審查面在末尾放一條寬松的permit (principal, action, resource);讓其余一切放行。如需更廣泛的策略強制與protect-mcp插件組合使用。四、默認策略逐條拆解審查面門控的落地實現(xiàn)默認策略 review-agent-governance.cedar 是理解這套門控體系的最佳入口它包含 5 條forbid規(guī)則與 1 條兜底permit。每條規(guī)則的作用域與實現(xiàn)要點如下規(guī)則 1門控ghCLI 的審查面動作forbid ( principal, action Action::Bash, resource ) when { [gh pr review, gh pr comment, gh pr close, gh pr merge, gh pr edit, gh issue comment, gh issue close, gh issue edit, gh release create, gh release edit, gh api repos].contains(context.command_pattern) };注意gh api repos是刻意保留的通配前綴它攔截任意 GitHub REST 調(diào)用防止代理用gh api repos/X/Y/pulls/42/reviews繞過基于命令模式command-pattern的規(guī)則。規(guī)則 2門控 GitLab / Bitbucket CLIforbid ( principal, action Action::Bash, resource ) when { [glab mr comment, glab mr approve, glab mr merge, glab issue comment].contains(context.command_pattern) };規(guī)則 3門控對保護分支的 git pushforbid ( principal, action Action::Bash, resource ) when { [git push, git push --force, git push -f].contains(context.command_pattern) context has target_branch [main, master, release, production].contains(context.target_branch) };注意context has target_branch這一存在性判斷——只有命令上下文確實攜帶目標分支信息時才觸發(fā)判斷。規(guī)則 4門控對 CI/CD 配置文件的直接寫入forbid ( principal, action in [Action::Write, Action::Edit], resource ) when { [.github/workflows/, .github/CODEOWNERS, .gitlab-ci.yml, .circleci/config.yml, buildkite/pipeline.yml].contains(context.path_starts_with) };修改這些文件等于讓代理改變未來構(gòu)建與 review 的運行方式從而繞過其他所有防護因此必須無條件要求人類審批。規(guī)則 5門控對已知 review / 聊天平臺的 WebFetch POSTforbid ( principal, action Action::WebFetch, resource ) when { context.method POST [api.github.com, api.gitlab.com, api.bitbucket.org, hooks.slack.com, discord.com].contains(context.url_host) };兜底規(guī)則放行一切其他動作permit (principal, action, resource);這印證了review-policy-author的原則 6該插件聚焦審查面非 review 動作原樣放行如需通用工具調(diào)用策略強制可并排安裝 protect-mcp。策略的 Schema 契約與策略配套的 review-agent-governance.cedarschema 定義了策略引用的實體與動作上下文類型它決定了每條規(guī)則可用的context字段entity User; entity Resource; action Bash appliesTo { principal: [User], resource: [Resource], context: { command_pattern: String, target_branch?: String } }; action Write appliesTo { principal: [User], resource: [Resource], context: { path_starts_with: String } }; action Edit appliesTo { principal: [User], resource: [Resource], context: { path_starts_with: String } }; action WebFetch appliesTo { principal: [User], resource: [Resource], context: { method: String, url_host: String } };可以看到Bash動作攜帶command_pattern與可選的target_branchWrite/Edit攜帶path_starts_withWebFetch攜帶method與url_host。默認策略中的 5 條 forbid 規(guī)則正是精確消費這些上下文字段——這也是為什么審計策略時必須保證 schema 與實際使用的 context 屬性一致。一個值得警惕的語言陷阱in-on-String 會被靜默丟棄倉庫的測試 test/README.md 與 run-tests.sh 專門防護了一個 Cedar 語言陷阱對應(yīng)上游 issue #598在forbid規(guī)則里寫context.attr in [ ... ]形式Cedar 會靜默丟棄該規(guī)則導(dǎo)致門控悄悄失效。正確寫法是[ ... ].contains(context.attr)。測試腳本的 Part A只需要grep任何環(huán)境都能跑做兩件事一是斷言策略中不存在context.attr in [的 bug 形態(tài)先扁平化空白防止跨行換行繞過檢查二是斷言策略確實使用了[ ... ].contains(context.attr)的修正寫法。Part B 則僅在安裝了cedarCLI 時運行cedar validate --policies ... --schema ...利用 schema 中 context 屬性為String類型這一事實在加載期拒絕in-on-String 形式、接受.contains()形式。默認策略中大量.contains(context.command_pattern)寫法正是這一防御的直接體現(xiàn)。五、三類典型擴展把默認策略適配到你的項目review-policy-author給出了三個可直接復(fù)制的擴展模板。5.1 使用 Linear 做 issue 分診的團隊禁止代理用 CLI 操作 Linear并禁止對api.linear.app發(fā)起寫型 WebFetchforbid ( principal, action Action::Bash, resource ) when { context.command_pattern starts with linear }; forbid ( principal, action Action::WebFetch, resource ) when { context.method POST context.url_host api.linear.app };5.2 使用自研內(nèi)部 review bot 的團隊forbid ( principal, action Action::WebFetch, resource ) when { context.method in [POST, PUT, PATCH, DELETE] context.url_host in [ review-bot.internal.company.com, code-review.internal.company.com ] };5.3 允許專用 bot 賬號、禁止個人賬號當團隊希望讓運行在專屬「automation」身份下的代理執(zhí)行 review而不允許開發(fā)者個人賬號執(zhí)行時可用「精確permit 兜底forbid」的組合permit ( principal Principal::gh-bot-reviewer, action Action::Bash, resource ) when { context.command_pattern in [gh pr comment] }; forbid ( principal, action Action::Bash, resource ) unless { principal Principal::gh-bot-reviewer || context.human_approved true };注意這個forbid ... unless結(jié)構(gòu)除 bot 賬號外其余主體只有攜帶human_approved true上下文時才能通過。六、審計一份既有策略的五個檢查點當需要審查一份review-governance.cedar時review-policy-author建議按以下順序逐項核對命令覆蓋確認團隊使用的每一條審查面 CLI 命令都有對應(yīng)的forbid規(guī)則。API 覆蓋缺口檢查gh api repos這類通配規(guī)則是否在。缺少它代理可以用gh api repos/X/Y/pulls/42/reviews繞過所有基于命令模式的規(guī)則。保護分支覆蓋驗證保護分支的git push規(guī)則覆蓋了倉庫設(shè)置中實際處于保護狀態(tài)的所有分支。CI/CD 路徑匹配確認 CI/CD 路徑規(guī)則與本項目真正起門控作用的文件一致例如有些團隊用deployment/而非.github/workflows/。默認放行規(guī)則不覆蓋先前的 forbid檢查末尾的默認放行規(guī)則不會覆蓋更早的forbid。Cedar 中forbid是權(quán)威的后續(xù)的permit無法解除它。七、門控體系如何運轉(zhuǎn)從策略到鉤子到收據(jù)鏈策略本身只是一半另一半是運行時執(zhí)行機制。該插件通過兩個鉤子定義于 hooks/hooks.json包住 Claude Code 的每一次工具調(diào)用PreToolUse 鉤子門控決策if [ -f ${REVIEW_APPROVAL_FLAG:-./.review-approved} ]; then exit 0; fi; \ npx protect-mcp0.7.4 evaluate --policy ${REVIEW_GOVERNANCE_POLICY:-./review-governance.cedar} \ --tool $TOOL_NAME --input $TOOL_INPUT --fail-on-missing-policy false若存在./.review-approved審批標記文件或REVIEW_APPROVAL_FLAG指定的替代路徑直接exit 0放行否則調(diào)用protect-mcp evaluate用 Cedar 策略評估該工具調(diào)用Cedar 判定 deny 時工具調(diào)用以退出碼 2 結(jié)束Claude Code 隨即阻止它。PostToolUse 鉤子簽名取證npx protect-mcp0.7.4 sign --tool $TOOL_NAME --input $TOOL_INPUT --output $TOOL_OUTPUT \ --receipts ${REVIEW_GOVERNANCE_RECEIPTS:-./review-receipts/} \ --key ${REVIEW_GOVERNANCE_KEY:-./review-governance.key}無論該次工具調(diào)用被批準、拒絕還是跳過都會產(chǎn)生一條 Ed25519 簽名收據(jù)收據(jù)鏈精確記錄了什么動作在何時被授權(quán)。審批窗口的打開與關(guān)閉審批窗口通過兩種方式打開方式一標記文件最簡touch ./.review-approved # 讓代理執(zhí)行被批準的動作 rm ./.review-approved方式二斜杠命令Claude Code 內(nèi)/approve-review Posting the code review for #123/approve-review實現(xiàn)見 commands/approve-review.md創(chuàng)建./.review-approved并把審批理由寫入文件與./review-receipts/approvals/下的時間戳 JSON 條目。關(guān)于審批日志的重要提醒./review-receipts/approvals/*.json是明文 JSON 記錄不是簽名收據(jù)。它們不經(jīng)過protect-mcp sign因此veritasacta/verify不覆蓋它們審批日志屬于「操作者信任」——它記錄人類意圖批準什么但事后被編輯也無法被偵測。真正具備防篡改能力的是 PostToolUse 為每次動作無論放行還是拒絕生成的./review-receipts/*.json工具調(diào)用收據(jù)它們才是權(quán)威審計線索。對于受監(jiān)管環(huán)境需要簽名審批記錄的場合可改用npx protect-mcplatest sign --tool approve-review --input ...直接簽名。查看被拒動作/list-pending實現(xiàn)見 commands/list-pending.md遍歷./review-receipts/收據(jù)鏈打印最近的decision: deny條目默認最近 10 條可用--last N調(diào)整展示工具名、命令模式與時間戳并提示可配合/approve-review人工放行后重試。一個完整的「拒絕 → 批準 → 放行」會話以代理想在 PR 上發(fā)布 review 評論為例。未批準時$ agent: gh pr review 42 --comment --body LGTM → PreToolUse hook 運行 → 無 ./.review-approved 文件策略被評估 → Cedar: 對 context.command_pattern gh pr review 判 forbid → 退出碼 2Claude Code 阻止該工具調(diào)用 → PostToolUse 運行簽名一條 decisiondeny 的收據(jù)批準后$ touch ./.review-approved $ agent: gh pr review 42 --comment --body LGTM → PreToolUse hook 運行 → 檢測到 ./.review-approvedexit 0 → 工具調(diào)用執(zhí)行 → PostToolUse 簽名收據(jù)decisionallow, reasonhuman_approved $ rm ./.review-approved關(guān)于簽名鏈的一個審計預(yù)期當審批標記存在時PreToolUse 鉤子短路為exit 0不會調(diào)用protect-mcp evaluate。因此被批準動作對應(yīng)的 PostToolUse 收據(jù)會是decision: allow但沒有policy_digest字段因為沒有評估任何 Cedar 策略。審計人員遍歷收據(jù)鏈時應(yīng)預(yù)期這一現(xiàn)象被批準的工具調(diào)用顯示為帶簽名的收據(jù)、reason: human_approved、無策略引用而被拒絕的工具調(diào)用與非 review 動作它們確實經(jīng)過 Cedar則照常攜帶policy_digest。八、收據(jù)鏈的離線驗證與組合使用驗證整條鏈npx veritasacta/verify ./review-receipts/*.json退出碼語義0表示每條收據(jù)都真實且鏈完整1表示某條收據(jù)被篡改2表示收據(jù)格式損壞。任何持有公鑰的一方都能離線驗證不依賴操作者。與 protect-mcp 組合該插件聚焦審查面若要對所有 Claude Code 工具調(diào)用做通用策略強制可并排安裝 protect-mcp。兩個鉤子都會運行、都會產(chǎn)出收據(jù)可配置不同的收據(jù)目錄如./receipts/與./review-receipts/保持鏈條分離。任一策略判 deny工具調(diào)用即被阻止。九、技術(shù)選型依據(jù)為什么是 Cedar Ed25519 收據(jù)CedarAWS 的開源授權(quán)引擎以聲明式、形式化的方式表達策略審查者閱讀策略即可精確了解什么被門控?zé)o需讀代碼策略可通過cedar validate做類型檢查策略變更可 diff。Ed25519 收據(jù)RFC 8032 簽名、RFC 8785 JCS 確定性規(guī)范化、hash-chained提供不依賴操作者的防篡改證據(jù)。任何篡改都會導(dǎo)致驗證退出碼 1。涉及的完整標準棧Ed25519RFC 8032、JCSRFC 8785、CedarAWS、IETF 草案 draft-farley-acta-signed-receipts收據(jù)格式。十、參考資料與進一步閱讀策略作者代理定義plugins/review-agent-governance/agents/review-policy-author.md插件默認策略plugins/review-agent-governance/policies/review-agent-governance.cedar策略 Schemaplugins/review-agent-governance/policies/review-agent-governance.cedarschema運行時鉤子配置plugins/review-agent-governance/hooks/hooks.json插件完整說明含安裝步驟、審批窗口、示例會話plugins/review-agent-governance/README.md一次性安裝與每會話工作流plugins/review-agent-governance/skills/review-agent-setup/SKILL.md策略語言陷阱防護測試plugins/review-agent-governance/test/run-tests.sh通用策略強制插件可與本插件組合plugins/protect-mcp實際安裝時可先執(zhí)行claude plugin install wshobson/agents/review-agent-governance隨后將默認策略復(fù)制到項目根目錄./review-governance.cedar并按第四節(jié)、第五節(jié)的方法定制最后按第七節(jié)的方式投入運行。如需強制所有工具調(diào)用都走策略評估禁用審批旁路可設(shè)置REVIEW_APPROVAL_FLAG./.never-approve——這在 CI 或鎖定的審計運行中尤為有用?！久赓M下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考