开场：安全不是加一层提示词就够的

安全不是加一层提示词就够的，需要从架构层面进行结构性设计。 本文介绍一套系统化的安全分类框架：三类风险、双层防线、凭证隔离与多层信任。核心原则一句话——生成的代码和密钥永远不能在同一个地方，结构性安全比靠提示词更可靠。

一、三类风险：先查自己家

每种 AI 产品面对的威胁模型不同，但所有风险都可以归入三个类别。理解这三类风险是设计安全架构的第一步。

风险 1：Misuse（用户滥用）

用户故意让 Agent 做不该做的事情。这是来自用户侧的主动威胁：

• 利用 Agent 生成钓鱼邮件
• 诱导 Agent 执行恶意代码
• 利用 Agent 获取未授权的数据
• 通过越狱攻击绕过安全限制

风险 2：Misbehavior（模型失控）

模型自发的错误行为：没人指使它，但它自己做了不该做的事：

• 过度行动： 用户只让查看文件，模型却自作主张修改了
• 幻觉驱动操作： 基于虚构信息执行了真实操作
• 权限越界： 模型尝试访问不属于当前任务的资源
• 停不下来： Agent 进入无限循环

风险 3：External Attack（外部攻击）

第三方通过注入恶意内容来操控 Agent 的行为。攻击来自数据源，用户本身可能毫不知情：

• Prompt Injection： 网页/文档中嵌入攻击指令
• 供应链攻击： 恶意 MCP 服务器返回篡改数据
• 数据投毒： 训练数据中植入后门
• 间接注入： 通过 Agent 读取的邮件/文件注入指令

三类风险的共同点：安全不能依赖模型自觉，必须从架构层面做结构性设计。

二、双层 Containment 策略

模型层防线（Model Layer）

通过训练让模型从内心倾向于安全行为，就像培养一个有良好价值观的员工：

• RLHF/Constitutional AI 训练安全偏好
• 模型学会拒绝危险请求
• 模型在不确定时主动询问用户
• 遵循最小权限原则

环境层防线（Environment Layer）

通过系统架构让危险操作无法执行，就像给仓库加锁，不依赖员工的自觉：

• 沙箱隔离： 代码执行在受限环境中
• 权限控制： 按任务粒度授权
• 审批机制： 高危操作需人工确认
• 网络隔离： 限制 Agent 的网络访问范围

两者互补，缺一不可。 模型层是让 Agent 想做对的事，环境层是让 Agent 即使想做错也做不到。只靠 Prompt 告诉模型「别做坏事」是不够的，你还需要在架构上让坏事不可能发生。

三、MCP 的双重风险

Model Context Protocol 带来了新的攻击面。

供应链风险（Supply Chain Risk）

不可信的 MCP 服务器可能注入恶意内容。Agent 信任 MCP 返回的工具描述和数据，但这些数据可能已被篡改。一个恶意的 MCP 服务器可以通过修改工具描述来操控 Agent 的行为：Agent 以为自己在用「搜索文件」工具，实际上在执行删除操作。

注入攻击（Prompt Injection）

MCP 返回的内容可能包含攻击指令。即使 MCP 服务器本身没有恶意，它返回的数据（比如从网页抓取的内容）可能包含 Prompt Injection 攻击。Agent 处理这些数据时，可能被说服执行非预期的操作。

MCP 本质上扩大了 Agent 的攻击面。 每多接入一个 MCP 服务器，就多了一个潜在的数据注入入口。产品设计者需要像审核第三方 SDK 一样审核每个 MCP 集成，信任但要验证。

四、Auto Mode 的实践数据

分类器 + 沙箱：高自主与低风险的组合

~83% 权限弹窗减少比例，2 个核心组件。

Auto Mode 通过两个核心组件实现了高自主 + 低风险的平衡：

分类器（判断操作是否安全）
+
沙箱（即使误判也不会造成破坏）
=
高自主 + 低风险

分类器负责快速判断每个操作的风险等级：安全操作直接执行，可疑操作才弹窗询问。沙箱作为第二道防线，确保即使分类器误判，代码执行也不会对系统造成真实损害。两者组合，让用户减少了约 83% 的确认弹窗，同时保持了安全性。

