financial-services威胁模型分析：谁能读、谁能写、谁能记账的权限图谱
【免费下载链接】financial-services项目地址: https://gitcode.com/GitHub_Trending/fi/financial-services
financial-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-reconciler | reader | GL、子账（只读 MCP） | resolver→ 例外报告 |
| month-end-closer | ledger-reader | 内部 GL（只读） | poster→ 关账包close-package-*.xlsx |
| statement-auditor | statement-reader | NAV 包（只读） | flagger→ 签核表signoff-*.xlsx |
| kyc-screener | doc-reader | 筛查库（只读） | escalator→ 升级单escalation-*.xlsx |
| valuation-reviewer | package-reader | 组合数据（只读） | publisher→ LP 报告包 |
| earnings-reviewer | transcript-reader | FactSet、Daloopa（只读） | note-writer→ 研报草稿 |
| pitch-agent | （输入本身可信） | CapIQ、Daloopa（只读） | deck-writer→ 路演材料 |
| meeting-prep-agent | news-reader | CRM、CapIQ（只读） | pack-writer→ 客户简报包 |
几个值得新手注意的细节：
- 读者的输出被"压缩"了：reader 层只能返回长度受限、经 schema 校验的 JSON，由 scripts/validate.py 校验。即使文档里塞了恶意指令，出了 reader 门也只剩结构化数据，无法"原样传播"。
- 双重复核：以 gl-reconciler 为例，
critic会在交给写者之前，独立地拿可信数据源重新验证每一条差异。 - 写者的活动半径极小：
resolver写差异报告到./out/、poster生成关账包，但永远不打开外部人的文件，也从不写回任何业务系统。
谁也不能记账：人类签核是最后一道闸门
"记账"权限在本项目中被系统性地剥夺了。每个模板 README 都有一个Not guaranteed（不保证）小节，逐条划出 AI 的能力边界：
- 📒GL Reconciler："没有任何东西会写入记录系统。账目调整必须在代理之外经人类审批。"
- 📒Month-End Closer：
poster产出的分录是草稿暂存（staged），不直接过账到总账。 - 📒Statement Auditor：只推荐 pass/hold，分发由 IR 在人类签核后执行。
- 📒KYC Screener：推荐风险评级，由合规官拍板。
- 📒Valuation Reviewer：LP 报告需要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.sh：
export ANTHROPIC_API_KEY=sk-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），仅供参考
