6 月 28 日，Krishna Mohan 和 Guda Nagavenkata Srinivasa 在 arXiv 提交了一篇论文，题为 《Agent Security Meets Regulatory Reality: A Practitioner Systematization of Autonomous-Agent Threats and Controls in Regulated Financial Systems》。
https://arxiv.org/pdf/2606.29142
这篇论文讨论的不是一个新的越狱技巧，也不是一个新的 Agent 安全 benchmark，而是一个更接近生产现实的问题：当 Agent 真正进入金融 KYC 流程后，安全系统到底要证明什么。
KYC 是 Know Your Customer 的缩写，通常译为“了解你的客户”或“客户身份识别”。在金融业务中，它不是简单核验身份证，而是一整套客户身份、风险、反欺诈、反洗钱和合规审查流程。
论文讨论的场景，是用 MCP、RAG 和 A2A Agent 自动化消费信贷产品中的 KYC onboarding 流程。
这篇论文的核心判断很直接：Agent 安全进入强监管金融场景后，重点不只是“能不能防攻击”，而是每一次自动化动作能不能被解释、审计、追责和复盘。
论文把六类 Agent 威胁映射到金融监管控制义务上，又总结了一个生产 KYC 部署中的四个架构模式和三个负面结果。
这篇论文真正讨论的不是攻击，而是监管现实
很多 Agent 安全论文会从攻击面开始讲：提示注入、工具投毒、记忆污染、权限升级、多 Agent 串谋、MCP 工具滥用等。这当然重要，但它们大多停留在实验室威胁模型里。
金融业务上线 Agent 后，问题会发生变化。
在普通系统里，我们可能会问：这个 Agent 的动作是不是被授权？
但在受监管金融场景里，问题会变成：这个动作为什么发生？依据了哪个政策版本？哪个 Agent 调了哪个工具？影响了哪个客户？最后能不能从一个 case ID 还原完整决策路径？
论文作者在生产环境中遇到的关键问题，不是某个攻击者成功绕过系统，而是内部审计发现了两个更棘手的问题：一个是 RAG 检索库中的政策版本滞后，导致系统继续按照旧政策要求用户做额外验证；另一个是工具调用日志虽然存在，但无法和具体 KYC case 对上，因此无法重建某个申请人的决策链路。
这就是这篇论文的价值所在：它把 Agent 安全从“攻击分类”拉到了“受监管生产系统怎么落地”的层面。
换句话说，金融 Agent 的安全问题不是多加一个护栏就结束了，而是要把身份、权限、工具、RAG、日志、人工监督和数据边界组织成一条完整证据链。
四个生产架构
金融 KYC Agent 是怎么跑起来的
论文里的生产系统基线，是一个人工和规则混合的 KYC 流程，每天处理大约 100 个 case，中位处理时间大约 2 到 3 天。引入 Agent 后，约五分之四的 case 可以当天自动完成，其余约五分之一进入人工审核队列。
这套系统不是一个单独的大模型接口，而是由 MCP、RAG 和 A2A Agent 组合起来的生产管道。论文总结了四个架构模式。
架构一：A2A compliance choreography，用多个 Agent 串起 KYC 流程
第一个架构模式叫 A2A compliance choreography，可以理解成“多 Agent 合规编排”。
在传统 KYC 流程中，人工审核员需要在多个系统之间切换，查看身份文件、信用数据、支付或 ACH 相关策略、KYC step-up 要求，然后给出通过、转人工或拒绝的判断。问题是，不同审核员留下的记录格式不一致，有些 case 可以还原决策依据，有些 case 只能看到零散备注。
Agent 被引入后，系统增加了一个编排 Agent，由它按照固定顺序协调多个子 Agent：身份文件验证、征信数据检索、ACH 策略适用性检查、KYC step-up 判断。每个子 Agent 输出结构化结果，再由编排 Agent 汇总成 pass / refer / reject 建议和支撑理由。论文报告称，约五分之四的 case 可以当天通过自动化路径完成，剩下约五分之一进入人工审核，并在一周内完成。
这里的重点不是“用了多 Agent”，而是多 Agent 把原本分散在不同系统和人工备注里的判断过程结构化了。对于金融业务来说，结构化输出本身就是一种控制能力，因为它能为后续不利行动通知、内部审计和监管检查提供依据。
架构二：Grounded RAG for audit，让政策依据可追溯
第二个架构模式叫 Grounded RAG for audit，可以理解成“面向审计的有依据 RAG”。
普通 RAG 常被用来减少幻觉，让模型回答时参考外部文档。但在金融 KYC 场景中，RAG 不是为了让回答看起来更准确，而是为了让每一次判断都能追溯到具体政策版本。
论文中的 KYC 和 ACH 政策文档由合规团队维护，并周期性更新。如果没有受控检索机制，编排 Agent 很难知道某条政策是当前有效、已经被替代，还是不适用于当前产品。为解决这个问题，系统将政策文档放入版本化检索库，并在进入生产索引前加入人工 sign-off gate。每次检索政策时，系统会记录文档 ID、版本 hash 和检索时间戳，作为该 case 审计记录的一部分。
这个设计背后的判断很重要：金融 Agent 的 RAG 知识库不能只做“内容管理”，还要做“政策生命周期管理”。如果模型引用了旧政策，即使结果更保守，也可能构成控制失败。
架构三：Case-ID propagation，让每次工具调用都能回到具体案件
第三个架构模式是全文最值得关注的部分：Case-ID propagation through MCP tool calls。
很多 Agent 系统不是没有日志，而是日志之间没有共同主键。模型调用日志、工具调用日志、RAG 检索日志、业务系统记录都存在，但出事之后无法从一个客户 case 反向还原完整链路。
论文中的初始部署也遇到了这个问题：MCP 工具调用日志可以用于运维调试，但没有和 KYC 系统中的 case ID 绑定。审计人员从一个 adverse action case 出发，无法稳定追溯到具体调用过哪些工具、检索过哪些政策文档、做过哪些检查。论文将这个问题概括为：日志存在，但链接不存在。
后续改造方式很直接：所有 MCP 工具调用必须携带 case ID 作为强制 header，工具响应也必须带着 case ID 被记录。这样一来，case ID 就成为编排器日志、MCP 工具调用日志和不利行动记录之间的审计 join key。内部审计可以只凭一个 case ID 重建完整工具调用链。
这个设计对 Agent 安全产品很有启发。真正有价值的 Agent 日志，不是“记录了很多事件”，而是能回答一个具体问题：
给我一个客户 case，我能不能还原它为什么被通过、转人工或拒绝？
架构四：Inference-boundary redaction proxy，不让原始客户材料直接进入模型
第四个架构模式叫 Redaction proxy at the inference layer，可以理解成“模型推理边界的脱敏代理”。
金融 KYC 会处理大量敏感材料，包括身份证明、联系方式、地址证明、银行或信用相关信息。如果把原始文档直接送进模型，会同时带来两个问题：一是客户材料中的恶意文本可能形成间接提示注入；二是模型推理端点可能成为数据出境或数据驻留风险点。
论文中的做法是：原始文档不直接进入模型。系统先通过结构化抽取阶段，只提取 KYC 判断所需字段；然后字段经过 redaction proxy，移除或 token 化个人可识别信息。模型只看到脱敏后的结构化输入，token 到真实身份的映射保留在受控环境内，不传给第三方推理端点。
这个做法缩小了两个风险面：提示注入面从“任意文档正文”缩小到“有限的抽取字段”；数据驻留义务也从第三方模型端点收缩到机构可控的抽取和脱敏组件。但代价也很明确：模型看到的信息变少，一些超出预设 schema 的边缘 case 无法自动判断，只能进入人工审核。
这里可以提炼出一个很实用的原则：
不要默认把完整上下文交给模型。越是强监管场景，越要把模型推理端点看成最难约束的数据边界。
六类威胁
金融场景为什么会放大 Agent 风险
理解了生产架构，再看论文里的六类威胁，会更容易看清它们为什么不是普通安全问题。
论文讨论的六类威胁包括：提示注入、身份与授权、行为可审计性、工具滥用、数据驻留、边界策略执行。作者强调，金融监管会放大这些威胁，因为法律责任、审计义务和数据保护要求会改变威胁的优先级和缓解方式。
威胁一：提示注入不是简单越狱，而是决策依据失真
提示注入在 Agent 系统里很常见，尤其是间接提示注入。攻击者可以把恶意指令藏在外部内容里，Agent 后续读取这些内容时可能被影响。
在金融 KYC 流程中，这个风险更严重。因为系统本来就要处理大量不可信外部材料，例如用户上传的身份文件、地址证明、补充说明等。即使原始文档不直接进入模型，只要恶意内容进入了抽取字段，仍然可能影响模型判断。论文明确指出，结构化抽取和脱敏只能缩小攻击面，不能完全消除剩余风险。
在普通聊天机器人里，一次提示注入可能只是输出错误答案。但在 KYC 场景里，它可能改变用户是否被要求补充材料、是否进入人工审核，甚至是否收到拒绝或不利行动通知。问题不只是“模型被攻击”，而是金融机构给出的决策理由可能不再准确反映真实因素。
所以金融 Agent 的提示注入防御不能只停留在“拦截恶意文本”。它还必须支持事后归因：到底是哪段输入、哪个字段、哪个政策依据、哪个工具结果影响了最终判断。
威胁二：Agent 身份与授权，不能只靠服务账号解决
第二类威胁是身份与授权。
很多企业会用 service account、OAuth client 或 API key 给 Agent 配工具权限。这样做在工程上简单，但在金融合规里会变得麻烦。论文指出，生产 IAM 工具体系通常假设账号背后是人，有岗位、职责和角色边界；但 Agent 是面向任务的非人类主体，可能只需要短期、窄范围、按 case 授权的能力。结果就是，系统很容易给 Agent 配一个权限过大的生产服务账号。
在普通安全视角下，权限过大意味着被攻破后的爆炸半径更大；但在监管场景里，即使没有攻击发生，权限过大本身也可能成为审计问题。因为审计人员会问：这个 Agent 为什么有这些权限？这些权限是否和它的任务范围匹配？谁能停止它？谁对它的动作负责？
这意味着金融 Agent 需要被当作一种可管理身份，而不是脚本、接口或后台服务的附属品。它需要有身份生命周期、权限边界、任务范围、授权记录和责任归属。
威胁三：行为可审计性，不是 debug log，而是法律证据
这是论文最重要的一类威胁。
在普通软件系统中，日志主要用于调试、异常检测和事故响应。但在金融场景里，日志不是运维副产品，而是法律和监管意义上的证据。论文认为，行为可审计性是实验室威胁模型和强监管生产系统之间最尖锐的分歧点。
单模型系统里，审计相对简单：记录输入、prompt、参数和输出即可。但在 MCP / RAG / A2A 管道里，决策是分布式产生的。一个检索 Agent 取回政策文档，一个推理 Agent 综合材料，一个编排 Agent 汇总结果，一个 MCP 工具执行外部检查。最终决策不是某一次模型调用的结果，而是多个中间动作共同形成的。
论文指出，审计问题不再是“系统输出了什么”，而是“哪些检索文档、哪些中间判断、哪些工具调用，以什么方式影响了最终结果”。
所以金融 Agent 的审计设计，不能只围绕模型调用日志，而要围绕 Agent 之间的消息边界、工具调用边界和业务 case 主键来做。
这也是 case-ID propagation 为什么重要。没有贯穿全链路的 case ID，就很难把 Agent 行为变成审计证据。
威胁四：工具滥用与最小权限，不越权也可能不合规
第四类威胁是工具滥用。
Agent 一旦接入 MCP 工具层，就可以执行外部动作，例如查征信、验文件、查政策、做支付或账户相关检查。安全研究通常会把工具滥用理解成越权调用、权限升级、能力误用等问题。
论文的观点更进一步：在金融监管环境里，最小权限不是安全加固建议，而是合规运行前提。论文提到，在 KYC 管道中，编排 Agent 会调用 bureau retrieval、document verification、policy lookup、ACH checks 等 MCP 工具，初始阶段这些工具使用了较宽泛的服务账号权限，因为 IAM 模型缺少将凭证绑定到单一 Agent 任务范围的机制。
审计关注的不是“有没有真的滥用工具”，而是 Agent 是否有能力调用超出单个 KYC case 所需范围的能力。如果有，而且无法给出角色理由，那就是控制缺陷。
这给 MCP 工具生态提出了更高要求：工具不能只做 authentication 和 authorization，还要支持任务级授权、case 级约束、调用前策略检查、调用后证据记录。
威胁五：数据驻留，模型推理端点就是新的数据边界
第五类威胁是数据驻留和数据主权。
在传统规则系统中，数据处理路径相对确定。但 Agent 架构会引入新的数据出口：RAG 检索库、第三方工具 API、模型推理端点。尤其是模型推理端点，它经常由第三方服务管理，可能在不同司法辖区，并且会消费 Agent 发送给它的上下文。论文指出，在受监管环境中，数据在哪里被处理，本身就是一个受控属性。
这也是为什么论文中的架构没有把原始客户文档送给模型，而是先做结构化抽取和脱敏。这个设计本质上不是“隐私优化”，而是“数据边界控制”。
对于金融、医疗、政务等场景，未来的 Agent 网关或 AI 网关必须具备类似能力：在请求进入模型之前识别敏感数据，判断是否允许出边界，必要时做字段级脱敏、token 化或本地化推理。
威胁六：边界策略执行，传统网关看不见 Agent 内部动作
第六类威胁是边界策略执行。
传统安全架构依赖边界控制。请求穿过 API 网关、WAF、代理或零信任访问点，在那里被鉴权、检查、记录和阻断。但 Agent 架构会打散这个边界。很多关键动作不是用户直接发起的 API 请求，而是模型在推理过程中发出的工具调用。
也就是说，真正有风险的动作发生在 Agent 内部执行链里，传统边界未必看得见。
论文中的解决办法，是把 MCP tool invocation layer 重新定义为策略执行点。所有工具调用都要在这里被检查、授权，并带上 case ID 记录日志。这个工具调用层同时承担三个角色：安全控制点、人工监督界面、合规审计边界。
这对企业 Agent 安全产品很关键。未来的 Agent Gateway 不应只是模型 API 的转发层，而要成为工具调用防火墙、Agent 身份中心、任务权限控制点和审计证据生成器。
三个负面结果
生产系统真正暴露的问题
这篇论文最有参考价值的地方，是它没有只报告成功架构，也报告了三个负面结果。
这三个负面结果都不是传统意义上的黑客攻击，却更接近真实生产系统里的风险。
负面结果一：RAG 政策版本滞后，导致用户被过度验证
第一个负面结果是 RAG 政策版本滞后。
论文中的合规团队更新了 KYC 政策，取消了某些高信用分申请人的 step-up verification 要求。但新的政策版本虽然已经通过自动化合规 feed 到达系统，却还没有经过人工 sign-off gate 批准进入生产索引。在这个窗口期内，Agent 继续检索旧政策，并对本不需要额外验证的客户执行了额外 KYC。
这个问题不是 Agent 系统监控发现的，而是内部审计发现的。审计认为，Agent 正在依据已经被替代的政策行动，导致结果无法准确反映机构当前合规立场。更麻烦的是，这个问题虽然是“过度验证”而不是“验证不足”，仍然可能引发不公平、误导或滥用行为方面的监管关注。
这说明，RAG 在合规场景中不能只解决“有没有检索到文档”，还要解决“检索到的是不是当前有效版本”。
人工审核 gate 可以防止坏内容进入生产库，但无法自动解决政策更新和生产索引生效之间的窗口期。这个窗口期在普通系统里可能只是运维延迟，在金融 Agent 里可能就是合规缺口。
负面结果二：MCP 工具接口不是天然为审计设计的
第二个负面结果是 MCP 工具接口的审计能力不足。
Case-ID propagation 解决了审计链路问题，但实现过程中暴露出一个结构性缺陷：很多 MCP 工具在设计时并没有把审计要求考虑进去。它们的调用签名不携带 case ID、session context 或 provenance 信息。要让这些工具进入合规生产流程，就必须逐个改造接口，让它们接受并传播 case ID，然后重新测试、重新验证。
这意味着，金融场景里的 MCP 审计不是基础设施层面补一份日志就能解决的，而是工具接口设计约束。
如果工具一开始没有把来源、上下文、case ID、调用目的、数据范围和返回证据设计进去，后期补会非常痛。更糟糕的是，很多企业只有到集成阶段才会发现这个问题，而集成阶段往往是最不适合重构接口的时候。
所以面向强监管场景构建 MCP 工具时，不能只问：
这个工具能不能被 Agent 调用？
还要问：
这个工具被调用后，能不能证明它为什么被调用、为哪个 case 调用、使用了什么权限、返回了什么证据、影响了哪个结果？
负面结果三：约九分之一合法申请人无法被自动化流程服务
第三个负面结果最容易被忽略，但也最有现实意义。
论文中的自动化 KYC 流程假设申请人至少有两个活跃联系渠道，例如手机号和邮箱，因为该消费信贷产品实际上要求双因素认证。但约九分之一的申请人只有一个活跃渠道，常见原因是无法访问或记不起此前注册的邮箱。这些申请人即使身份真实、信用状况没有问题，也无法完成自动化 KYC 流程。
论文说，团队曾评估为单渠道申请人提供例外路径，但由于消费信贷产品的安全要求不允许单渠道 2FA，而单独建设遗失凭证恢复路径的运营成本又超过产品经济性，最终放弃。结果就是，约九分之一合法申请人没有自动化通过路径。
这不是单纯的 Agent 架构 bug，而是自动化系统的设计前提排除了部分用户。
这点很重要。我们讨论 AI 安全时，很容易关注“模型会不会犯错”“Agent 会不会越权”，但生产系统里的风险还包括：自动化流程是否默认了某些用户必须具备的技术条件？如果用户无法满足这些条件，系统是否提供合理替代路径？如果没有，这算不算一种新的系统性排除？
论文认为，现有安全研究和监管指南都还没有很好回答这个问题。实验室评测通常不会建模“无法满足认证前置条件的人群”，但真实金融业务必须面对这类人。
启发
这篇论文的结论可以压缩成一句话：
金融 Agent 安全的核心，不是只拦截风险输出，而是让每一次动作都能形成证据链。
这对 Agent 安全产品、AI 网关、内容安全护栏、MCP 工具治理和企业 AI 审计平台都有直接启发。
第一，Agent 审计主键要前置设计。
每个任务都需要 case_id / task_id，贯穿用户输入、RAG 检索、工具调用、模型推理、人工审核和最终业务动作。没有主键，日志越多越像碎片。
第二，工具调用层要成为新的安全控制面。
MCP 工具层不能只负责连接外部 API，还要承担鉴权、策略执行、敏感动作拦截、case 绑定、证据记录和权限收敛。
第三，RAG 文档要进入版本治理。
合规场景里的 RAG，不只是知识检索，而是政策依据管理。每次检索都要记录文档 ID、版本 hash、批准状态和时间戳。
第四，模型推理边界要做数据最小化。
原始文档不应默认进入模型。结构化抽取、字段级脱敏、PII token 化、本地映射表和边界控制，会成为金融、医疗、政务 Agent 的基础能力。
第五，安全护栏要输出证据，而不只是判定。
“拦截/放行”对普通内容安全场景可能够用，但对金融 Agent 不够。系统还要说明依据什么策略、哪个版本、哪个字段、哪个工具结果做出了这个判断。
写在最后
过去的大模型安全，很多时候围绕输入和输出展开：用户问了什么，模型答了什么，是否违规，是否需要拒答。
但 Agent 上线之后，风险对象发生了变化。模型不再只是回答问题，而是会检索政策、调用工具、编排流程、更新状态、影响用户权益。尤其在金融 KYC 这样的强监管场景里，安全护栏不能只盯着文本内容，还必须覆盖行为链路。
这也是这篇论文最值得关注的地方。它没有提出一个炫目的新攻击，但指出了一个更接近企业落地的事实：
Agent 安全真正难的地方，不是知道有哪些威胁，而是把审计性、最小权限和边界策略执行做成生产系统的一部分。
对于金融机构来说，这意味着 Agent 不是简单接入模型 API，也不是把规则流程外包给大模型。它需要重新设计身份体系、权限体系、工具接口、RAG 生命周期、日志主键、人工监督和数据边界。
对于安全厂商来说，这也意味着 Agent 安全产品不能只停留在 prompt 风险检测。未来真正有价值的能力，是围绕 Agent 行为生成可验证、可追溯、可复盘的证据链。
换句话说，金融 Agent 上线之后，安全系统要回答的不只是：
“这个 Agent 有没有被攻击？”
更要回答：
“这个 Agent 为什么做了这个决定？它依据的政策是否有效？它调用的工具是否授权？它处理的数据是否越界？如果用户或监管来追问，我们能不能从一个 case ID 还原完整过程？”
这才是金融 Agent 进入生产系统之后，真正被放大的安全问题。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
