金融AI Agent安全落地：PolarDB与VM沙箱隔离架构实践

做一个金融行业的AI Agent项目，业务方催得再急，也不如安全合规那一关来得硬核。我们团队从去年底开始推进AI Agent在内部场景的落地，先后试过不少方案，最后稳定跑在生产环境里的，是一套以PolarDB为数据底座、以VM沙箱隔离为核心边界、贯穿“数据不出域”原则的部署架构。这套组合被我们内部称为Agent Express模式，写这篇文章就是想把整个设计思路、选型理由、落地过程以及踩过的坑都摊开来讲，给正在被同样问题卡住的朋友一个参考。

先介绍下背景。我们面对的场景是金融企业内部的智能数据分析助手——让Agent能够根据业务人员的自然语言提问，自动生成SQL去查询PolarDB中的业务数据，再做汇总、生成报表、输出结论。听起来不复杂，但金融行业有两条红线：第一，业务数据绝对不能出域，尤其是客户维度数据；第二，Agent的行为必须可审计、可追溯、可干预。这两条红线叠加在一起，直接把很多“先跑起来再补安全”的敏捷玩法否掉了。如果你所在的团队也正在评估AI Agent在合规敏感场景下的部署方式，这篇文章里讲的隔离设计思路、数据链路管控方法、权限与审计落地方案，应该能帮你省掉不少试错成本。

1. 金融场景下AI Agent的真实挑战

1.1 为什么Agent在金融行业推进这么难

先说一个最直接的感受：传统软件的需求是确定的，逻辑是写死的，上线之前就能把行为边界穷举清楚。但AI Agent不一样，它是模型驱动、目标导向的，你给它一个“帮我分析一下上个月各分公司的业绩波动原因”，它自己会规划步骤、选择工具、编写查询、甚至自我纠错重试。每一步动作都是动态推理出来的，不是预先写好的代码路径。

这个特性放在互联网行业无所谓，顶多就是效果不稳定。但在金融行业，直接撞上审计要求——合规部门要的是“确定性”：这个系统能做什么、不能做什么、什么情况下会做什么，必须能提前说清楚。一个推理出来的动作序列，怎么提前穷举？这成了推进AI Agent落地的第一道坎。

第二道坎更实际：Agent要干活，就得有数据访问权限；但数据不出域，又是硬性要求。如果把Agent放在一个能自由出入内外网的服务器上，它一边访问PolarDB里的业务数据，一边还能调用公网API、访问外部知识库、上传文件到外部服务，那风险就完全失控了。我们内部安全团队当时的一句话我印象很深：“我们不怕模型笨，就怕模型太聪明，聪明到会自己找路。”这句话基本概括了AI Agent在金融体系里最核心的矛盾：能力越强，越要把它的活动半径控制住。

1.2 合规要求倒逼架构升级

传统做法里，系统隔离靠网络分区、防火墙规则、数据库权限、堡垒机审计，这些手段对人和固定程序是有效的。但Agent是一个“自主决策者”，它会在边界内自己变换路径，甚至可能因为提示词注入被诱导去做偏离本意的事。所以必须把隔离理念从“网络层面隔离”升级为“行为层面隔离”。

这也是我们为什么会最终走上“VM沙箱隔离+数据不出域”路线的原因。核心理念可以总结成几句话：让Agent活在虚拟机里，虚拟机之外的世界它默认看不见；让数据只走内网链路，Agent再聪明也接触不到公网；让每一次数据库操作都过一道权限与审计闸门，任何异常行为在发生的瞬间就被记录和拦截。

这套架构不是某个单一产品能搞定的，需要数据库、沙箱、网络、模型服务、Agent框架、审计系统多方配合。下面我从架构设计的角度，把整条链路拆开讲。

2. 沙箱隔离与数据不出域的架构设计

2.1 为什么选VM而不是容器

现在很多AI Agent的demo都是跑在Docker容器里的，容器轻、启动快、资源利用率高。但金融生产环境里，我们对隔离强度的要求远高于部署便利性。

容器共享宿主机内核，虽然Docker提供了namespace和cgroup做隔离，但历史上出现过不少容器逃逸漏洞。安全团队一听“逃逸”两个字直接皱眉，因为一旦从容器逃逸出来，就是宿主机权限，那等于整个数据面暴露了。而VM（虚拟机）自带独立内核，虚拟化层（Hypervisor）把Guest OS和宿主机隔得干干净净，攻击面要小得多。即便有人从Agent应用层打穿了操作系统，也还要再突破一层Hypervisor才能碰到宿主机和其他虚拟机——这在金融合规语境下是一个决定性的安全感差异。

