智能体安全基线：从一次工具调用开始自评

作者：Max Luo · 2026年10月11日 · Teloa AI Security

企业 Agent 的安全问题常发生在一个具体动作里：模型把检索结果中的文字理解成新指令，工具把模型给出的用户标识当成真实身份，连接器又用拥有全库权限的共享密钥完成了操作。三个组件分别“正常工作”，组合起来却形成了越权路径。

这篇文章用“检索本月客户工单，生成摘要，发给项目组”建立一份可以复验的评审方法。我们关心的是身份、权限、数据和外部效果如何沿调用链传播，以及哪个组件有能力阻止它。示例是教学用的参考设计和假设评估记录，不是对 Teloa 产品符合性的声明。

《企业智能体身份与授权安全基线》v1.0将这些设计经验整理为 240 条要求。本文解释如何把条款转成工程问题；规范中的等级、适用条件和措辞仍以正文为准。

1. 先固定业务意图与攻击者能力

设员工 user-42 只能访问租户 tenant-a 的 project-a 工单。任务允许读取 10 月工单、生成不含原始客户联系方式的摘要；外发前要确认真实收件人和正文。Agent 的可用工具是工单检索与消息草稿，执行实例是 run-17。

评审需要明确三种攻击者能力：攻击者能控制一条工单的正文；能向开放渠道提交消息；或已经控制了执行实例内的代码进程。它们分别对应提示注入、身份冒用和执行环境失陷。默认攻击者不能修改企业 IdP、平台身份登记、策略服务与出口网关；如果这些控制面也被攻陷，应进入独立的基础设施与事件响应评审。

把攻击路径写出来，可以避免只测试“模型有没有拒绝恶意提示词”。即使模型生成了危险请求，控制面也应该能拒绝执行；如果模型碰巧没有生成请求，并不能证明执行边界有效。

2. 把 Harness 与安全控制放在正确的信任边界上

Agent 由模型与 Harness 组成。Harness 管理循环、上下文、工具与编排；框架提供开发抽象，运行时负责持久执行与恢复。一个框架是否提供工具回调，并不能直接回答该回调是否不可绕过、是否具有可信身份、是否能约束代码执行。

安全评审应画出两种路径：决策路径从可信身份进入策略服务；实际访问路径从执行环境进入网关和下游。两者必须在同一项已确认的调用上会合。模型输出、工具返回、网页和执行实例按不可信处理；平台托管且 Agent 无法修改的控制组件承担授权责任。

“所有调用都经过工具函数”需要进一步验证。代码、浏览器、MCP 进程、数据库驱动是否也能访问网络？控制钩子是否与被检查的脚本处于同一个可写进程？沙箱是否能读到真正的 SaaS 密钥？这些路径如果可以绕开网关，受控工具上的审批只是局部控制。

V4.2.2、V4.2.3 对平台托管环境要求默认拒绝出站和下游拒绝直连；端侧环境另按 V5.4 评估。网关也不能只做 TLS 转发：它必须理解工具、操作、资源范围及凭证目标，才能执行授权决定。

3. 为一次调用建立可核验的记录

下面是一份平台根据认证、登记和工具解析结果生成的调用记录。字段名是示例，不是新的标准协议；模型只提出工具和参数，不能直接生成可信的身份字段。

{
  "request_id": "req-17-02",
  "principal": {
    "user": "user-42",
    "agent": "agent-support",
    "workload": "run-17",
    "tenant": "tenant-a"
  },
  "task": "task-october-summary",
  "tool": "tickets.search",
  "tool_version": "sha256:reviewed-schema-digest",
  "arguments": {
    "project": "project-a",
    "period": "2026-10",
    "limit": 100
  },
  "context": {
    "has_untrusted_input": true,
    "has_nonpublic_data": true
  },
  "authorization": {
    "policy_version": "policy-23",
    "decision_id": "decision-221"
  }
}

这里有三个容易被忽略的点。租户从可信登记推导，不来自请求正文；工具版本绑定已审核的工具定义，不能让同名工具更新参数结构后继续继承旧审批；上下文状态由平台维护，模型不能用“我已经清理输入”将其重置。

has_untrusted_input 只是最小示意。生产系统还要保留来源、数据标签和传播关系；数据进入摘要、文件、记忆或子 Agent 后，敏感性不能因为形式变化自动消失。记录里不放原始凭证；工单内容与收件人等敏感字段需要脱敏或限制调阅。

4. 沿请求链检查六个安全不变量

