安全与容器化

沙箱与凭证隔离

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 在生产环境安全运行的基石。