安全部署 AI 代理

Claude Code 和 Agent SDK 是强大的工具，可以代表您执行代码、访问文件并与外部服务交互。与任何具有这些功能的工具一样，周全地部署它们可以确保您在获得收益的同时保持适当的控制。

与遵循预定代码路径的传统软件不同，这些工具根据上下文和目标动态生成其操作。这种灵活性正是它们有用的原因，但这也意味着它们的行为可能受到所处理内容的影响：文件、网页或用户输入。这有时被称为提示注入。例如，如果一个代码仓库的 README 包含异常指令，Claude Code 可能会以操作者未预料到的方式将这些指令纳入其操作中。本指南涵盖了降低此风险的实用方法。

好消息是，保护代理部署不需要特殊的基础设施。适用于运行任何半可信代码的相同原则在这里同样适用：隔离、最小权限和纵深防御。Claude Code 包含多项安全功能来帮助解决常见问题，本指南将介绍这些功能以及为有需要的用户提供的额外加固选项。

并非每个部署都需要最高级别的安全性。在笔记本电脑上运行 Claude Code 的开发人员与在多租户环境中处理客户数据的公司有不同的需求。本指南提供了从 Claude Code 内置安全功能到加固生产架构的各种选项，以便您选择适合自己情况的方案。

我们在防范什么？

代理可能由于提示注入（嵌入在其处理内容中的指令）或模型错误而采取非预期的操作。Claude 模型旨在抵御这种情况，正如我们在模型卡片中分析的那样，我们认为 Claude Opus 4.6 是目前最强健的前沿模型。

不过，纵深防御仍然是良好的实践。例如，如果代理处理了一个恶意文件，该文件指示它将客户数据发送到外部服务器，网络控制可以完全阻止该请求。

内置安全功能

Claude Code 包含多项安全功能来解决常见问题。请参阅安全文档了解完整详情。

• 权限系统：每个工具和 bash 命令都可以配置为允许、阻止或提示用户批准。使用 glob 模式创建规则，如"允许所有 npm 命令"或"阻止任何包含 sudo 的命令"。组织可以设置适用于所有用户的策略。请参阅访问控制和权限。
• 静态分析：在执行 bash 命令之前，Claude Code 会运行静态分析以识别潜在的风险操作。修改系统文件或访问敏感目录的命令会被标记并需要用户明确批准。
• 网络搜索摘要：搜索结果会被摘要处理，而不是将原始内容直接传入上下文，从而降低来自恶意网络内容的提示注入风险。
• 沙箱模式：Bash 命令可以在限制文件系统和网络访问的沙箱环境中运行。请参阅沙箱文档了解详情。

安全原则

对于需要在 Claude Code 默认设置之外进行额外加固的部署，以下原则指导可用的选项。

安全边界

安全边界将具有不同信任级别的组件分隔开来。对于高安全性部署，您可以将敏感资源（如凭证）放置在包含代理的边界之外。如果代理环境中出现问题，该边界之外的资源仍然受到保护。

例如，与其直接给代理 API 密钥的访问权限，您可以在代理环境之外运行一个代理服务器，将密钥注入请求中。代理可以进行 API 调用，但它永远看不到凭证本身。这种模式对于多租户部署或处理不可信内容时非常有用。

最小权限

在需要时，您可以将代理限制为仅具有其特定任务所需的功能：

纵深防御

对于高安全性环境，分层多重控制提供额外保护。选项包括：

• 容器隔离
• 网络限制
• 文件系统控制
• 在代理服务器处进行请求验证

正确的组合取决于您的威胁模型和运营需求。

隔离技术

不同的隔离技术在安全强度、性能和运营复杂性之间提供不同的权衡。

沙箱运行时

对于无需容器的轻量级隔离，sandbox-runtime 在操作系统级别强制执行文件系统和网络限制。

主要优势是简单性：不需要 Docker 配置、容器镜像或网络设置。代理和文件系统限制是内置的。您提供一个设置文件来指定允许的域名和路径。

工作原理：

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

设置：

npm install @anthropic-ai/sandbox-runtime

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

安全注意事项：

1. 共享主机内核：与虚拟机不同，沙箱进程共享主机内核。内核漏洞理论上可能导致逃逸。对于某些威胁模型这是可以接受的，但如果您需要内核级隔离，请使用 gVisor 或单独的虚拟机。

2. 无 TLS 检查：代理允许列表中的域名但不检查加密流量。如果代理对允许的域名拥有宽松的凭证，请确保无法使用该域名触发其他网络请求或泄露数据。

对于许多单开发者和 CI/CD 用例，sandbox-runtime 以最小的设置显著提高了安全门槛。以下部分涵盖了需要更强隔离的部署的容器和虚拟机方案。

容器

容器通过 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 套接字架构：

使用 --network none 时，容器完全没有网络接口。代理到达外部世界的唯一方式是通过挂载的 Unix 套接字，该套接字连接到主机上运行的代理服务器。此代理服务器可以强制执行域名允许列表、注入凭证并记录所有流量。

