Multica 的任务能在运行机器上访问到什么安全模型与隔离边界怎么设置【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica当你把任务分配给 Multica 的智能体后执行发生在连接了守护进程daemon的那台电脑上守护进程把 AI 编程工具Codex、Claude Code 等作为子进程启动。这就带来一个必须回答的问题——这个子进程在运行机器上能碰到什么本文基于 安全模型文档 和 守护进程与运行时说明默认情况下一次运行run的实际访问范围以及如何把隔离边界设置到正确的位置并通过守护进程日志和配置块确认运行实际生效的模式。默认情况下一次运行能访问到什么核心结论只有一条边界是运行守护进程的那个操作系统用户。默认情况下每次运行拥有守护进程所属 OS 用户的全部权限该用户能读写的文件运行都能读写该用户的凭据运行都能使用网络访问不受限制。运行继承守护进程用户真实的HOME与XDG_*变量——正因如此gh、aws、kubectl、gcloud、glab等宿主 CLI 在运行内的行为与在你的 shell 里完全一致。代价是该 home 目录下的一切都可触达。Multica 不对文件系统沙箱作任何保证。目前只有一个狭窄的例外在 Windows 上显式开启 Codex 原生沙箱。哪些平台与配置组合会真正启用沙箱属于兼容性细节会随工具版本变化因此文档的建议是把每一次运行都当作无沙箱来对待。这是有意为之的设计智能体需要安装依赖、执行构建、使用你的云 CLI这些工具都假设自己面对一个正常的 home 目录。不完整的文件系统沙箱会以极难排查的方式破坏这些工作——工具报“未登录”或悄悄用错账号——同时又保护不了最要紧的东西因为它无法阻止运行读取凭据并通过网络发出去。官方文档的警告很直接Multica 不会替你做文件系统沙箱。如果守护进程跑在你的个人账号下运行可以读取你的 SSH 私钥、修改你的 shell 配置、删除你的文档。隔离必须来自你为守护进程设置的外层边界。如何把隔离边界设置到正确的位置文档给出的操作原则是Multica 不假装自己是边界请在它外面加一层。推荐部署方式按从轻到重排列选择适合你基础设施的一种专用 Unix 用户。创建一个multica用户只给它智能体需要的仓库和凭据用该用户运行守护进程。你自己的账号完全不受影响。容器。在容器里运行守护进程只挂载智能体需要的目录和密钥。虚拟机。隔离最彻底代价是要额外准备一台机器。无论选哪种凭据管理遵循同一条规则把该环境中可触达的凭据视为智能体可能会用到的凭据。具体来说——token 权限尽量收窄优先使用专用部署密钥而不是你的个人 SSH 私钥不要把无关的生产凭据留在该用户的 home 目录里。自托管快速上手 在连接执行电脑一步也重复了这个警告每次执行都拥有守护进程所属用户的全部权限——该用户能读写的一切运行都能读写。请用专用 Unix 用户、容器或虚拟机来运行守护进程而不是你的个人账号。注意边界设在哪一侧自托管场景下 Multica 服务Web、API、PostgreSQL跑在一台装了 Docker 的机器上而守护进程和 AI 编程工具跑在开发者实际工作的电脑上两者可以是同一台也可以分开。上面三种隔离方式约束的对象是运行守护进程的电脑/账号这与服务端的部署方式是两个独立的决策。Multica 自身提供的隔离是什么不是什么以下隔离是真实存在的但属于便利性与影响面收敛不是用来防御主动逃逸的安全边界每次运行独立工作目录。每个运行在~/multica_workspaces/下拥有独立 workdir根目录可用multica config set workspaces_root path或daemon start的--workspaces-root path调整并发运行不会在同一份 checkout 上冲突。每次运行独立的智能体状态。Codex 运行拥有运行级CODEX_HOME保存配置、会话与技能不会污染你的~/.codex/。运行级 API token。交给运行的MULTICA_TOKEN由服务端绑定到该智能体与该运行因此运行无法通过 Multica API 以你或其他智能体的身份行事。临时 token 的完整规则见 认证与令牌守护进程领取运行后服务器为这次执行创建以mat_开头的临时令牌它绑定当前用户、工作区、智能体和运行最长有效 24 小时并在运行结束时清理。守护进程注入的是这个临时令牌而不是你的用户 PAT——所以智能体发出的请求会记录为智能体行为也不能借此调用只允许用户或 owner 执行的敏感操作。以下两项不构成边界配置时要心里有数编程工具自带的沙箱与审批设置。Multica 以无人值守方式运行智能体审批请求会被自动应答。默认路径下文件系统沙箱同样处于关闭状态Codex 使用sandbox_mode danger-full-accessClaude Code 使用--permission-mode bypassPermissions。例外是 Windows——如果你显式配置了 Codex 原生沙箱windows.sandbox unelevated或elevatedMultica 会尊重这个 opt-in对这些运行保留workspace-write。文档明确它“只覆盖一个平台上的一个工具”不改变你应当如何收窄守护进程用户的权限。你的HOME目录结构。见上一节运行继承真实的HOME和XDG_*变量home 下的一切都可达。另有一个历史变更值得知道在 Linux 上Codex 过去曾在workspace-write沙箱下运行并使用为每次运行重定向的HOME。该机制已被移除——它让宿主 CLI 在运行内处于未配置状态而且由于只限制写入从未能阻止运行读取并外传凭据。现在 Linux 与 macOS、Windows 的默认行为一致。还有一条与“本地执行”直觉相抵触的边界智能体的自定义环境变量custom_env和 MCP 配置保存在服务器侧执行时发送给运行时。不要把“本地执行”理解为所有 secret 都只存在本机不希望离开你电脑的 secret不要写进custom_env。如何确认运行实际以什么模式运行设置完外层边界后有两个检查手段可以确认运行实际生效的沙箱模式都来自 安全模型文档。1. 查看守护进程日志。运行以无沙箱方式启动时守护进程会记录 warn 级日志multica daemon logs --lines 200 | grep codex sandbox该命令只读取最近 200 行日志并过滤包含codex sandbox的行不会修改任何状态。2. 读取运行写入的 Codex 托管配置块。要确认 Codex 的实际生效配置查看该运行CODEX_HOME下config.toml中的托管块——# BEGIN multica-managed与# END multica-managed标记之间的内容由守护进程在每次运行时写入。这个块是守护进程写出的生效策略比凭记忆推断更可靠。如果需要整体确认守护进程与运行时的连接状态用multica daemon status查看守护进程和连接情况工具刚安装或路径刚修改后运行multica daemon restart重新检测。边界与限制文档中的隔离手段独立 workdir、运行级CODEX_HOME、mat_临时令牌只能理解为爆炸半径收敛它们防止并发运行互相污染、防止运行冒用你或其他智能体的 Multica 身份但不阻止运行以守护进程用户的身份读取本机文件并外传。不要把编程工具侧的审批或沙箱设置当作防线——审批会被自动应答文件系统沙箱默认关闭。Windows 上 Codex 原生沙箱是当前唯一的沙箱例外且属于“适用场景下值得开启”的可选项不能替代对守护进程用户权限的收窄。运行时进程的环境变量包括MULTICA_TOKEN会被其启动的子进程默认继承如果某个子进程不应持有该凭据必须显式移除不要假定进程之间存在并没有的隔离。完成外层边界设置后判断标准是守护进程以专用低权限用户或容器/VM运行该用户的 home 中只存在智能体确实需要的仓库与凭据daemon logs与CODEX_HOME/config.toml托管块显示的沙箱模式与你预期一致。此时一次运行能碰到的范围就被限定在了你为它划定的这个用户/环境之内——这也是 安全模型文档 给出的最终要求把每一次运行当作无沙箱来对待把边界放在守护进程之外。【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考