安全部署 AI 智能体

Claude Code 和 Agent SDK 可以代你执行代码、访问文件并与外部服务交互。与遵循预先确定代码路径的传统软件不同，这些工具根据上下文和目标动态生成它们的动作。这种灵活性正是它们有用的原因，但也意味着它们的行为可能受到它们所处理内容（文件、网页或用户输入）的影响，这有时被称为提示注入。例如，如果仓库的 README 含有不寻常的说明，Claude Code 可能以运营者没有预料到的方式把它们纳入自己的动作。本指南涵盖降低这种风险的实用办法。

并非每个部署都需要最高的安全。开发者在笔记本上运行 Claude Code 与公司在多租户环境里处理客户数据有不同的要求。本指南给出从 Claude Code 内置安全特性到加固的生产架构的一系列选项，让你选择适合你情况的。

威胁模型

智能体可能因提示注入（嵌入在它们所处理内容里的指令）或模型错误而采取非预期的动作。Claude 模型被设计为抵御这类情况（评估细节见模型概览和你所部署模型的系统卡）。不过纵深防御仍是好的做法。例如，如果智能体处理一个恶意文件，其中指示它把客户数据发送到外部服务器，网络控制可以完全阻止该请求。

内置安全特性

Claude Code 包含几个应对常见顾虑的安全特性（完整细节见安全文档）：

• 权限系统：每个工具和 bash 命令都可以配置为允许、阻止或提示用户批准。用 glob 模式创建如"允许所有 npm 命令"或"阻止任何带 sudo 的命令"这样的规则。组织可以设置适用于所有用户的策略（见权限）。
• 用于权限的命令解析：执行 bash 命令之前，Claude Code 把它们解析成 AST，并把结果与你的权限规则匹配。无法被干净解析、或不匹配允许规则的命令需要显式批准；eval 这类少数结构不论允许规则如何都总是需要批准。这是权限关卡，不是沙盒：除了 rm 和 rmdir 上的关键路径检查以及受保护路径列表这类内置安全检查，它不会从命令的目标路径或效果推断命令是否危险。
• 网页搜索摘要：搜索结果被做成摘要，而不是把原始内容直接传进上下文，降低来自恶意网页内容的提示注入风险。
• 沙盒模式：Bash 命令可以在限制文件系统和网络访问的沙盒环境里运行（细节见沙盒文档）。

安全原则

对于需要在 Claude Code 默认值之外进一步加固的部署，这些原则指导可用的选项。

安全边界

安全边界分隔具有不同信任级别的组件。对高安全部署，你可以把敏感资源（如凭据）放在包含智能体的边界之外；如果智能体的环境里出了问题，边界之外的资源仍受保护。例如，与其让智能体直接访问 API key，你可以在智能体环境之外运行一个把 key 注入请求的代理：智能体可以发出 API 调用，但从不看到凭据本身。这种模式对多租户部署或处理不受信任的内容时很有用。

最小权限

需要时，你可以把智能体限制在它具体任务所需的能力上：

纵深防御

对高安全环境，叠加多重控制提供额外的保护。选项包括：容器隔离、网络限制、文件系统控制、代理上的请求验证。正确的组合取决于你的威胁模型和运营要求。

隔离技术

不同的隔离技术在安全强度、性能和运维复杂度之间有不同的取舍。在所有这些配置里，Claude Code（或你的 Agent SDK 应用）都运行在隔离边界（沙盒、容器或 VM）之内；下面描述的安全控制限制智能体能在该边界内访问什么。

沙盒运行时

对不使用容器的轻量隔离，sandbox-runtime 在操作系统层面强制文件系统和网络限制。主要优势是简单：不需要 Docker 配置、容器镜像或网络设置，代理和文件系统限制是内置的。

工作方式：

• 文件系统：用操作系统原语（Linux 上的 bubblewrap，macOS 上的 sandbox-exec）限制对已配置路径的读写访问
• 网络：移除网络命名空间（Linux），或用 Seatbelt 配置文件（macOS）把网络流量经内置代理路由
• 配置：用于域名和文件系统路径的基于 JSON 的允许列表

设置：

npm install @anthropic-ai/sandbox-runtime

然后创建一个指定允许的路径和域名的配置文件。

安全考虑：

1. 同主机内核：与 VM 不同，沙盒里的进程共享宿主内核；内核漏洞理论上可能使逃逸成为可能。对某些威胁模型这是可接受的，但如果你需要内核级隔离，就用 gVisor 或单独的 VM。
2. 没有 TLS 检查：代理根据客户端提供的主机名做域名允许列表，不终止也不检查加密流量；在沙盒里运行的代码可能用域前置或类似技术到达允许列表之外的主机。如果你的威胁模型需要更强的保证，配置终止 TLS 的代理（更多细节见沙盒安全限制）。另外，如果智能体对某个允许的域名持有宽松的凭据，要确保它不能用该域名触发其他网络请求或外泄数据。

