AgentSpace 安全架构解析:沙箱隔离、Provider 策略层与多 Agent 硬隔离的完整设计指南

发布时间:2026/10/16 18:25:19
AgentSpace 安全架构解析:沙箱隔离、Provider 策略层与多 Agent 硬隔离的完整设计指南 人工智能AI AgentAgent 编排后端前端任务调度认证鉴权【免费下载链接】AgentSpaceAgentSpace: Human Agents. One Team. One Workspace项目地址https://gitcode.com/gh_mirrors/ag/AgentSpace点击查看免费下载AgentSpace 是一个人类 Agent 同队协作的工作空间Human Agents. One Team. One Workspace。当多个 AI Agent 在同一工作区里读写文件、执行命令、调用外部系统时安全就成了第一命题。本文带你从源码层面拆解 AgentSpace 的三层安全设计Sandbox 沙箱隔离、Provider 策略层Policies、以及多 Agent 硬隔离机制看看它如何做到能力给够、风险管住。一、为什么 Agent 安全需要分层隔离 普通应用的安全边界是用户接口而 Agent 系统多了一个更危险的边界——Agent 本身会执行代码、访问文件系统、发送外部消息。一旦某个 Agent 被恶意提示词诱导prompt injection它可能越权删文件、外发数据。AgentSpace 的应对思路是把防线拆成三层每层解决一类问题防线位置解决的问题Sandbox 沙箱packages/sandbox/Agent 执行代码时出不去、玩不坏策略层 Policiespackages/services/src/policies/哪些动作要审批、哪些数据算不可信多 Agent 硬隔离packages/daemon/src/agent-router/不同 Agent 互不串门、资源按授权分配二、第一层Sandbox 沙箱隔离 2.1 统一的 Sandbox 接口沙箱模块 packages/sandbox/src/interface.ts 定义了一个极简的Sandbox接口读文件、写文件、列目录、执行命令、打快照、停止、销毁。上层业务只依赖这个接口不关心底层是本地目录还是云端容器——这是典型的可替换隔离后端设计。入口工厂 packages/sandbox/src/factory.ts 根据配置把请求路由到两种 Provider 之一connectSandbox() ├─ provider cube → CubeSandbox云端强隔离实验特性 └─ provider local → LocalSandbox本地目录沙箱默认2.2 LocalSandbox路径围栏 命令超时默认的本地沙箱 packages/sandbox/src/local/local-sandbox.ts 有两条核心防线路径围栏所有文件操作都经过resolveInsideSandbox校验任何试图以../逃逸出工作目录的路径会直接抛出Path xxx escapes sandbox root.错误。Agent 的文件系统视野被限制在一个笼子内。命令生命周期管控exec启动子进程后统一跟踪超时先SIGTERM优雅终止宽限 5 秒后再SIGKILL强杀见 local-sandbox.ts任务级超时默认 12 小时可通过AGENT_SPACE_TASK_TIMEOUT_MS环境变量调整types.ts。此外沙箱支持snapshot()对工作内容打快照、destroy()彻底销毁工作目录让每次 Agent 运行都是一次性房间。2.3 CubeSandbox云级强隔离与网络策略需要更强隔离时可切换到 CubeSandbox。它是实验特性必须显式设置AGENT_SPACE_CUBE_ENABLE_EXPERIMENTALtrue才能启用避免误用cube-config.ts。配置上亮点是出站网络策略AGENT_SPACE_CUBE_ALLOW_OUT/AGENT_SPACE_CUBE_DENY_OUT出站域名白名单与黑名单cube-config.ts可选把宿主工作目录挂载进沙箱的/workspace其余环境完全由云端模板提供超时、API 请求超时默认 30 秒全部有硬上限也就是说Agent 在 Cube 沙箱里跑任务时能访问哪些网络资源是由策略显式授予的而不是默认全通。三、第二层Provider 策略层Policies⚖️策略层回答的不是能不能执行而是该不该放行、要不要人审。核心实现在 packages/services/src/policies/agent-actions.ts。3.1 动作策略allow / require_approval / deny 三态决策每个 Agent 动作发帖、写文档、发外部消息、调用技能等都会进入decideAgentActionPolicySync产出一个带reasonCode和审计数据的决策。内置动作清单包括runtime.use、message.post、external_message.send、document.read/write、file.delete、skill.invoke等agent-actions.ts。默认规则非常克制外部文档写入一律require_approval需要channel_manager角色审批发送外部消息低风险且 Provider 绑定校验通过后放行否则要求channel_manager审批高风险动作riskLevel high必须admin审批其他动作默认放行但全程记录审计数据workspace、actor、任务、资源、payloadHash 等这套默认放行 高危审批 全程审计的组合比一刀切的全审批对协作效率更友好同时把最危险的出口动作往外写、往外发全部拦在审批闸门前。3.2 数据策略外部内容一律不可信标签外部渠道如 IM进来的消息属于不可信输入。workspace-data.ts 的策略是外部消息必须显式标注trust untrusted_user_message否则直接deny标注后分类为external_untrusted_user_content允许作为普通用户内容存储、检索、进入 Agent 上下文但永远带来源标签Agent 消费时知道它是外部用户说的话而非系统指令这是对抗 prompt injection 的数据面防线源头标记 用途白名单storeInWorkspace / includeInSearch / includeInAgentContext。四、第三层多 Agent 硬隔离 4.1 每个 Agent × 频道都有独立工作目录多 Agent 协作最怕串文件。AgentSpace 在 conversation-execution-workspaces.ts 中为每个频道 Agent组合生成唯一 keygroup:频道名:agentId并映射到独立目录workdirs/channels/频道/Agent路径规则见 storage-paths.ts。这意味着同一个频道里的两个 Agent、同一个 Agent 在两个频道里各自拥有完全隔离的文件空间与运行状态——文件系统层面天然硬隔离不依赖任何君子协定。4.2 AgentRouterProvider 适配器 子进程围栏packages/daemon/src/agent-router/ 把 Claude Code、Codex、OpenCode、Hermes 等多种 CLI 型 Agent Provider 统一抽象为HarnessAdapter清单见 types.ts。每次运行都是一个受控子进程能力白名单RuntimeToolCapability声明每个工具允许的 shell 模式allowedShellPatterns被标记denied的工具会被直接转为诊断错误harness.tool_unauthorized而不是静默失败capabilities.ts。以 Claude 适配器为例工具白名单会被拼进--allowedTools参数下发claude.ts。环境变量最小化只注入允许工具所需的env与PATH目录denied 工具的环境变量一律不带capabilities.ts。密钥脱敏启动计划携带redactions规则stdout/stderr 流经redactText过滤防止 API Key 等机密被打进日志subprocess.ts。超时与诊断超时统一 SIGTERM → SIGKILL所有失败都归一化为结构化AgentRouterDiagnostic如harness.cli_missing、harness.timeout故障可观测、可归因。4.3 Runtime 授权谁能驱动哪个 Agent 运行时隔离的不只是 Agent 之间还有人 × Runtime的授权面。runtime-access.ts 实现了运行时授权模型仅 workspace 的 owner/admin 可授予或吊销 Runtime 使用权限runtime-access.ts普通用户只能使用被授予的 RuntimeAgent 绑定 Runtime 后用户还需同时通过员工可见性 频道可见性 Runtime 授权三重检查才能触发它每次授权/吊销都写入审计事件并推送通知五、总结一张图看懂 AgentSpace 的三道防线 外部消息 ──▶ 数据策略(不可信标签) ──▶ 动作策略(审批闸) │ ▼ 独立工作目录(频道×Agent) ◀── AgentRouter(白名单/脱敏/超时) │ ▼ Sandbox(路径围栏/网络策略/快照销毁)数据进来先打标外部内容永远带着不可信身份进入工作区动作出去先过闸高风险与外发动作强制人工审批全程审计执行环境先圈住独立目录 沙箱围栏 工具白名单让每个 Agent 只在自己的房间里干被授权的事。对想搭建多 Agent 协作系统的团队来说这套沙箱隔离 策略层 硬隔离的分层思路比单纯堆权限点更值得借鉴。感兴趣可以继续阅读源码沙箱模块 packages/sandbox/src/factory.ts、策略层 packages/services/src/policies/、运行时路由 packages/daemon/src/agent-router/。赞分享人工智能AI AgentAgent 编排后端前端任务调度认证鉴权【免费下载链接】AgentSpaceAgentSpace: Human Agents. One Team. One Workspace项目地址https://gitcode.com/gh_mirrors/ag/AgentSpace点击查看免费下载相关推荐Ladybird安全架构沙箱与进程隔离机制Ladybird安全架构沙箱与进程隔离机制 Ladybird浏览器采用了先进的多进程架构和沙箱技术来实现严格的安全隔离。该架构通过将浏览器功能划分为多个独立的前端WebAssembly音视频插件隔离策略lazy.nvim沙箱环境与安全边界插件隔离策略lazy.nvim沙箱环境与安全边界 引言现代Neovim插件管理的安全挑战 在Neovim生态系统中插件管理器的安全性一直是开发者关注的核心开发工具包管理器Potpie 沙箱核心设计RepoCache、Workspace 与 Runtime 三层解耦的隔离执行架构Potpie 沙箱核心设计RepoCache、Workspace 与 Runtime 三层解耦的隔离执行架构 本文围绕 Potpie 的沙箱核心设计文档 sa人工智能AI Agent代码智能体知识图谱开发工具CLI后端创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询