数据库管理458期 2026-08-11胖头鱼的技术专栏-458 AI Agent 的安全边界不能是提示词20260811一、零信任每次都重新盘问二、一次请求的零信任校验三、数据库怎么执行这个边界四、如何验证安全五、上线前的控制清单六、安全也有边界总结胖头鱼的技术专栏-458 AI Agent 的安全边界不能是提示词20260811作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: Database PostgreSQL ACE 10年数据库行业经验 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVPITPUB认证专家 圈内拥有“总监”称号非著名社恐社交恐怖分子 全网同名胖头鱼的鱼缸 ITPUByhw1809 除授权转载并标明出处外均为“非法”抄袭本期继续“川序”的介绍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 规范约定调用格式凭证撤销和资源权限前端菜单改善用户体验直接接口访问控制频道成员限制协作可见性数据库资源授权数据库策略执行数据边界终止外部任意进程这张表的重点不是否定 Prompt 或 API——它们有它们的位置。安全需要最底层有强制边界也需要上层用提示、协议和体验来减少误用。但别把上层的“减少误用”当成底层的“强制执行”。四、如何验证安全安全测试不能只测正常用户。得分别用普通用户、无权限 Agent、过期凭证、被撤销凭证、跨组织 Agent 和频道成员去访问还要绕过前端直接调 HTTP、MCP 或 Skill 接口。测试结果应该证明看不到的数据不会被检索不能执行的动作不会被提交凭证撤销后后续请求立即受影响异常拒绝会留下审计证据。还可以加一组“恶意”测试在消息里要求 Agent 忽略权限提示词注入在参数里替换 Agent ID伪造主体在频道里塞未授权主体——看服务端是不是还以认证会话和数据库事实为准。测试不能只看页面有没有报错——还得翻数据库确认没有产生越权读取、工具调用或副作用记录。此前在《Agent 上线之后谁来负责它》里聊过生命周期管理安全边界其实就嵌在那条生命周期的每一个环节里。而 Agent 的身份本身——是谁、能做什么——则是边界判断的前提这个话题将在后面的文章里里展开。五、上线前的控制清单上线前可以逐项确认人和 Agent 是否有独立身份数据库是否拒绝默认回退凭证Skill、MCP、HTTP 和页面是否走同一套授权服务敏感配置是否加密撤销是否在后续请求生效外部回调是否验证来源审计是否带请求关联 ID应急操作是否要求理由和留痕。这份清单不能替代渗透测试或第三方安全审计。但它能帮客户发现最常见的工程缺口。安全不是一个模块上线后才补的功能而是身份、数据、执行和运维在整个生命周期里的共同约束。六、安全也有边界零信任不是万能的。它不能自动撤回 Agent 已经导出的数据也不能直接终止数据库外部正在跑的任意进程。所以企业还需要受控凭证、外部系统回调校验、运行时隔离、日志留存和处置流程来配合。同时企业也需要做好 AI 时代的企业管理加强对人的管控。总结安全不是一条提示词而是一组可验证的控制链。身份、授权、执行和证据同时存在Agent 才能在企业环境里被信任地使用。对客户来说零信任的价值不是让系统“看起来更安全”而是把数据访问和副作用控制变成可以执行、测试、审计和复核的工程事实。老规矩知道写了些啥。