胖头鱼的技术专栏-455 AI Agent安全治理：平台管得住的，和管不住的（20260805）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE
10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

最近和不少企业客户聊AI Agent落地，有个感受越来越强烈——

平台做得再好，也防不住人的"创造力"。

这个感受不是凭空来的。我自己的项目"川序"，在安全层面下了很大功夫——零信任、身份治理、审批审计、应急撤销，该做的都做了。但和客户一聊，发现现实中的问题远比平台能覆盖的要"丰富"得多。

今天就聊聊这个话题——AI Agent在企业落地，平台管控之外，还差什么。

老规矩，先打个广告： https://db4agent.cn 。

一、平台做了什么：先把"门"装好

先简单回顾一下川序在安全层面做了哪些事。不是为了自夸，而是为了让后面的讨论有个基准。

川序的安全设计，核心就一句话： 提示词不能代替权限。

具体来说：

• 零信任默认——身份、授权或凭证缺失、失效、过期时，直接失败关闭，不是"先放行再看看"；
• 服务端重决策——不管前端菜单给了什么、提示词写了什么、频道成员关系怎么设的，最终在服务端按当前身份、归属、角色、显式拒绝、安全域、用途、密级和有效期重新算一遍权限交集；
• 高风险审批——高风险访问支持N-of-M多人审批、申请人与审批人分离、限时授权、即时撤销；
• 实例隔离——同一Agent可按安全域、频道或任务隔离实例与短期凭证，缩小凭证爆炸半径；
• 审计可追溯——所有操作按风险记录身份、动作、资源、决策、摘要和证据引用，事后可复核。

打个比方：川序就像一栋写字楼的物业管理系统——门禁卡、摄像头、访客登记、电梯权限、消防通道，一应俱全。你拿着卡能进该进的楼层，进不了不该进的地方；出事了能查记录，紧急情况能一键锁电梯。

这已经比大多数"裸奔"的Agent部署强太多了。但——注意这个"但"——门装好了，不代表所有人都会走门。

而且川序自己在安全页面上也写了一句很诚实的话： 数据库控制面不能撤回已经离开的数据，也不能自动终止数据库外且未接入Gateway的进程。

这句话是什么意思？翻译成人话就是—— 平台管得住门内的，管不住门外的。

二、现实给了两记闷棍

和客户沟通中，有两个场景让我印象特别深。这两个场景，平台层面确实很难完全覆盖。

第一记：非受控Agent接入了生产

这是个很典型的场景——企业IT部门搭了Agent管理平台，流程也规范了：注册、认证、分配权限、纳入管理。但业务部门那边，有人自己拿了个开源Agent框架，直接连上了生产数据库。

为什么？因为快。走平台注册要审批、要配权限、要走流程，而自己搭一个Agent，写个连接串，十分钟就跑起来了。业务方觉得：“我不就查个数据嘛，能出什么事？”

但问题在于——这个Agent 根本不在平台的管辖范围内。它没有注册身份，没有权限边界，没有审计记录，出了事你都不知道是谁干的。更可怕的是，如果这个Agent被提示词注入了，它可能拿着生产库的连接串，干出一些始料未及的事情。

Agent在聊天框里只回了你一句话，你以为它只做了一件事，实际上背后可能执行了上百次tool calls：read_file、write_file、search_file、browser……你完全不知道。一个连平台都没注册的Agent，这种行为更是一点影子都留不下。

这就好比你给写字楼装了门禁系统，但有人发现后门没锁，天天走后门。门禁系统再先进，也管不了走后门的人。

第二记：注册后主动脱管

这个更"高级"一点——Agent确实通过正规流程注册到了平台上，身份、权限都配好了。但运行过程中，它自己（或者背后的人）想办法绕过了平台的受控接口，直接和外部服务通信。

比如，平台要求Agent通过Skill接口访问外部API，但Agent的代码里偷偷写了个直连逻辑——绕过Skill，绕过审计，直接HTTP请求出去。平台看到的是"这个Agent在正常执行任务"，实际上它已经脱管了。

还有一种情况：Agent注册后，开发者后续修改了Agent的代码或配置，加入了一些"不在台账里"的行为。平台管理的只是注册时的那个"快照"，运行时的实际行为早就偏了。

这就像员工入职时签了保密协议，工牌也发了，但入职之后偷偷把公司数据拷到U盘上带走了——HR系统的记录一切正常，但人已经"脱管"了。

三、平台之外，还差三道门

聊到这里，我的总结很明确： 企业AI Agent想要真正落地，光有平台管控不够，还得有三条腿。

第一道：传统企业管理，不能丢

这个观点可能不那么"技术"，但我觉得最重要。

上面两个场景，本质上都不是技术问题—— 是人的问题。