对许多单开发者和 CI/CD 用例，sandbox-runtime 以极少的设置就显著抬高了门槛。下面的章节涵盖需要更强隔离的部署所用的容器和 VM。

容器

容器通过 Linux 命名空间提供隔离。每个容器有自己对文件系统、进程树和网络栈的视图，同时共享宿主内核。安全加固的容器配置可能是这样的：

docker run \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt seccomp=/path/to/seccomp-profile.json \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /home/agent:rw,noexec,nosuid,size=500m \
  --network none \
  --memory 2g \
  --cpus 2 \
  --pids-limit 100 \
  --user 1000:1000 \
  -v /path/to/code:/workspace:ro \
  -v /var/run/proxy.sock:/var/run/proxy.sock:ro \
  agent-image

每个选项的作用：

Unix socket 架构： 用 --network none 时，容器根本没有网络接口。智能体到达外部世界的唯一途径是挂载的 Unix socket，它连接到在宿主上运行的代理。这个代理可以强制域名允许列表、注入凭据并记录所有流量。这与 sandbox-runtime 使用的架构相同：即使智能体经提示注入被攻破，它也无法把数据外泄到任意服务器，只能通过代理通信，而代理控制哪些域名可达（更多细节见 Claude Code 沙盒博客文章）。

额外的加固选项：

gVisor

标准容器共享宿主内核：容器内的代码发出系统调用时，它直接到达运行宿主的同一个内核。这意味着内核漏洞可能使容器逃逸成为可能。gVisor 通过在系统调用到达宿主内核之前在用户空间拦截它们来解决这个问题，它实现自己的兼容层，不涉及真实内核就处理大多数系统调用。如果智能体运行恶意代码（可能因提示注入），该代码在容器里运行并可能尝试内核利用。有了 gVisor，攻击面小得多：恶意代码需要先利用 gVisor 的用户空间实现，并且对真实内核的访问有限。要在 Docker 里使用 gVisor，安装 runsc 运行时并配置守护进程（/etc/docker/daemon.json）：

