financial-services威胁模型分析谁能读、谁能写、谁能记账的权限图谱【免费下载链接】financial-services项目地址: https://gitcode.com/GitHub_Trending/fi/financial-servicesfinancial-services 是一个面向金融行业的开源 AI 智能体参考项目它把投资银行、股票研究、私募、财富管理等高频工作流做成了可安装的 Claude 插件与托管 Agent 模板。而真正让它值得深读的是其隐藏的威胁模型设计——一套回答谁能读、谁能写、谁能记账的权限图谱。本文将用新手也能看懂的方式拆解这套三层隔离架构是如何防止 AI 代理越权的。先搞清楚这个项目的 AI 代理能做什么、不能做什么 打开项目总览 README.md 就能看到一条醒目的红线声明这些智能体起草分析师的工作成果模型、备忘录、对账报告供合格专业人员复核。它们不做投资建议、不执行交易、不承担风险、不写入账本、不审批开户——所有产出都停留在待人类签核状态。用威胁模型的语言翻译一下这就是项目的顶层权限承诺权限类型AI 代理是否拥有说明 读Read✅ 有但分级读外部文件、只读数据连接器✍️ 写Write✅ 有但唯一每个工作流仅一个持写者且只能写./out/草稿 记账Post to ledger❌ 永无分录只暂存过账必须走人类审批一句话概括AI 可以替你把活干到 99 分但最后 1 分永远是人签的字。三层隔离架构权限图谱的核心这套设计的精髓藏在 managed-agent-cookbooks/ 目录下每个智能体都有自己的模板。以总览文档 managed-agent-cookbooks/README.md 为例所有 Agent 的叶子工作器被统一划分为三层其中加粗的那个叶子是唯一持有Write工具的层级是否接触不可信文档可用工具数据连接器reader 层如reader、doc-reader是唯一接触层仅Read、Grep无Orchestrator 层编排器否Read、Grep、Glob、Agent只读 MCP 连接器写者层如resolver、poster否Read、Write、Edit无为什么这么切 威胁模型的出发点是外部文档可能是武器。对手方发来的对账单、客户发来的邮件、GP 提供的估值包——这些都是不可信输入里面可能藏有恶意指令提示注入。三层隔离保证了一条铁律能读不可信文档的组件没有写权限和工具执行能力有写权限的组件永远不打开外部文件。逐一看10 个智能体的权限分配实战下面这张图谱汇总了全部 10 个智能体的读/写/记账权限分配来源各目录下的README.md智能体读不可信文档者只读连接器唯一写者 → 产出物gl-reconcilerreaderGL、子账只读 MCPresolver→ 例外报告month-end-closerledger-reader内部 GL只读poster→ 关账包close-package-*.xlsxstatement-auditorstatement-readerNAV 包只读flagger→ 签核表signoff-*.xlsxkyc-screenerdoc-reader筛查库只读escalator→ 升级单escalation-*.xlsxvaluation-reviewerpackage-reader组合数据只读publisher→ LP 报告包earnings-reviewertranscript-readerFactSet、Daloopa只读note-writer→ 研报草稿pitch-agent输入本身可信CapIQ、Daloopa只读deck-writer→ 路演材料meeting-prep-agentnews-readerCRM、CapIQ只读pack-writer→ 客户简报包几个值得新手注意的细节读者的输出被压缩了reader 层只能返回长度受限、经 schema 校验的 JSON由 scripts/validate.py 校验。即使文档里塞了恶意指令出了 reader 门也只剩结构化数据无法原样传播。双重复核以 gl-reconciler 为例critic会在交给写者之前独立地拿可信数据源重新验证每一条差异。写者的活动半径极小resolver写差异报告到./out/、poster生成关账包但永远不打开外部人的文件也从不写回任何业务系统。谁也不能记账人类签核是最后一道闸门记账权限在本项目中被系统性地剥夺了。每个模板 README 都有一个Not guaranteed不保证小节逐条划出 AI 的能力边界GL Reconciler没有任何东西会写入记录系统。账目调整必须在代理之外经人类审批。Month-End Closerposter产出的分录是草稿暂存staged不直接过账到总账。Statement Auditor只推荐 pass/hold分发由 IR 在人类签核后执行。KYC Screener推荐风险评级由合规官拍板。Valuation ReviewerLP 报告需要IR 和 CCO 双重签核。这就是权限图谱上记账那一列永远为空的原因——系统里根本不存在写账本的连接器。代理协作也设防白名单 载荷校验智能体之间不直接互相调用。需要协作时它在自己输出里发一个handoff_request移交请求由编排层路由给目标会话。参考实现 scripts/orchestrate.py 的头部注释直接写出了这段的威胁模型移交请求出现在编排器的文本输出中而它位于不可信文档读者的下游。控制了被处理文档的攻击者可能嵌入一个手写的 handoff_request 片段——如果被原样回显就会被解析执行。对应的两道防线硬白名单目标智能体必须在 10 个已部署的 slug 之内见 scripts/orchestrate.py写别的名字直接丢弃schema 校验载荷字段有长度上限和字符白名单正则^[A-Za-z0-9 ._/:#-]$不符合 scripts/orchestrate.py 中定义的结构就拒绝。并且官方建议生产环境优先用类型化的专用工具调用或 SSE 事件来发移交让模型无法靠复述文档文本伪造请求。如何部署这套威胁模型快速上手整套东西全是 markdown YAML没有构建步骤。部署一个模板只需三步以 GL Reconciler 为例配置环境变量ANTHROPIC_API_KEY 你的只读MCP 连接器地址如GL_MCP_URL运行部署脚本 scripts/deploy-managed-agent.shexport ANTHROPIC_API_KEYsk-ant-... export GL_MCP_URL... # 只读 GL MCP export SUBLEDGER_MCP_URL... # 只读子账 MCP scripts/deploy-managed-agent.sh gl-reconciler用 managed-agent-cookbooks/gl-reconciler/steering-examples.json 里的示例事件发起会话验证权限边界是否如预期。⚠️ 注意子代理委派callable_agents目前是 Research Preview 能力且只支持一层委派——编排器可以调用工作器工作器不能再往下调。总结一张图看懂 financial-services 的权限哲学✅能读的不能写接触外部不可信文档的 reader 层只有Read/Grep输出被压缩成受校验的 JSON ✅能写的不能碰外部文件唯一写者不接连接器、不开外部文档产出只落./out/ ✅能记账的只有人分录暂存、分发待签核、风险评级待合规官拍板 ✅协作也有门禁移交请求经硬白名单 schema 双重校验。这套读/写/记账三权分立的图谱对任何要把 AI 接入敏感业务的团队都是一份可以直接抄作业的威胁模型范本。【免费下载链接】financial-services项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 21:06:33 · 阅读 1.2k financial-services威胁模型分析：谁能读、谁能写、谁能记账的权限图谱
financial-services威胁模型分析谁能读、谁能写、谁能记账的权限图谱【免费下载链接】financial-services项目地址: https://gitcode.com/GitHub_Trending/fi/financial-servicesfinancial-services 是一个面向金融行业的开源 AI 智能体参考项目它把投资银行、股票研究、私募、财富管理等高频工作流做成了可安装的 Claude 插件与托管 Agent 模板。而真正让它值得深读的是其隐藏的威胁模型设计——一套回答谁能读、谁能写、谁能记账的权限图谱。本文将用新手也能看懂的方式拆解这套三层隔离架构是如何防止 AI 代理越权的。先搞清楚这个项目的 AI 代理能做什么、不能做什么 打开项目总览 README.md 就能看到一条醒目的红线声明这些智能体起草分析师的工作成果模型、备忘录、对账报告供合格专业人员复核。它们不做投资建议、不执行交易、不承担风险、不写入账本、不审批开户——所有产出都停留在待人类签核状态。用威胁模型的语言翻译一下这就是项目的顶层权限承诺权限类型AI 代理是否拥有说明 读Read✅ 有但分级读外部文件、只读数据连接器✍️ 写Write✅ 有但唯一每个工作流仅一个持写者且只能写./out/草稿 记账Post to ledger❌ 永无分录只暂存过账必须走人类审批一句话概括AI 可以替你把活干到 99 分但最后 1 分永远是人签的字。三层隔离架构权限图谱的核心这套设计的精髓藏在 managed-agent-cookbooks/ 目录下每个智能体都有自己的模板。以总览文档 managed-agent-cookbooks/README.md 为例所有 Agent 的叶子工作器被统一划分为三层其中加粗的那个叶子是唯一持有Write工具的层级是否接触不可信文档可用工具数据连接器reader 层如reader、doc-reader是唯一接触层仅Read、Grep无Orchestrator 层编排器否Read、Grep、Glob、Agent只读 MCP 连接器写者层如resolver、poster否Read、Write、Edit无为什么这么切 威胁模型的出发点是外部文档可能是武器。对手方发来的对账单、客户发来的邮件、GP 提供的估值包——这些都是不可信输入里面可能藏有恶意指令提示注入。三层隔离保证了一条铁律能读不可信文档的组件没有写权限和工具执行能力有写权限的组件永远不打开外部文件。逐一看10 个智能体的权限分配实战下面这张图谱汇总了全部 10 个智能体的读/写/记账权限分配来源各目录下的README.md智能体读不可信文档者只读连接器唯一写者 → 产出物gl-reconcilerreaderGL、子账只读 MCPresolver→ 例外报告month-end-closerledger-reader内部 GL只读poster→ 关账包close-package-*.xlsxstatement-auditorstatement-readerNAV 包只读flagger→ 签核表signoff-*.xlsxkyc-screenerdoc-reader筛查库只读escalator→ 升级单escalation-*.xlsxvaluation-reviewerpackage-reader组合数据只读publisher→ LP 报告包earnings-reviewertranscript-readerFactSet、Daloopa只读note-writer→ 研报草稿pitch-agent输入本身可信CapIQ、Daloopa只读deck-writer→ 路演材料meeting-prep-agentnews-readerCRM、CapIQ只读pack-writer→ 客户简报包几个值得新手注意的细节读者的输出被压缩了reader 层只能返回长度受限、经 schema 校验的 JSON由 scripts/validate.py 校验。即使文档里塞了恶意指令出了 reader 门也只剩结构化数据无法原样传播。双重复核以 gl-reconciler 为例critic会在交给写者之前独立地拿可信数据源重新验证每一条差异。写者的活动半径极小resolver写差异报告到./out/、poster生成关账包但永远不打开外部人的文件也从不写回任何业务系统。谁也不能记账人类签核是最后一道闸门记账权限在本项目中被系统性地剥夺了。每个模板 README 都有一个Not guaranteed不保证小节逐条划出 AI 的能力边界GL Reconciler没有任何东西会写入记录系统。账目调整必须在代理之外经人类审批。Month-End Closerposter产出的分录是草稿暂存staged不直接过账到总账。Statement Auditor只推荐 pass/hold分发由 IR 在人类签核后执行。KYC Screener推荐风险评级由合规官拍板。Valuation ReviewerLP 报告需要IR 和 CCO 双重签核。这就是权限图谱上记账那一列永远为空的原因——系统里根本不存在写账本的连接器。代理协作也设防白名单 载荷校验智能体之间不直接互相调用。需要协作时它在自己输出里发一个handoff_request移交请求由编排层路由给目标会话。参考实现 scripts/orchestrate.py 的头部注释直接写出了这段的威胁模型移交请求出现在编排器的文本输出中而它位于不可信文档读者的下游。控制了被处理文档的攻击者可能嵌入一个手写的 handoff_request 片段——如果被原样回显就会被解析执行。对应的两道防线硬白名单目标智能体必须在 10 个已部署的 slug 之内见 scripts/orchestrate.py写别的名字直接丢弃schema 校验载荷字段有长度上限和字符白名单正则^[A-Za-z0-9 ._/:#-]$不符合 scripts/orchestrate.py 中定义的结构就拒绝。并且官方建议生产环境优先用类型化的专用工具调用或 SSE 事件来发移交让模型无法靠复述文档文本伪造请求。如何部署这套威胁模型快速上手整套东西全是 markdown YAML没有构建步骤。部署一个模板只需三步以 GL Reconciler 为例配置环境变量ANTHROPIC_API_KEY 你的只读MCP 连接器地址如GL_MCP_URL运行部署脚本 scripts/deploy-managed-agent.shexport ANTHROPIC_API_KEYsk-ant-... export GL_MCP_URL... # 只读 GL MCP export SUBLEDGER_MCP_URL... # 只读子账 MCP scripts/deploy-managed-agent.sh gl-reconciler用 managed-agent-cookbooks/gl-reconciler/steering-examples.json 里的示例事件发起会话验证权限边界是否如预期。⚠️ 注意子代理委派callable_agents目前是 Research Preview 能力且只支持一层委派——编排器可以调用工作器工作器不能再往下调。总结一张图看懂 financial-services 的权限哲学✅能读的不能写接触外部不可信文档的 reader 层只有Read/Grep输出被压缩成受校验的 JSON ✅能写的不能碰外部文件唯一写者不接连接器、不开外部文档产出只落./out/ ✅能记账的只有人分录暂存、分发待签核、风险评级待合规官拍板 ✅协作也有门禁移交请求经硬白名单 schema 双重校验。这套读/写/记账三权分立的图谱对任何要把 AI 接入敏感业务的团队都是一份可以直接抄作业的威胁模型范本。【免费下载链接】financial-services项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考