非受控Agent接入生产，是谁干的？是员工。注册后主动脱管，是谁授意的？也是人。平台能做的是提供管控手段，但如果有人铁了心要绕开，纯靠技术是防不住的。

所以传统的企业管理手段必须跟上：

• 制度先行——明确规定：任何接入生产环境的Agent，必须经过平台注册和审批，未注册的Agent禁止连接生产系统。这不是建议，是红线；
• 流程约束——把Agent的上线流程纳入现有的变更管理，和数据库变更、应用发布走同一套审批流，不能因为是"AI"就搞特殊；
• 违规处置——发现非受控Agent接入生产，或已注册Agent主动脱管，要有明确的处置机制。不能只是"口头警告"，得和绩效挂钩，该处罚就处罚。

说白了： 平台是技术防线，制度是管理防线。技术防线可以不断加固，但管理防线一旦松懈，技术防线就是摆设。

就像你给写字楼装了最好的门禁系统，但如果物业不巡查、保安不值守、违规人员不处理——门禁系统也就是个摆设。

第二道：安全扫描，向Agent运行态扩展

传统的安全扫描，主要扫代码漏洞、配置基线、网络边界这些。但在AI Agent的场景下，光扫这些不够了。

Agent是一个 运行时动态变化的东西——它的行为不是写死在代码里的，而是由模型、提示词、上下文、工具调用共同决定的。同一个Agent，今天的提示词被注入了，行为就可能完全不同。

所以安全管控应当向 Agent运行态扫描扩展：

几个关键点展开说一下：

• 提示词安全扫描——定期或实时检测Agent的提示词是否被注入、是否包含敏感信息泄露风险。提示词是Agent的"指令源"，指令源被污染了，后面全歪；
• 行为基线监控——为每个Agent建立正常行为基线（调哪些工具、访问哪些数据、调用频率多少），偏离基线时告警。一个平时只读数据的Agent突然开始批量删除，不用等出事就该拦下来；
• 出站通信审计——监控Agent的网络出站请求，发现绕过受控接口的直连行为，立即阻断并告警。这条直接对应上面"注册后主动脱管"的场景；
• 凭证使用审计——Agent使用的数据库连接串、API Key等凭证，定期轮换，使用记录全量审计。凭证泄露是Agent场景下最容易出事的地方之一。

这些能力，有些可以在平台层面实现（比如川序的审计和审批模块已经覆盖了一部分），有些需要和企业的安全运营体系（SOC、SIEM）打通。但方向是明确的—— 安全扫描的边界，必须从"代码和配置"扩展到"Agent运行态"。

第三道：算力管控，不可忽视的新维度

这个可能是三个方向里最"新"的，但我觉得不可回避。

AI Agent和传统应用最大的区别之一，就是 它吃算力。一个Agent跑一次推理，消耗的GPU/CPU资源可能顶得上传统应用跑一天。如果企业内部有一堆Agent在不受控地消耗算力，会带来什么问题？

• 成本失控——算力是真金白银，Agent跑飞了，云账单就飞了；
• 资源挤占——关键业务的Agent算力不够，被非关键Agent占满了资源池；
• 隐蔽滥用——有人拿公司的算力跑自己的私活，甚至"挖矿"（这个真不是段子，圈内已经有实际案例了）。

所以算力管控应该成为Agent治理的标配：

• 配额管理——按Agent、按部门、按任务类型分配算力配额，超额预警和熔断；
• 用途审计——算力消耗和具体任务关联，能追溯到"谁在用、干什么用、花了多少"；
• 优先级调度——关键任务优先分配算力，非关键任务在资源紧张时自动降级或排队。

这块目前行业里做得还比较少，但我判断会很快成为企业级Agent平台的标配能力——就像云成本管理（FinOps）一样，先是"Nice to have"，然后变成"Must have"。

总结

回到开头那个问题：AI Agent在企业落地，平台管控之外，还差什么？

我的答案是 三道门：

1. 传统企业管理——制度、流程、违规处置，人的问题不能靠技术解决；
2. 运行态安全扫描——从代码扫描扩展到Agent行为、提示词、出站通信的实时监控；
3. 算力管控——配额、审计、调度，算力是新的"成本中心"。

川序在平台层面已经做了很多——身份治理、零信任、审批审计、应急控制——但我也很清楚，平台只是起点，不是终点。而且川序自己在安全页面上就老老实实写了： 平台不能撤回已经离开的数据，也不能终止未接入Gateway的进程。 这不是推卸责任，是实事求是——技术防线有边界，认清边界才能补齐短板。

技术防线要不断加固，管理防线更不能松。用我项目的那句Slogan收个尾： Breaking the AI Agent Black Box——打破黑盒，光靠平台不够，还得靠人、靠制度、靠算力管控。

老规矩，知道写了些啥。