胖头鱼的技术专栏-458 AI Agent 的安全边界不能是提示词（20260811）

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

本期继续“川序”的介绍： https://db4agent.cn

这两天在群里又看到有人聊 Agent 安全——“我们在提示词里写了约束，不让它碰敏感数据，应该够了吧？”

每次听到这种话，我都忍不住想唠两句。提示词约束、系统指令、API 规范、前端按钮——这些东西有没有用？有用。它们能帮模型理解意图，也能改善使用体验。

但它们不应当成为企业数据的最终安全边界。说穿了：提示词可能被误解、被遗忘、被注入；API 请求可以被伪造；前端隐藏按钮挡不住直接调接口；频道成员关系也不能自动扩大数据库授权。（这里说明一下，频道是“川序”中的基于 协作组的可视化聊天窗口功能，可以看做人与 Agent 的群聊，让 Agent 的协作运行不仅被记录在数据库中，也能被看见）

真正的边界，必须在 Agent 自己改不了的地方执行。

一、零信任：每次都重新盘问

零信任不是给 Agent 贴一个“可”标签然后就一路放行。

它是对每一次访问都重新盘问：当前主体是谁？访问什么资源？属于哪个组织、哪个安全域？请求用途是什么？数据分类是什么？授权还有没有效？有没有显式拒绝？

打个比方——银行金库不是进门刷一次卡就全开放的。进大门一道验证，进金库区一道验证，开具体保险柜还有一道验证。每道门都独立核验，前一道过了不代表后面免检。

就算 Agent 已经在频道里了，就算上一轮对话通过了检查，也不代表它下一轮就能去读另一类数据。协作可见性和数据可访问性是两套判断——必须同时成立。

二、一次请求的零信任校验

一个业务请求进来，可以拆成几个连续判断。

先验访问凭证是不是当前 Agent 的；再确定请求对应的资源和动作；然后读组织、安全域、数据分类、有效期和是否存在显式拒绝；最后检查这个 Agent 有没有权限用对应的 Skill、Tool、模型或外部适配器。任何一项不满足，就在服务端 fail-close。

这个顺序很关键。不能先拿向量相似度召回全库内容，最后才想起过滤——那等于先把金库门打开再问“这人能不能进”。也不能先让模型把工具参数全生成好了，再把安全检查当个“附加提示”。

所有的操作，都得在真正执行之前过完授权判断。

三、数据库怎么执行这个边界

数据库天生适合保存身份、角色、资源分类、组织关系、授权有效期和审计证据。

“川序”的原则是：Skill、Tool、模型、频道和前端只负责“表达请求”，不直接授予权限。每次数据披露、外部能力调用、副作用和结果提交，都要重新校验当前授权交集。当 Business Agent 引人任何权限校验失败时，是禁止要求使用 Admin 权限或数据库的 Schema Owner 凭证，这种被称为“降级”的方式在很多传统系统中是作为应急手段的，但在 AI 面前这可能会带来一场灾难。

说白了——平台不能靠“把按钮灰掉”来实现“禁止访问”，也不能让模型自己决定“我应该读什么”。模型负责推理，服务端负责分发，数据库负责边界，各司其职。

数据库层面可以用的手段包括：独立数据库用户、角色、服务端接口、行级策略、工作区或安全域过滤、事务内权限检查。应用层的授权判断不能替代数据库层的最终拒绝；数据库层也不能假设应用传来的 Agent ID 一定可信——主体映射必须来自已验证的会话或凭证。

审计记录至少要包含：主体、资源、动作、结果、原因、请求关联 ID、策略版本、时间。对于外部 API 或生产操作，还得记目标、参数摘要、批准依据和回调结果。

这样出争议的时候，你能回答“谁在什么授权下执行了什么”——而不是只有模型的一段自然语言。

这张表的重点不是否定 Prompt 或 API——它们有它们的位置。安全需要最底层有强制边界，也需要上层用提示、协议和体验来减少误用。但别把上层的“减少误用”当成底层的“强制执行”。

四、如何验证安全

安全测试不能只测正常用户。

得分别用普通用户、无权限 Agent、过期凭证、被撤销凭证、跨组织 Agent 和频道成员去访问；还要绕过前端，直接调 HTTP、MCP 或 Skill 接口。测试结果应该证明：看不到的数据不会被检索；不能执行的动作不会被提交；凭证撤销后后续请求立即受影响；异常拒绝会留下审计证据。

还可以加一组“恶意”测试：在消息里要求 Agent 忽略权限（提示词注入），在参数里替换 Agent ID（伪造主体），在频道里塞未授权主体——看服务端是不是还以认证会话和数据库事实为准。

测试不能只看页面有没有报错——还得翻数据库，确认没有产生越权读取、工具调用或副作用记录。

此前在 《Agent 上线之后，谁来负责它》里聊过生命周期管理，安全边界其实就嵌在那条生命周期的每一个环节里。而 Agent 的身份本身——是谁、能做什么——则是边界判断的前提（这个话题将在后面的文章里里展开）。

五、上线前的控制清单

上线前可以逐项确认：人和 Agent 是否有独立身份；数据库是否拒绝默认回退凭证；Skill、MCP、HTTP 和页面是否走同一套授权服务；敏感配置是否加密；撤销是否在后续请求生效；外部回调是否验证来源；审计是否带请求关联 ID；应急操作是否要求理由和留痕。

这份清单不能替代渗透测试或第三方安全审计。但它能帮客户发现最常见的工程缺口。

安全不是一个模块上线后才补的功能，而是身份、数据、执行和运维在整个生命周期里的共同约束。

六、安全也有边界

零信任不是万 能的。

它不能自动撤回 Agent 已经导出的数据，也不能直接终止数据库外部正在跑的任意进程。所以企业还需要受控凭证、外部系统回调校验、运行时隔离、日志留存和处置流程来配合。同时企业也需要做好 AI 时代的企业管理，加强对人的管控。

总结

安全不是一条提示词，而是一组可验证的控制链。身份、授权、执行和证据同时存在，Agent 才能在企业环境里被信任地使用。对客户来说，零信任的价值不是让系统“看起来更安全”，而是把数据访问和副作用控制变成可以执行、测试、审计和复核的工程事实。

老规矩，知道写了些啥。