{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

然后这样运行容器：

docker run --runtime=runsc agent-image

性能考虑：

对多租户环境或处理不受信任的内容时，额外的隔离通常值得这个开销。

虚拟机

VM 通过 CPU 虚拟化扩展提供硬件级隔离。每个 VM 运行自己的内核，形成强边界；客户机内核里的漏洞不会直接危及宿主。不过 VM 并不自动比 gVisor 这样的替代方案"更安全"：VM 的安全高度依赖虚拟机监控器和设备模拟代码。Firecracker 为轻量级 microVM 隔离而设计：它能在 125 毫秒内启动 VM，内存开销不到 5 MiB，去掉不必要的设备模拟以减少攻击面。采用这种做法，智能体 VM 没有外部网络接口，而是通过 vsock（虚拟套接字）通信：所有流量经 vsock 路由到宿主上的代理，由代理在转发请求之前强制允许列表并注入凭据。

云部署

对云部署，你可以把上述任何隔离技术与云原生网络控制组合：

1. 在没有互联网网关的私有子网里运行智能体容器
2. 配置云防火墙规则（AWS 安全组、GCP VPC 防火墙）以阻止除到你的代理之外的所有出口
3. 运行验证请求、强制域名允许列表、注入凭据并转发到外部 API 的代理（如带 credential_injector 过滤器的 Envoy）
4. 给智能体的服务账号最小的 IAM 权限，尽可能把敏感访问经代理路由
5. 在代理处记录所有流量以供审计

凭据管理

智能体常常需要凭据来调用 API、访问仓库或与云服务交互。难点是在不暴露凭据本身的情况下提供这种访问。

代理模式

推荐的办法是在智能体安全边界之外运行一个把凭据注入出站请求的代理：智能体发送不带凭据的请求，代理添加它们，并把请求转发到目的地。这种模式有几个好处：智能体从不看到真实凭据；代理可以强制允许端点的列表；代理可以记录所有请求以供审计；凭据存放在一个安全的位置，而不是分发给每个智能体。

配置 Claude Code 使用代理

Claude Code 支持两种把采样请求经代理路由的方法：

选项 1：ANTHROPIC_BASE_URL（简单，但只对采样 API 请求有效）

export ANTHROPIC_BASE_URL="http://localhost:8080"

这告诉 Claude Code 和 Agent SDK 把采样请求发给你的代理，而不是直接发给 Claude API。你的代理收到明文 HTTP 请求，可以检查和修改它们（包括注入凭据），然后转发给真实 API。

选项 2：HTTP_PROXY / HTTPS_PROXY（系统范围）

export HTTP_PROXY="http://localhost:8080"
export HTTPS_PROXY="http://localhost:8080"

Claude Code 和 Agent SDK 遵从这些标准环境变量，把所有 HTTP 流量经代理路由。对 HTTPS，代理创建加密的 CONNECT 隧道：没有 TLS 拦截，它无法看到或修改请求内容。

实现代理

你可以构建自己的代理或使用现有的：Envoy Proxy——带用于添加认证头的 credential_injector 过滤器的生产级代理；mitmproxy——用于检查和修改 HTTPS 流量的终止 TLS 的代理；Squid——带访问控制列表的缓存代理；LiteLLM——带凭据注入和速率限制的 LLM 网关。

其他服务的凭据

除了从 Claude API 采样之外，智能体常常需要对其他服务（如 git 仓库、数据库和内部 API）的经认证访问。有两种主要办法：

自定义工具。 通过 MCP 服务器或自定义工具提供访问，把请求路由到运行在智能体安全边界之外的服务。智能体调用工具，但实际的经认证请求发生在外面：工具调用一个注入凭据的代理。例如，git MCP 服务器可以接受来自智能体的命令，但把它们转发到宿主上运行的 git 代理，由它在联系远程仓库之前添加认证；智能体从不看到凭据。优点：没有 TLS 拦截——外部服务直接发出经认证的请求；凭据留在外面——智能体只看到工具接口，不看到底层凭据。

流量转发。 对 Claude API 调用，ANTHROPIC_BASE_URL 让你把请求路由到能以明文检查和修改它们的代理。但对其他 HTTPS 服务（GitHub、npm 仓库、内部 API），流量通常是端到端加密的；即使你经 HTTP_PROXY 经代理路由它，代理也只看到不透明的 TLS 隧道，无法注入凭据。要在不使用自定义工具的情况下修改发往任意服务的 HTTPS 流量，你需要一个终止 TLS 的代理：它解密流量、检查或修改它，然后在转发前重新加密。这需要：1. 在智能体容器之外运行代理；2. 把代理的 CA 证书安装进智能体的信任存储（使智能体信任代理的证书）；3. 配置 HTTP_PROXY/HTTPS_PROXY 把流量经代理路由。这种办法无需编写自定义工具就能处理任何基于 HTTP 的服务，但增加了证书管理的复杂度。注意并非所有程序都遵从 HTTP_PROXY/HTTPS_PROXY：多数工具（curl、pip、npm、git）会，但有些可能绕过这些变量直接连接。例如 Node.js 的 fetch() 默认忽略这些变量；在 Node 24+ 里可以设 NODE_USE_ENV_PROXY=1 启用支持。要得到全面的覆盖，可以用 proxychains 拦截网络调用，或配置 iptables 把出站流量重定向到透明代理。透明代理在网络层拦截流量，所以客户端不需要配置成使用它；常规代理要求客户端显式连接并使用 HTTP CONNECT 或 SOCKS，而透明代理（如透明模式下的 Squid 或 mitmproxy）能处理被重定向的原始 TCP 连接。两种办法仍然需要终止 TLS 的代理和受信任的 CA 证书，它们只是确保流量真的到达代理。

文件系统配置

文件系统控制决定智能体能读写哪些文件。

只读挂载代码

智能体需要分析代码但不修改它时，只读挂载该目录：

docker run -v /path/to/code:/workspace:ro agent-image

警告： 即使对代码目录的只读访问也可能暴露凭据。挂载之前要排除或清理的常见文件：

可以考虑只复制需要的源文件，或使用 .dockerignore 风格的过滤。

可写位置

如果智能体需要写文件，根据你是否想让改动持久化，有几种选择。对容器里的临时工作区，用只存在于内存、容器停止时被清除的 tmpfs 挂载：

docker run \
  --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,size=100m \
  --tmpfs /workspace:rw,noexec,size=500m \
  agent-image

如果想在持久化之前审查改动，叠加文件系统让智能体写入而不修改底层文件：改动存放在单独的一层，你可以检查、应用或丢弃它。对完全持久的输出，挂载专用的卷，但要让它与敏感目录保持分开。

延伸阅读

• Claude Code 安全文档
• 托管 Agent SDK
• 处理权限
• 沙盒运行时
• 《AI 智能体的致命三要素》（The Lethal Trifecta for AI Agents）
• OWASP LLM 应用 Top 10
• Docker 安全最佳实践
• gVisor 文档
• Firecracker 文档