还有一个审计算法上的优势：VM有明确的边界，一台沙箱VM就是一个独立的审计单元，所有进出流量、进程行为、文件变更以VM为粒度做日志记录，逻辑非常清晰。容器如果要做到同样粒度，需要额外引入复杂的标签和追踪机制，审计链路拉得很长。

当然，VM的代价是资源开销和启动速度。但这个问题可以通过镜像预置和模板化启动来缓解，我们后续落地时用的是预置好依赖的Agent Express黄金镜像，冷启动也就一分钟左右，对内部场景完全能接受。

2.2 沙箱内部的分层隔离设计

VM解决了“外部打不进来”的问题，但“里面不乱跑”同样重要。我们参照零信任的思路，在沙箱内部又做了四层控制。

第一层是网络隔离。每个沙箱VM只分配内网IP，默认路由不指向公网网关。Agent进程所在的网络命名空间里，除了与PolarDB内网域名、内部模型网关、内部知识库之间的通信，其他所有目的地一律不通。也就是把“出域”定义成非法行为，从路由层面直接宣告死亡。

第二层是文件系统隔离。Agent运行在专门划分的只读系统盘上，代码和依赖全部打包进镜像。如果Agent需要临时写文件，只能写入挂载的临时卷，这个卷同时被配置成不落盘或加密落盘。这样就算Agent被诱导去读取或篡改本地配置，它也碰不到系统关键文件。

第三层是工具执行权限隔离。Agent不是直接调用操作系统命令，而是通过工具集来操作。我们在沙箱里只预置了白名单工具——查PolarDB、调模型接口、做简单的数据加工、生成报表。任何不在白名单里的命令，即便Agent生成了对应的执行意图，也会被沙箱的执行代理拒绝并记录日志。

第四层是资源配额隔离。给每个沙箱VM分配CPU、内存、磁盘IO的硬上限，防止Agent写了个死循环SQL或者出现异常递归调用时，把整个宿主机资源耗尽。这在并发了多个Agent实例的生产环境里非常重要，我们后面还专门优化过这一块。

2.3 数据不出域的技术闭环

“数据不出域”不是靠一句口号实现的，它必须是一个技术闭环。我们的理解是：数据在整个生命周期里，从数据库，到模型推理的输入输出，再到Agent生成的中间结果，最后到用户端展示，都不能穿越到不受信的域外环境。

具体落地有五个关键控制点。

第一，数据库访问必须走内网。PolarDB实例放在独立的VPC里，沙箱VM与数据库之间通过VPC内网互通，白名单只放行沙箱网段，从源头保证除了沙箱里的Agent谁都不能直连数据库。

第二，模型推理不依赖外部API。Agent调用的底层大模型必须部署在内部推理网关后面，不能说因为业务方想用某个公网模型服务，就让数据往外送。金融场景里，这个原则没有妥协空间。我们自建的推理网关基于开源模型做了私有化部署，虽然初期成本高一些，但换来的是数据不出域这条底线从未被触碰。

第三，外部知识获取默认拒绝。Agent如果需要知识库增强，只能使用预热后的内部知识库快照，不能实时去爬外部网页或调外部搜索API。这一点平时看起来保守，但实际能避开很多提示词注入和数据泄露的坑。

第四，所有Agent出域请求都要经过出域控制面审核。什么叫出域控制面？就是在沙箱外层单独布一个网络代理，Agent发出的所有非内网请求会被代理接管，按“域名/IP/端口”三级白名单匹配；匹配不了的直接丢弃，同时触发安全告警。我们一开始以为Agent不会主动往外连，结果部署后第一天就有尝试连代码托管平台的动作，被控制面拦了个正着。

第五，输出面也要管住。Agent生成的报表、文字、图表，只能通过统一的应用网关返回给终端用户，不能自己找通道外发。应用网关上再有内容过滤、敏感词校验、脱敏检查，相当于给输出再做一道合规体检。

这一整套组合下来，结论很清晰：Agent不是不能跑，而是必须在划定好的笼子里跑。笼子本身就应该是系统架构的一部分，而不是事后再用安全设备去“围堵”。