这与 sandbox-runtime 使用的架构相同。即使代理通过提示注入被攻破，它也无法将数据泄露到任意服务器——它只能通过代理服务器通信，而代理服务器控制着哪些域名是可达的。更多详情请参阅 Claude Code 沙箱博客文章。

额外加固选项：

gVisor

标准容器共享主机内核：当容器内的代码进行系统调用时，它直接到达运行主机的同一内核。这意味着内核漏洞可能允许容器逃逸。gVisor 通过在用户空间拦截系统调用来解决这个问题，在它们到达主机内核之前，实现自己的兼容层来处理大多数系统调用，而无需涉及真正的内核。

如果代理运行恶意代码（可能由于提示注入），该代码在容器中运行并可能尝试内核漏洞利用。使用 gVisor 时，攻击面要小得多：恶意代码需要首先利用 gVisor 的用户空间实现，并且对真正的内核访问有限。

要将 gVisor 与 Docker 一起使用，请安装 runsc 运行时并配置守护进程：

// /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}

然后使用以下命令运行容器：

docker run --runtime=runsc agent-image

性能注意事项：

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

虚拟机

虚拟机通过 CPU 虚拟化扩展提供硬件级隔离。每个虚拟机运行自己的内核，创建一个强大的边界——客户内核中的漏洞不会直接危及主机。然而，虚拟机并不自动比 gVisor 等替代方案"更安全"。虚拟机安全性在很大程度上取决于虚拟机管理程序和设备仿真代码。

Firecracker 专为轻量级微虚拟机隔离而设计——它可以在 125 毫秒内启动虚拟机，内存开销不到 5 MiB，去除不必要的设备仿真以减少攻击面。

使用这种方法，代理虚拟机没有外部网络接口。相反，它通过 vsock（虚拟套接字）进行通信。所有流量通过 vsock 路由到主机上的代理服务器，该代理服务器在转发请求之前强制执行允许列表并注入凭证。

云部署

对于云部署，您可以将上述任何隔离技术与云原生网络控制相结合：

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

凭证管理

代理通常需要凭证来调用 API、访问代码仓库或与云服务交互。挑战在于提供这种访问权限而不暴露凭证本身。

代理模式

推荐的方法是在代理的安全边界之外运行一个代理服务器，将凭证注入到出站请求中。代理发送不带凭证的请求，代理服务器添加凭证，然后将请求转发到目的地。

这种模式有几个好处：

1. 代理永远看不到实际的凭证
2. 代理服务器可以强制执行允许端点的列表
3. 代理服务器可以记录所有请求以供审计
4. 凭证存储在一个安全位置，而不是分发到每个代理

配置 Claude Code 使用代理

Claude Code 支持两种方法将采样请求路由到代理：

选项 1：ANTHROPIC_BASE_URL（简单但仅适用于采样 API 请求）

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

这告诉 Claude Code 和 Agent SDK 将采样请求发送到您的代理服务器而不是直接发送到 Anthropic 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 — TLS 终止代理，用于检查和修改 HTTPS 流量
• Squid — 带有访问控制列表的缓存代理
• LiteLLM — LLM 网关，带有凭证注入和速率限制

其他服务的凭证

除了从 Anthropic API 采样之外，代理通常还需要对其他服务的认证访问——git 代码仓库、数据库、内部 API。有两种主要方法：

自定义工具

通过 MCP 服务器或自定义工具提供访问，将请求路由到代理安全边界之外运行的服务。代理调用工具，但实际的认证请求发生在外部——工具调用代理服务器，由代理服务器注入凭证。

例如，一个 git MCP 服务器可以接受来自代理的命令，但将它们转发到主机上运行的 git 代理服务器，该代理服务器在联系远程仓库之前添加认证。代理永远看不到凭证。

优势：

• 无需 TLS 拦截：外部服务直接进行认证请求
• 凭证保持在外部：代理只看到工具接口，而不是底层凭证

流量转发

对于 Anthropic 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 将出站流量重定向到透明代理。

两种方法仍然需要 TLS 终止代理和受信任的 CA 证书——它们只是确保流量确实到达代理。

文件系统配置

文件系统控制决定了代理可以读取和写入哪些文件。

只读代码挂载

当代理需要分析代码但不需要修改时，以只读方式挂载目录：

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

可写位置

如果代理需要写入文件，根据您是否希望更改持久化，有几个选项：

对于容器中的临时工作区，使用仅存在于内存中且在容器停止时被清除的 tmpfs 挂载：

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

如果您想在持久化之前审查更改，overlay 文件系统允许代理在不修改底层文件的情况下写入——更改存储在一个单独的层中，您可以检查、应用或丢弃。对于完全持久化的输出，挂载一个专用卷，但将其与敏感目录分开。

延伸阅读

• Claude Code 安全文档
• 托管 Agent SDK
• 处理权限
• Sandbox runtime
• The Lethal Trifecta for AI Agents
• OWASP Top 10 for LLM Applications
• Docker Security Best Practices
• gVisor Documentation
• Firecracker Documentation