你的 AI 代理需要自己的钥匙

一个会写程序、部署 web 函数的代理，需要一个执行身份。让它运行之前，先决定这个身份能读哪些记录、调用哪些服务、最多花多少钱。

所有函数共用一个大权限的服务账号，demo 很快就能跑起来；可只要其中一个代理被攻破，它也就拿到了这个账号能碰的全部资源。身份分开，权限才好分别收紧，出了事也更容易查清是谁做的。

检索要沿用文档原有的权限

代理能把多次操作串起来执行，访问控制上的疏漏代价也就格外高。

最典型的例子是公司内部的搜索助手。有人用管理员账号给内部文档建索引，索引里于是什么都有。助手拿这个索引回答任何员工的问题，一个初级分析师就能问出高管团队拿多少薪水。文件系统里原本有文档权限，建索引那一步悄悄把它们压平了。

多租户应用要让租户身份贯穿检索、工具调用和写入。每条受支持的访问通道，都要加入跨租户访问测试。测试只能覆盖写进去的情形，代码审核和监控仍要寻找遗漏。

每个代理一个受限身份

给部署的函数分别分配角色，再用权限边界限制角色最多能拿到什么权限。要实际测试一次禁止动作，例如读取另一个租户的存储。单个函数的请求、并发和花费上限可以减少循环失控的损失，共享的依赖服务也需要单独保护。

密钥按同样的思路处理。代理会写代码，代码会进日志、进代码仓库、进聊天记录，所以设计上让 API key 完全不出现在代理的代码里。函数调用一个小的转发服务，key 在请求出去的路上才被附加上去，代理自始至终看不到它正在用的那个值。公司数据进入函数也要走一条有中间层把关的通道，先确认数据归谁，再交出去。

即使代理理解错了请求，这些访问检查也必须照样生效。身份独立还有一个好处：要停掉某个工作流时，只需撤销它的身份，不必把共用同一账号的所有服务一起停掉。

文档里可能夹带指令

代理读邮件、读工单、读上传的文件，难免会遇到组织外部的人写下的指令，其中有些就是想把它引到别的事情上去。一份 PDF 里可以藏一行白色字体，让助手把文件转发到某个外部邮箱。OWASP 的 2025 年风险清单把提示词注入排在首位，并建议用多层控制降低影响。

检索回来的文字要按不可信输入处理。提示模型忽略文档中的指令，只是其中一层防护。工具权限必须在模型之外执行，做摘要的任务就不给发邮件的工具。外发数据、花钱、改权限时，审核人要看到具体收件人、金额或变更内容，再作决定。

隐私问题，大半取决于你留下了什么

团队共用的代理能让有用的工作被更多人看到，也会让错误传得更广。共享对话仍要遵守原始文档的访问权限，同一个答案在一个群里可以公开，在另一个群里可能就是泄密。

开始录音之前，要先识别会议可能涉及的个人信息和商业机密，明确收集用途，以及需要取得的同意或其他依据。谁能读取录音、何时过期，也要定下来。这些都是设计要求，应请机构的隐私负责人按适用地区的规定核对。

建立索引前，先遮盖不需要的敏感字段。删除材料时，要清理在线索引和缓存，并写清备份何时过期、恢复备份后怎样继续执行删除。服务商的条款、保留设置和处理地点都要对照客户的要求逐项核对，光有一句「不用数据训练模型」的承诺解决不了这些问题。

亲眼看一次被拒绝的操作

采购审核需要看控制措施的证据。安全相关的操作要记下操作者、租户、工具、结果和时间，同时避开密钥和不必要的个人信息。除了成功请求，也要测试告警能否触发、撤销权限能否生效。

把代理接入公司数据之前，先要一份允许操作的清单和一段脱敏后的近期操作记录。再选一项它绝不应该做到的操作，现场看着系统把它拒掉。日志能说明做过什么，拒绝测试才能检验权限边界。