3. PolarDB Agent Express落地方案

3.1 它解决了什么问题

整个方案里，把“Agent要查询的数据”和“Agent自身运行时”串起来的那根线，是PolarDB。我们选PolarDB，不是随手拍的，而是基于几个很现实的需求。

首先是兼容性。团队里很多人本来就会MySQL语法，PolarDB对MySQL高度兼容，Agent生成的SQL基本不需要做方言适配，迁移和学习成本都很低。

其次是高可用和弹性。金融业务对数据库的可用性要求非常高，PolarDB自带多副本同步、自动故障切换能力，不用我们自己在应用层再折腾一套主从方案。另外Agent场景有一个特点：白天业务人员集中提问，数据库负载呈脉冲式上升，PolarDB的弹性扩展能力正好匹配这种节奏。

再次是安全与审计能力。PolarDB支持细粒度的权限控制、SSL加密传输、SQL审计和慢查询分析。Agent在数据库里干了什么，全部在审计日志里，这对满足“行为可审计”的要求是刚需。

再说Agent Express。它不是什么神秘的黑科技，我更愿意把它理解为一种“面向AI Agent场景的数据库交付形态”——把Agent连接数据库所需要的预配置能力打包好：只读账号模板、权限最小化配置、连接池参数、SQL执行超时设置、一键开启审计，这些原本要DBA手动配置半天的东西，用Agent Express模板能几分钟就拉起来。它让“给Agent开一个库”这个动作，从高风险手工操作变成了可重复的标准化流程。

3.2 数据链路与权限管控的细节

这里放一段我们实际在用的权限配置思路，可以给读者当一个模板参考。

第一步：创建Agent专用账号。不要用DBA账号给Agent连库，一台沙箱VM对应一个独立账号，账号命名带沙箱标识，方便后续审计定位。

-- 创建Agent沙箱专用只读账号 CREATE USER 'agent_sandbox_001'@'%' IDENTIFIED BY '[强密码]'; -- 只授予业务库的只读权限 GRANT SELECT ON biz_db.* TO 'agent_sandbox_001'@'%'; -- 禁止查看元数据库 REVOKE ALL ON information_schema.* FROM 'agent_sandbox_001'@'%'; REVOKE ALL ON mysql.* FROM 'agent_sandbox_001'@'%'; -- 设置单次查询最大返回行数限制 ALTER USER 'agent_sandbox_001'@'%' WITH MAX_QUERIES_PER_HOUR 1200;

第二步：权限最小化约束。Agent很多时候会“好奇”地去查一些表结构。如果给了information_schema的查询权限，它就能扫描整个库的元数据，这等于把数据库的地图全暴露给了一个可能被诱导的自主体。所以我们把Agent的数据库权限压到几乎只剩SELECT，而且只允许访问业务库中明确授权的表范围。

第三步：敏感字段脱敏。对客户手机号、身份证号这类敏感字段，在数据库视图层做脱敏，Agent查到的直接就是“138****1234”这种格式。这一点特别重要，因为Agent会把这些数据放进推理上下文，如果库里是明文，那模型服务等于变相成了数据的第二存储点，审计口径会变得非常复杂。

第四步：连接池与超时控制。Agent和PolarDB之间用专用的连接池，限制最大连接数，防止某个Agent失控查询时把数据库连接耗尽。同时给SQL执行设置硬超时，比如单条查询超过30秒直接终止，并记录到慢查询日志。

3.3 沙箱与数据库之间的链路安全

沙箱VM和PolarDB之间的链路也不能裸奔。我们用了几道保险：链路层开启SSL/TLS加密，防止数据在VPC内部被旁路监听；数据库白名单只放行沙箱网段，其他来源一律拒绝；数据库侧再配合审计日志记录每条SQL的来源IP、用户、执行时间和内容，和沙箱VM侧的Agent行为日志相互印证。

这里要说一句经验：两边日志必须有共同关联键。我们最初沙箱侧日志和数据库审计日志各记各的，出了状况很难对上号。后来统一采用“沙箱ID + Agent运行实例ID + 会话ID”作为关联维度，两边日志都打上这个组合标，排查问题的时候效率提高了几倍。

4. 从验证到生产：落地实操复盘

4.1 如何快速拉起一套安全环境

很多团队做类似项目，卡在第一步“我想试试但不知道怎么开始”。这里分享一套我们总结出来的最小化落地路径，从零到出第一个结果大约需要半天。

