1. 多 Agent 系统里隔离模型到底在隔离什么如果你正在搭一套多 Agent 系统大概率已经遇到过这个场景一个负责检索的 Agent 抓回来一段网页内容另一个负责执行的 Agent 拿着这段内容去调工具结果工具调用参数里混进了不该出现的东西。问题不在于模型笨而在于你把两个本该待在不同信任域里的角色塞进了同一个 sandbox。AI Agent 的隔离模型说白了就是回答三个问题代码在哪跑、控制循环在哪跑、凭证存在哪。这三个问题的答案组合起来决定了你的安全边界画在哪。sandbox 本身只是手段信任域才是目的。一个 sandbox 如果和 Agent 的决策循环共享同一个信任域那它防的是横向移动防不了纵向劫持——攻击者不需要逃出 sandbox他只需要让 sandbox 里的 Agent 自己做出错误决策。这篇面向的是已经在写多 Agent 编排、准备把 sandbox 和信任域设计落地的开发者。我会用 TaoToken 作为统一 Key 和 API 通道把跨信任域调用的配置骨架写出来包括 config.toml 和 settings.json 两份可复制文件再演示一次跨信任域调用的验证动作。TaoToken 在这里的角色不是替代你的 sandbox而是让不同信任域里的 Agent 用同一套凭证体系访问模型同时把 Key 的暴露面收敛到一个可控的通道上。先说清楚一个前提统一 Key 不等于统一信任域。很多团队为了省事把所有 Agent 的模型调用都指向同一个 Key结果一个低信任域的 Agent 被注入后拿到的 Key 能访问高信任域才能用的模型和额度。TaoToken 的 API 通道可以让你在同一个账号下管理多个 Key按信任域拆分这才是正确的用法。官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 不带任何跟踪参数。2. 用 TaoToken 统一 Key 打通 sandbox 信任域的前置准备在写配置之前先把信任域划分清楚。我的做法是按 Agent 的能力边界分三层第一层是只读检索域Agent 只能访问公开数据源不能调任何写操作工具模型调用只需要基础对话能力。第二层是受控执行域Agent 可以调工具但工具清单是白名单模型调用需要更强的推理能力。第三层是高权限域只有经过人工确认的流程才能进入模型调用和工具调用都要留审计日志。这三层对应三个不同的 TaoToken Key。你可以在控制台的 API Keys 页面创建每个 Key 绑定不同的权限范围。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建 Key 的时候注意两点一是给每个 Key 起一个能看出信任域的名字比如agent-readonly、agent-exec、agent-privileged后面排查问题时能省很多时间二是把额度上限设好低信任域的 Key 即使泄露损失也可控。拿到 Key 之后不要直接写进代码。我的做法是写进环境变量配置文件里只引用变量名。这样 sandbox 里的进程即使被读取了配置文件也拿不到真实 Key。如果你用的是容器化 sandbox把 Key 通过 secret 挂载不要走镜像层。TaoToken 的 API 通道兼容 OpenAI 风格的请求格式所以你的 Agent 框架如果已经支持自定义 base_url改一个地址就能接上。base_url 填https://taotoken.net/api注意这里不加任何 UTM 参数保持接口地址干净。3. 可复制的 config.toml 与 settings.json 配置骨架下面这份 config.toml 是我在一个多 Agent 项目里实际用过的骨架按信任域拆了三个 profile。你可以直接复制把 Key 的环境变量名换成自己的。# config.toml - 多信任域 Agent 配置骨架 [default] # 默认走只读域任何未显式指定信任域的调用都降级到这里 profile readonly request_timeout 30 max_retries 2 [profiles.readonly] # 只读检索域只能访问公开数据不能调写操作工具 base_url https://taotoken.net/api api_key_env TAOTOKEN_KEY_READONLY model claude-3-5-sonnet allowed_tools [web_search, read_file] sandbox firecracker trust_domain readonly audit_log true [profiles.exec] # 受控执行域工具白名单需要推理能力 base_url https://taotoken.net/api api_key_env TAOTOKEN_KEY_EXEC model claude-3-5-sonnet allowed_tools [web_search, read_file, write_file, run_shell] sandbox firecracker trust_domain exec audit_log true require_approval [run_shell] [profiles.privileged] # 高权限域人工确认后才能进入 base_url https://taotoken.net/api api_key_env TAOTOKEN_KEY_PRIVILEGED model claude-3-5-sonnet allowed_tools [*] sandbox firecracker trust_domain privileged audit_log true require_approval [*]这份配置的关键在于trust_domain字段。你的编排层在派发任务时根据任务来源决定用哪个 profile。来自不可信网页的内容只能进 readonly来自内部工单系统的指令可以进 exec涉及删除、转账这类操作必须走 privileged 并且人工确认。settings.json 是给 Agent 运行时用的控制 sandbox 内部的行为。这份文件放在 sandbox 的挂载目录里不要和 config.toml 放一起。{ sandbox: { type: firecracker, network: { egress: allowlist, allowlist: [ taotoken.net ], deny_private_ranges: true }, filesystem: { readonly: [/usr, /lib], writable: [/workspace], deny_paths: [/proc/self/root, /proc/1/root] }, process: { run_as_uid: 10001, no_new_privs: true, seccomp_profile: agent-default } }, agent: { control_loop: host, credential_store: host, max_tool_calls_per_turn: 8, inject_guard: { enabled: true, untrusted_sources: [web_search, read_file], action: strip_instructions } }, audit: { sink: stdout, include_prompt: false, include_tool_args: true } }这里有两个设计点值得展开。第一control_loop设为host意思是 Agent 的决策循环跑在 sandbox 外面sandbox 里只跑工具执行。这样即使 sandbox 里的代码被注入攻击者够不到决策循环。第二credential_store也设为hostKey 不进 sandboxsandbox 里的进程通过宿主机的代理访问模型。这两条合起来就是前面说的不共享信任域。inject_guard是我加的一层防护。来自web_search和read_file的内容在进入模型上下文之前先做一次指令剥离。这不是万能的但能挡住大部分低成本的 prompt injection。注意deny_paths里我显式禁了/proc/self/root和/proc/1/root这是为了防止通过 proc 文件系统绕过文件系统白名单。4. 验证一次跨信任域调用配置写完了得验证它真的按预期工作。我设计了一个三步验证动作你可以照着跑一遍。第一步确认只读域的 Key 调不动写操作工具。用一个最小的 Python 脚本模拟 readonly profile 发起一次工具调用请求import os import requests BASE_URL https://taotoken.net/api KEY os.environ[TAOTOKEN_KEY_READONLY] headers { Authorization: fBearer {KEY}, Content-Type: application/json, } payload { model: claude-3-5-sonnet, messages: [ {role: user, content: 调用 write_file 工具写入 /workspace/test.txt} ], tools: [ { name: write_file, description: 写入文件, input_schema: { type: object, properties: { path: {type: string}, content: {type: string}, }, }, } ], } resp requests.post(f{BASE_URL}/v1/messages, headersheaders, jsonpayload, timeout30) print(resp.status_code) print(resp.json())预期结果是模型返回一个工具调用请求但你的编排层在收到这个请求后会对照 config.toml 里的allowed_tools做一次校验发现write_file不在 readonly 的白名单里直接拒绝执行。这一步验证的是信任域的能力边界。第二步确认跨域调用时 Key 不会串。用 exec profile 的 Key 发起同样的请求这次write_file在白名单里应该能正常执行。然后在审计日志里检查这次调用的trust_domain字段是不是exec用的 Key 是不是TAOTOKEN_KEY_EXEC。这一步验证的是信任域的凭证隔离。第三步确认 sandbox 的出站流量被限制。在 sandbox 里跑一条 curl尝试访问一个不在 allowlist 里的地址curl -v --max-time 5 https://example.com预期结果是连接被拒绝或超时。然后再访问 allowlist 里的地址curl -v --max-time 5 https://taotoken.net/api预期结果是能建立连接。这一步验证的是信任域的网络边界。三步都通过说明你的隔离模型基本落地了。如果某一步不符合预期往下看排查部分。5. 本篇常见错排查报错一401 Unauthorized但 Key 明明是对的。先检查环境变量有没有被 sandbox 的启动脚本覆盖。我遇到过一种情况sandbox 镜像里预置了一个空的TAOTOKEN_KEY_EXEC启动时把宿主机的值覆盖了。排查方法是进 sandbox 执行env | grep TAOTOKEN看值是不是空的。修复方式是在启动脚本里显式 unset 掉镜像里的占位变量。报错二工具调用被拒绝但工具名在白名单里。检查allowed_tools的匹配逻辑是不是大小写敏感。有些框架的工具名是WriteFile配置里写的是write_file匹配不上。另外检查 profile 有没有被正确加载可以在编排层加一行日志打印当前生效的 profile 名。报错三sandbox 里访问taotoken.net超时。检查settings.json里的allowlist有没有包含taotoken.net注意不要写成api.taotoken.net或者带路径的形式allowlist 匹配的是域名。另外检查deny_private_ranges有没有误伤如果你的 DNS 解析把taotoken.net解析到了内网地址会被这条规则拦掉。报错四审计日志里看不到trust_domain字段。检查audit_log是不是设成了true以及日志 sink 有没有正确配置。有些框架的审计日志是异步写的进程退出太快会丢日志加一个 flush 或者优雅退出。报错五prompt injection 还是穿透了。inject_guard只能挡低成本的注入如果攻击者用的是多轮诱导或者编码混淆还是会穿透。这时候要靠信任域隔离兜底即使模型被诱导它也只能在 readonly 域里调只读工具造成不了实际损害。如果你的 readonly 域里还有写操作工具那就是配置问题回去检查allowed_tools。6. 统一 Key 之后下一步该做什么把信任域拆开、Key 分开、sandbox 边界画清楚之后你会发现一个额外的好处审计变得简单了。每个信任域的调用日志是独立的出问题的时候能快速定位是哪个域、哪个 Key、哪次调用。这比所有 Agent 共用一个 Key 要清晰得多。如果你还在用单一 Key 跑所有 Agent建议先从只读域和受控执行域拆起这两个域的边界最清晰改动成本也最低。高权限域可以最后拆但一定要加人工确认。TaoToken 的模型对话入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 你可以用它快速验证不同 Key 的权限范围。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的 API 参数说明。如果你的团队在做长期编码类 Agent需要更稳定的额度和并发可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。Claude Code 相关的接入配置在 https://taotoken.net/claude-code?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。最后留一个我踩过的坑不要为了让 Agent 更聪明而给它跨信任域的权限。我见过一个项目为了让检索 Agent 能直接修复它发现的问题把写权限开给了只读域结果一次注入攻击直接改了生产配置。信任域的边界一旦模糊sandbox 就只是个摆设。