当 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 解释器入口。任何进入上下文的文本——包括恶意注入的指令——都有机会被模型翻译成工具调用，并在没有独立裁决的情况下被执行。

        攻击链路（四步）

        1. 注入载荷进入上下文：间接注入——Agent 读取外部文本（知识库、工单、邮件正文）时把恶意指令当成高优先级规则

        2. 模型翻译为工具调用：工具协议对模型来说"非常像工作流"，恶意指令被结构化为 Action Input

        3. 执行器无条件执行：没有独立于模型的策略裁决点，Action Input 被当作代码送入 REPL

        4. 影响扩散：真实部署中往往伴随文件系统、网络、数据库访问能力，一次执行可以演变为更大范围的入侵

        来源：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 接入生产系统，先回答这三件事：

1. 它能否在无人干预时执行通用代码或系统命令？如果能，默认关闭，需要显式授权。
2. 工具调用前是否有独立于模型的裁决器？ 如果没有，加一个确定性的策略检查层。
3. 执行环境是否隔离并遵循最小权限？如果不是，先做沙箱化再上线。

九、小结

Agent 权限治理的核心原则：

• 模型不是操作员——它的输出应该经过独立校验才能执行

• 工具按风险分层——高风险动作必须有额外门禁

• 执行隔离——Proposal 层和 Execution 层分开

• 最小权限——只给完成任务所需的最小能力

• 审计追踪——每一步可追溯、可回滚

        下一篇，我们继续深入供应链安全——大模型应用的供应链比传统应用更长，投毒风险更大。

        汇报要点：向领导汇报Agent安全时，用"高风险工具已纳入人工确认和轨迹审计"这句话——它比技术细节更有说服力。

参考资料：

1、https://mp.weixin.qq.com/s/zyZYL8Sn8NjXLPWrFwmgQA?scene=1&click_id=9