五、核心原则：凭证与执行环境物理隔离

Agent 生成的代码和用户的密钥永远不能在同一个地方。 这是安全架构的硬性要求，不只是最佳实践的建议。

旧方案出了什么问题

传统架构：一个容器装所有东西。 代码执行、API 密钥、OAuth Token、会话凭证，全部共存在同一个运行环境中。Agent 能看到的一切，恶意代码也能看到。

Prompt Injection 一步偷走密钥： 攻击者只需通过 Prompt Injection 说服 Agent 执行一行代码（echo $API_KEY），就能窃取环境变量中的所有密钥。整个攻击链极短，防不胜防。

Agent 越聪明，问题越严重： 能力更强的 Agent 意味着更强大的工具调用能力，而在旧架构下，这也意味着更大的攻击面。模型的进步不会自动解决这个问题，反而会让它恶化。

模型能力越强，安全问题越严重。 这意味着安全架构不能依赖模型自觉，必须通过结构性设计来保证：即使模型被完全控制，攻击者也拿不到凭证。

六、两种凭证隔离模式

模式 1：绑定到资源

Token 在使用时被嵌入到资源的访问路径中，从不作为独立变量存在。Agent 能用它，但看不到它。

Git 克隆场景： Token 在克隆时注入到 remote URL 中：https://[email protected]/repo.git。沙箱内的 Agent 可以正常执行 push/pull 操作，但无法直接读取或提取 Token——它被嵌入在 Git 配置的深层，不是一个可读的环境变量。Token 注入 Remote URL，Agent 可用不可见。

模式 2：Vault 代理模式

Token 存在安全的 Vault 服务中，Agent 的每次 API 调用都通过代理转发。代理根据 Session ID 查找对应凭证并注入请求，Agent 永远接触不到原始 Token。

MCP OAuth 场景： Agent 发起 MCP 调用时，请求先到达代理服务。代理根据当前 Session ID 从 Vault 中查找对应的 OAuth Token，将 Token 注入请求头后转发到目标 MCP 服务器。Agent 全程只知道「调用成功了」，但从未见过 Token 的任何一个字符。Agent 发请求 → 代理注入 Token → 目标服务。

七、OS 级沙箱隔离：三重隔离屏障

• 文件系统隔离： Agent 只能访问工作目录下的文件，无法读取宿主机的其他文件系统路径。凭证、配置、系统文件全部不可见。
• 网络隔离： 沙箱限制网络访问范围，Agent 无法向任意外部服务发送数据。即使获取了凭证，也无法外传。
• 进程隔离： Agent 的代码执行在独立进程空间中，无法访问宿主机的其他进程。既不能读取其他进程的内存，也不能发送信号。

八、三层信任层级：从工具到组织

工具级信任（Tool）

最细粒度的控制。某些特定工具需要每次使用都经过人工审批，比如文件删除、数据库写入、发送邮件等高危操作。对于安全的只读操作（如搜索代码、读取文件），可以设为自动放行。

会话级信任（Session）

某次对话的权限范围。用户在开始会话时授予 Agent 特定范围的权限（如「可以读写 /src 目录但不能改 /config」），整个会话期间权限范围保持不变。会话结束后权限自动回收。

全局级策略（Global）

组织级的安全策略限制。无论用户在会话中授予什么权限，Agent 都不能违反全局策略，比如「永远不能访问生产数据库」「不能向外部域名发送请求」。这是安全的兜底防线。

结语

安全需要结构性设计，不能靠提示词自觉。回顾全文：三类风险（用户滥用、模型失控、外部攻击）帮你先查自己家；双层防线（模型层 + 环境层）让 Agent 既想做对的事、又做不了错事；凭证隔离（绑定资源 / Vault 代理）保证即使模型被完全控制也拿不到密钥；三层信任（工具 / 会话 / 全局）从最细粒度到组织兜底逐层设防。

结构性安全 > 提示词安全。 设计上让攻击不可能，模型自觉靠不住。凭证和执行环境物理隔离、多层信任控制、OS 级沙箱，这些是让 Agent 在生产环境安全运行的基石。