第一步：准备好PolarDB实例，创建业务库和测试数据，创建低权限Agent专用账号。

第二步：建一个标准化的沙箱VM黄金镜像。镜像里装好Python运行时、Agent框架（比如LangGraph或自研的简单编排器）、PolarDB连接驱动、内部模型网关SDK、运行监控Agent。这一步是一次性投入，之后每开一个新沙箱，从这个镜像复制即可。

第三步：配置沙箱网络。按上文说的，把默认路由指向内网，只放行PolarDB内网地址、模型网关地址、内部知识库地址到白名单，其余出网请求全部交由出域控制面处理。

第四步：配置工具集白名单。给Agent暴露的工具就几个：query_db（查询PolarDB）、call_model（调用内部模型）、generate_report（生成报表）。工具的参数也做强约束，比如query_db最多返回500行，call_model的输入长度有上限。

第五步：跑通一个最简用例。让Agent回答“上个月销售额最高的五个城市分别是什么，同比变化如何”，看它能否自动生成SQL、查库、整理结果。这个用例跑通，整个技术闭环就算打通了。

我把这套操作整理成了一份内部用的Checklist，内容比上面更细，但核心就是这五步。团队照着走，基本没有空转。

4.2 沙箱配置的实操要点

沙箱这层配置是最容易“看起来安全、实际有洞”的地方。举几个我们实践过的关键点。

第一，务必关闭沙箱VM的SSH公网访问。Agent本身跑在沙箱里，如果运维习惯性开着公网SSH，等于给攻击者留了一扇门。我们要求所有沙箱VM仅允许通过堡垒机、从内网跳板机登录，公网SSH端口在全网段封禁。

第二，注意临时文件的处置。Agent在执行数据分析任务时，经常会写中间结果到本地。如果这个本地目录恰好是共享存储，其他沙箱也挂载了，就会形成沙箱间的数据串扰。我们后来规定每个沙箱的临时目录默认不共享，任务结束后由审计模块统一清理。

第三，要对Agent的递归调用行为做限制。有的Agent框架支持子Agent或者多步递归优化，这个特性在沙箱里很容易演化成资源黑洞——一个Agent派生十个子Agent，十个子Agent每个再去查一轮数据库。我们在沙箱配置层面直接限制最大并发子任务数，超过将被拒绝。

下面是一个简化版的沙箱资源配置示意，实际生产环境里参数值会随着业务量调整，但结构基本一致：

sandbox: name: agent-sbx-001 cpu_limit: 4 mem_limit: 8Gi disk: root: read-only tmp: 20Gi, encrypted network: default_route: reject allow_domains: - polaradb-internal.example.com - model-gateway.internal.example.com - knox.internal.example.com tool_whitelist: - query_db - call_model - generate_report max_concurrent_subtasks: 2 audit: enable: true log_destination: kafka-audit.internal

4.3 从POC到生产环境要补的课

POC阶段跑通，不等于可以直接上线。我们在从POC到生产的过渡中，补了三门课。

第一门课是压测与配额规范化。POC阶段我们只给了一个沙箱实例，生产上要同时支撑几十个业务账号并发提问。这里做了两件事：一是给每个Agent实例单独配额，防止个别极端任务消耗掉公共资源；二是做了数据库连接数和水位的压测，搞清楚PolarDB在Agent高频查询模式下的真实承载能力，再按业务量规划沙箱实例数量。

第二门课是异常行为基线化。Agent的正常行为和异常行为，需要一个基线来界定。我们跑了一周影子模式——Agent照常执行，但结果只落在测试库，不进入真实生产数据。把Agent在这期间产生的行为数据收集起来，分析出正常行为分布，再依据这个分布配置告警阈值。比如正常Agent每天查库次数在某个范围，如果某天某个实例超过标准差的数倍，就自动触发复核。

第三门课是应急预案。安全团队问了一个问题：如果发现Agent正在试图向外部投递数据，你怎么在最短时间内终止一切行为？我们设计了三级应急开关：一级是沙箱网络断网，一键切断该沙箱所有对外连接；二级是Agent进程冻结，让运行中的任务直接挂起；三级是数据库侧即时吊销该Agent账号权限。三级联动可以在30秒内把风险面压到最小。

5. 上线后踩过的坑与排查实录

5.1 出域告警排查的真实案例

