当 AI 团队提出要上线 Agent 时，真正需要追问的不是"效果好不好"，而是：它能动什么、谁批准的、出事能追溯吗。 Agent 是大模型安全里风险跳变最大的一步------从"说错话"变成"做错事"。
当模型只负责回答问题，错误停留在文本层；当模型可以调工具、执行动作，错误就变成了系统行为。
上一篇文章讲了护栏怎么防输入输出的语义风险。但当一个 Agent 可以查数据库、发邮件、改配置、提交工单------语义安全就不够了，你还需要权限安全。
这篇文章讲的核心问题是：模型能调工具，但权限怎么管？
一、为什么单独讲 Agent
前一篇讲输入输出防护，主要处理"模型怎么说"的问题。Agent 不一样，它处理的是"模型能不能做、能做到哪一步、做错了谁负责"的问题，所以需要单独拿出来讲权限、工具、审计和回滚。
它承接第 3 篇的输入输出防护，进一步处理风险更高的执行面：当模型不只是回答，而是能调用工具、改数据、发请求、触发业务动作时，权限和审计必须重新设计。
二、Agent 权限问题的本质
很多 AI 安全事故不是因为模型"知道太多"，而是因为它"能做太多"。
OWASP 把这个风险叫"Excessive Agency"------过度授权。本质上是：能建议，不代表能执行；能调用工具，不代表应该拿到完整权限。
传统系统里，配置、代码、用户输入和数据库记录有清晰的边界。但在 Agent 系统里，自然语言最终都可能被翻译成工具调用，而工具调用在现实系统中往往不是"建议"而是"命令"。
所以 Agent 安全的核心不是提示词更强，而是执行面更小、策略更硬、隔离更彻底。
三、一个真实漏洞的完整拆解：CVE-2026-27966
这个案例能让你看到，一行硬编码怎么让一个"读 CSV"的 Agent 变成远程代码执行的入口。
事件经过
Langflow 是一个流行的 LLM 应用开发平台。它的 CSV Agent 节点在创建时， 把 allow_dangerous_code 硬编码为 True，导致默认打开了 LangChain 的 Python REPL 工具。
这意味着什么？CSV Agent 不只是"读 CSV"，而是挂了一个完整的 Python 解释器入口。任何进入上下文的文本------包括恶意注入的指令------都有机会被模型翻译成工具调用，并在没有独立裁决的情况下被执行。
攻击链路（四步）
-
注入载荷进入上下文：间接注入------Agent 读取外部文本（知识库、工单、邮件正文）时把恶意指令当成高优先级规则
-
模型翻译为工具调用 ：工具协议对模型来说"非常像工作流"，恶意指令被结构化为
Action Input -
执行器无条件执行：没有独立于模型的策略裁决点，Action Input 被当作代码送入 REPL
-
影响扩散：真实部署中往往伴随文件系统、网络、数据库访问能力，一次执行可以演变为更大范围的入侵
来源：GitHub Advisory GHSA-3645-fxcv-hqr4，NVD CVE-2026-27966
为什么容易被忽略
-
以为"内网 = 可信"，忽略注入可能来自知识库、工单、邮件正文
-
以为"没有运行按钮就不会执行"，忽略 Agent 的自动规划
-
以为"系统提示写了不要执行危险命令就能兜底"，忽略提示注入会重排优先级
更根本的错误是把 LLM 系统当作"增强版搜索"，而不是"具备执行能力的自动化系统"。
四、最小权限设计：五个控制面
最小权限设计的核心是：Agent 只拥有完成当前任务所需的最小上下文、最小工具权限和最小动作范围。
具体来说，需要分别设计五个控制面：
1. 身份控制
-
Agent 应该有独立身份，而不是直接复用人类员工的长期权限
-
一次任务的授权做成临时、可回收、可审计的委托
2. 工具权限分层
按风险等级给工具分层：
| 风险等级 | 操作类型 | 控制要求 |
|---|---|---|
| 低 | 只读查询（SELECT） | 日志记录 |
| 中 | 写入操作（INSERT/UPDATE） | 参数校验 + 日志 |
| 高 | 删除、发送、支付 | 参数校验 + 权限检查 + 人工确认 |
| 严重 | 系统配置变更、代码执行 | 参数校验 + 权限检查 + 人工确认 + 回滚机制 |
3. 上下文裁剪
-
不可信输入不应该直接决定高权限工具的参数
-
检索结果不应该自动获得"指令"的身份
4. 执行隔离
这是最关键的架构决策。把 Agent 的输出拆成两层：
-
Proposal 层：模型负责提出建议和生成参数
-
Execution 层：独立于模型的执行层负责校验权限、验证参数、判断风险、记录日志
即使模型被诱导，错误也会停在 Proposal 层，不会自动穿透到业务系统。
5. 审计追踪
每一步工具调用都需要记录：谁触发的、调了什么工具、参数是什么、结果是什么、是否有异常。这就是所谓的"最小审计链"：主体身份 → 任务上下文 → 执行动作 → 风险判断 → 结果留痕。
五、执行隔离架构：No-Read Principle
执行隔离型智能体架构（XOA）提出了一个更激进的原则：高权限执行单元尽量不直接读取不可信原文。
核心设计：
-
No-Read Principle：执行层不直接读原文，只接收经过净化的结构化指令
-
Execute-Only Sandbox：模型可以生成脚本或计划，但脚本在受限沙箱中执行
-
Harness/Compute 分离：控制平面负责策略、授权、审批和恢复；执行平面负责实际运行
-
数据与指令分层：把"参考内容"与"可执行控制信号"分开
它不是让模型更会识别恶意内容，而是让高权限执行尽量不直接暴露给不可信原文。
适用场景：浏览器或文档阅读型 Agent、带 RAG 与外部网页接入的工作流、会修改数据/发消息/调接口的执行型 Agent。
六、MCP 安全：Agent 调用外部服务的协议风险
MCP（Model Context Protocol）正在成为 Agent 连接外部工具和服务的重要接口协议之一。但 OWASP 在 2026 年专门发布了 MCP 的十大安全风险，核心问题包括：
-
工具描述注入：恶意工具通过描述文本向 Agent 注入指令
-
权限边界模糊：MCP Server 的权限没有被明确限定
-
数据外带：工具返回值中携带敏感信息
防护要点：
-
给每个 MCP Server 设定明确的权限边界
-
对工具返回值做独立校验，不直接拼入上下文
-
记录所有 MCP 调用的完整审计日志
开源工具 AgentBound 专门解决这个问题------给 MCP Server 套上权限边界，限制工具调用的范围和频率。
问题引申：这个AgentBound和Harness是什么关系？又有什么联系？
七、CVE-2026-27966 的四层防护框架
回到那个 CSV Agent 的案例，如果当时有这四层防护，RCE 就不会发生：
第一层：工具面最小化
-
• 优先提供窄能力工具（筛选、聚合、统计）而不是通用 REPL
-
• 确需 REPL 则默认关闭，显式开启
第二层：独立裁决
-
• 工具调用前用确定性策略回答：此场景是否允许？参数是否越界？是否需要人工确认？
-
• 不要把判断再次交给模型
第三层：隔离与最小权限
-
• 执行环境与主服务隔离
-
• 限制文件写入、网络出站、凭证注入与资源使用
第四层：可观测与失效关闭
-
• 结构化记录工具调用并建立异常信号
-
• 触发异常就暂停自动执行、切换只读或转人工
安全负责人行动项：如果AI团队提出要上线Agent，用上面五个控制面逐一检查。任何一条不满足，不应批准上线。
八、上生产前必问的三个问题
如果你正准备把 Agent 接入生产系统，先回答这三件事：
- **它能否在无人干预时执行通用代码或系统命令？**如果能，默认关闭，需要显式授权。
- 工具调用前是否有独立于模型的裁决器？ 如果没有，加一个确定性的策略检查层。
- **执行环境是否隔离并遵循最小权限？**如果不是，先做沙箱化再上线。
九、小结
Agent 权限治理的核心原则：
-
模型不是操作员------它的输出应该经过独立校验才能执行
-
工具按风险分层------高风险动作必须有额外门禁
-
执行隔离------Proposal 层和 Execution 层分开
-
最小权限------只给完成任务所需的最小能力
-
审计追踪------每一步可追溯、可回滚
下一篇，我们继续深入供应链安全------大模型应用的供应链比传统应用更长，投毒风险更大。
汇报要点：向领导汇报Agent安全时，用"高风险工具已纳入人工确认和轨迹审计"这句话------它比技术细节更有说服力。
参考资料：
1、https://mp.weixin.qq.com/s/zyZYL8Sn8NjXLPWrFwmgQA?scene=1&click_id=9