安全不变量是无论模型如何选择下一步，都必须成立的条件。

1. 身份不能由请求自报。 网关从已认证工作负载及平台登记得到用户与 Agent；改动参数中的 user_id 不得改变执行主体，对应 V1.4.3。
2. 权限只能收窄。 有效操作必须同时处于用户当前权限、Agent 授权范围以及适用的任务和委托限制内。子 Agent 不得补上发起人没有的权限，对应 V2.2 与 V2.4。
3. 批准内容与实际效果一致。 收件人、正文、附件、资源范围和数量发生变化时，旧审批不能继续使用，对应 V3.4.2、V3.4.3。
4. 凭证不能越过目标边界。 真正密钥只在受控组件中取用，并且仅注入绑定的域名和路径，对应 V4.1、V4.7。
5. 接触数据不等于获准外发。 读取不可信内容或非公开数据后，外发默认需要审批，对应 V6.2.1、V7.5.4；合法读取不会自动授予发送权限。
6. 结果按接收者权限展示。 群里有权触发任务的人，不一定有权把结果发给全部成员，对应 V7.1；允许查询与允许展示是两次不同的判断。

这些条件是结合多个条款得到的工程解释。实现时仍需区分 L1、L2、L3：例如用户与 Agent 的权限交集是 L1 要求，每次调用重新计算有效权限是 L2 要求，不能把本文整条参考流程都宣称为 L1 的强制实现。

5. 用一条成功路径定位控制责任

先跑一条可观察的正常路径，再改造它进行失败实验。

证据需要跨组件关联。只有 Harness 日志中的“已拒绝”还不够：要核对网关没有注入凭证、下游没有产生消息、重试队列没有继续执行。反过来，一条下游成功日志也不能解释批准它的是谁。使用请求 ID、决策 ID、审批 ID 和下游效果 ID 连接这些事件，才能复原决策到效果的完整链路。

6. 失败实验比产品能力列表更有判断力

给每个实验设置一个明确的外部效果计数器，例如测试邮箱收到的邮件数量或测试工单的写入次数。所有测试都在隔离租户和测试下游进行，保留同一请求的时间线。

测试模型未生成攻击请求时，可以通过测试专用入口提交等价的工具调用，单独验证策略执行点。这个入口不能成为生产旁路。评估记录要同时区分“模型行为符合预期”和“执行控制挡住了危险请求”，避免把前者当作后者的证据。

7. 将实验变成自评结果与修复计划

v1.0 的 L1 是 90 条，L2 累计 227 条，L3 累计 240 条。先确定目标等级，再判断适用条件。V2.3 适用于定时任务或长时任务；不支持这两类用户离线委托能力时，才可依据适用条件排除。没有定时功能但仍支持用户离线后的长时任务，不能将本节排除；提供了对应能力却没有运行前复查，就是缺口。

下面是假设的示例评估，不是任何产品的测评结论。

“部分满足”不能据此把条款判为满足。第 6.4 节要求同一条款的所有分句均满足；“应能”“应支持”核验可启用的能力，其余要求核验当前部署实际生效。满足比例可以帮助排序整改，但不能替代逐条证据，也不能将高比例直接转为认证结论。

在自评工具中记录状态、证据、负责人和计划完成时间；保存平台版本、目标等级和范围说明，与导出结果一起归档。修复后用原实验复验，并确认失败路径的外部效果确实为零。紧急停用和权限撤销应记录实测延迟与约定上限，不能仅写“支持秒级撤销”。

8. 从最容易造成实际损失的路径开始改造

工程上可以先选一条高价值流程：客户数据导出、对外消息、生产变更或支付。第一轮补齐可信主体、实际参数授权、受控凭证出口和完整审计；第二轮扩展到子 Agent、定时任务、MCP 与浏览器操作。每增加一种执行入口，都需要回答“它是否仍满足相同的安全不变量”。

一个可以借鉴的设计判断是：让模型负责提出候选动作，让可信控制面负责决定执行条件；将审批绑定到会产生外部效果的对象，并在实际效果发生处检查它。这样，提示注入的危害可以被限制在受控调用范围里，安全团队也能用确定的失败实验评估边界。

继续阅读身份篇中的绑定、签发与撤销设计，以及授权篇中的权限计算和执行流程。完整标准与工具源码由 Teloa AI Security维护，参考架构可在多语言图集查看。基线源于 Teloa 的开发实践，开放用于其他平台的设计与评审。