第一个坑出现在上线初期。安全平台报了一条出域告警：某个沙箱VM里的Agent进程尝试连接一个外部Git仓库域名。我们的第一反应是“Agent被攻破了”，但排查下来发现真相很朴素——Agent框架在初始化时默认会检查GitHub上的插件更新清单，这和业务本身无关。

这个案例很有代表性：框架默认行为和安全策略的冲突，往往比恶意攻击更常见。解决办法是把Agent框架的自动更新、遥测上报、甚至版本检查相关功能全部显式关闭，并在镜像构建时统一写死配置。不要指望框架的默认配置能满足金融级合规要求，必须自己过一遍黑名单。

5.2 数据库连接池被“Agent风暴”打满

第二个坑更隐蔽。有一天上午PolarDB的活跃连接数突然飙到上限，业务侧查询直接超时。查了审计日志发现，源自某个新增Agent实例的并发查询特别高，而且每一条查询的执行计划都很差——原来这个Agent在处理一个多维度筛选问题时，选择了一条全表扫描的SQL方案，还拆成了几十个子查询并发执行。

这个问题的根源在于：模型生成的SQL不会自动走索引，也不能保证执行效率。我们的解决办法有几层：在工具层给Agent配置了SQL预检器，生成后的SQL先经过执行计划分析，凡是预估扫描行数超过阈值的一律拒绝并提示改写；再叠加单实例并发控制，让一个Agent最多同时运行三个数据库查询，超出部分排队等待。经过这两层优化，类似问题基本没有再出现过。

5.3 Agent幻觉引发的数据访问误判

还有一个任何做Agent落地的人都躲不过去的问题：大模型幻觉导致Agent查询了不存在的表。Agent在生成SQL时，偶尔会“创造”出一些听起来合理的表名或字段名。PolarDB会直接报错，但Agent收到报错后会尝试反复重试——有几次甚至把不同的报错SQL换着花样来回查，浪费了不少资源。

我们后来在Agent的数据库工具里加了一层“元数据提示”：在做查询之前，先把数据库的真实表结构和字段列表注入到提示上下文里，让模型基于真实元数据生成SQL，而不是凭“想象”去猜测。这个改动同时提升了SQL正确率，减少了报错重试，属于性价比极高的优化项。

5.4 常见问题速查表

我把上线以来遇到的典型问题整理成了一张表，后续排查时可以按图索骥。

5.5 生产环境维护的几条心得

最后一个部分，说几条维护层面的体会。这套架构上线运行了小半年，稳定性基本在可接受范围内，但维护工作量和传统系统完全不同——你不仅要维护“系统本身”，还要维护“系统的行为预期”。

第一，Agent相关配置变更必须走版本管理。环境变量、工具权限、模型参数，每一项改动都可能导致Agent行为出现意料外的变化。我们把所有配置纳入了Git管理，每次变更都有评审记录，出问题可以快速回滚。

第二，日志水位要留足余量。Agent比传统程序话多得多，每执行一个工具、每调用一次模型、每做一次重试，都是日志。如果日志系统磁盘规划不足，三天就能爆盘，而审计数据恰恰是不能丢的。我们目前的做法是日志七日热存加长期归档冷存，双份备份确保合规追溯随时可用。

第三，沙箱镜像要定期重建，不要“一台跑一年”。长期运行的沙箱VM会有累积性的环境漂移，软件包升级、临时文件残留、配置被误改，这些都是风险。我们现在每个月都会基于最新黄金镜像重建业务沙箱，把“漂移”消灭在摇篮里。

另外要特别提醒一件事：Agent的合规审查不能只看技术和系统，模型本身的输出同样要纳入管理。我们内部对Agent生成内容做了抽样质检，每周抽一定比例的任务，由业务专家复核结果是否准确、是否有越权表述、是否符合业务规范。这项“人工陪跑”机制看似老派，但在金融场景下恰恰是不可或缺的最后防线。

说句实在话，做这个项目最大的收获不是跑通了技术方案，而是让业务、研发、安全和合规几方找到了一个协作模式：业务提需求，研发建能力，安全划边界，合规做验收。AI Agent这件事在金融行业能走多远，最终不取决于模型参数有多强，而取决于你给它的笼子搭得有多专业、多可靠。我们这套VM沙箱隔离+数据不出域的方案，就是在这个思路下长出来的。希望这篇文章能给同在路上的人一点参考。