安全与容器化

三类风险：滥用、失控、外部攻击

安全不是加一层提示词就够的，需要从架构层面进行结构性设计。这里介绍一套系统化的安全分类框架。

安全分类框架

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

MISUSE
用户滥用
用户故意让 Agent 做不该做的事情。这是来自用户侧的主动威胁。
  • 利用 Agent 生成钓鱼邮件
  • 诱导 Agent 执行恶意代码
  • 利用 Agent 获取未授权的数据
  • 通过越狱攻击绕过安全限制
MISBEHAVIOR
模型失控
模型自发的错误行为：没人指使它，但它自己做了不该做的事。
  • 过度行动：用户只让查看文件，模型却自作主张修改了
  • 幻觉驱动操作：基于虚构信息执行了真实操作
  • 权限越界：模型尝试访问不属于当前任务的资源
  • 停不下来：Agent 进入无限循环
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 在实际生产环境中安全运行。
安全与容器化

沙箱与凭证隔离

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

核心原则
生成的代码和密钥
永远不能在同一个地方
这是管理 Agent 安全的第一原则：凭证与执行环境的物理隔离。
旧方案出了什么问题

传统架构：一个容器装所有东西

所有东西在一个容器里
代码执行、API 密钥、OAuth Token、会话凭证，全部共存在同一个运行环境中。Agent 能看到的一切，恶意代码也能看到。
Prompt Injection 一步偷走密钥
攻击者只需通过 Prompt Injection 说服 Agent 执行一行代码（echo $API_KEY），就能窃取环境变量中的所有密钥。整个攻击链极短，防不胜防。
Agent 越聪明，问题越严重
能力更强的 Agent 意味着更强大的工具调用能力。而在旧架构下，这也意味着更大的攻击面。模型的进步不会自动解决这个问题，反而会让它恶化。
模型能力越强，安全问题越严重。这意味着安全架构不能依赖模型自觉，必须通过结构性设计来保证：即使模型被完全控制，攻击者也拿不到凭证。
两种凭证隔离模式
MODE 1
绑定到资源
Token 在使用时被嵌入到资源的访问路径中，从不作为独立变量存在。Agent 能用它，但看不到它。
GIT 克隆场景
Token 在克隆时注入到 remote URL 中：
https://token@github.com/repo.git
沙箱内的 Agent 可以正常执行 push/pull 操作，但无法直接读取或提取 Token：它被嵌入在 Git 配置的深层，不是一个可读的环境变量。
Token
注入 Remote URL
Agent 可用不可见
MODE 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 都不能违反全局策略，比如「永远不能访问生产数据库」「不能向外部域名发送请求」。这是安全的兜底防线。
结构性安全 > 提示词安全。设计上让攻击不可能，模型自觉靠不住。凭证和执行环境物理隔离、多层信任控制、OS 级沙箱，这些是让 Agent 在生产环境安全运行的基石。
1 / 4