Multica Runtime 到底拦了什么：一次危险操作会经过哪些边界？

我一开始问的问题很直接：如果我通过 Multica 让 Agent 做一件危险的事，它会在哪一步被拦下来？

答案比“会”或“不会”复杂，但也更有用：**Multica Runtime 不是一个拦截所有 shell 命令的安全沙箱。**它主要负责把任务送到一台已连接的机器、以任务身份调用本地 AI 编程工具，并把结果带回 Issue。真正能否读文件、起进程、访问网络、调用云 CLI，主要仍由运行 daemon 的操作系统用户和所选工具配置决定。

这不是一个缺点的委婉说法，而是部署 Agent 时最重要的威胁建模前提。把这条边界看清楚，才知道哪些控制已经生效，哪些必须自己补上。

#先给结论：安全控制分成两类

第一类是 Multica 明确提供的平台与任务边界：谁能运行 Agent、任务如何排队、任务通过哪个 runtime 执行、任务调用 Multica API 时以什么身份出现。这些控制对“越权操作工作区”和“不同任务互相冒充”很关键。

第二类是宿主机边界：文件、进程、网络、HOME 下已有的凭据，以及 gh、aws、kubectl 之类宿主 CLI 的能力。这里不能默认有 Multica 的通用拦截。官方安全模型写得很直白：默认情况下，任务拥有运行 daemon 的 OS 用户所拥有的权限；应将隔离放在 daemon 外部，而不是把 Multica 当作文件系统沙箱。Multica Security model

所以，“危险操作会不会被拦住”要先改写成一个更准确的问题：它走的是 Multica API，还是本地工具链？运行时所在的 OS 用户本来又拥有什么权限？

#一条任务是怎样落到本机上的

以 Issue 指派或评论中的 @Agent 为例，流程可以概括为：

图 1：从任务触发到结果回写的本地执行链路

flowchart LR
  S([开始：Issue 或评论触发]) --> A[服务端创建任务]
  A --> B[在线 runtime 认领]
  B --> C[daemon 创建工作目录]
  C --> D[AI 工具执行]
  D --> E[结果写回 Issue]
  E --> F([结束：记录执行结果])

任务是在连接的机器上执行；服务端负责记录、调度和回写，而不直接代替本机执行命令。

这不是推测。Multica 的公开文档把任务状态列为 queued、dispatched、waiting_local_directory、running、completed、failed 与 cancelled，并说明 runtime 认领任务后调用 Agent 配置所绑定的本地 AI 编程工具。Tasks 任务的触发源可以是指派、评论提及、聊天或自动化；一次提及不是普通通知，而是一次新的执行触发。Agents

这里第一个可见的阻拦点是平台授权：Agent 的 Access 配置决定哪些成员可以触发该 Agent；工作区成员、管理员与 Agent owner 的权限不同。它不限制 Agent 已经运行后能访问哪些资源或命令；后者由 daemon 用户、宿主机和工具配置决定。第二个是runtime 可用性：没有匹配的在线 runtime，任务只能等待或失败，而不会凭空在 Multica 服务端执行。Multica 的工作模型是“服务端协调，连接的计算机执行”；本地 AI 工具的凭据和实际命令执行留在连接的机器上。How Multica works

#真正被隔离的是什么

在任务内部，Multica 确实做了几件很有价值的隔离工作：

• 每个任务有独立工作目录，减少并发任务碰撞；
• Codex 任务有任务级 CODEX_HOME，使配置、会话和 skills 不污染用户的 ~/.codex/；
• 注入给任务的 MULTICA_TOKEN 绑定到特定 Agent 与特定任务，不能通过 Multica API 直接冒充人或其他 Agent。

这些是“任务身份”和“协作面”的隔离，而不是对恶意进程的安全封装。换言之，任务 token 的范围收窄了，并不自动收窄同一个进程可读的本地文件、环境变量或第三方 CLI 凭据。Multica Security model

这也是为什么一个看起来无害的动作，要区分两条路径：

表 1：不同操作所经过的主要控制；用于区分平台任务身份与宿主机权限，不表示所有部署的固定能力

#我们实测到的边界：临时目录、系统信息与网络

以下内容来自一次受控实测。为避免动到机器原有文件，测试只在 /tmp 下创建随机的新目录，在其中完成“新建—读取—修改—删除”，随后确认测试文件和目录均不存在。四步都成功。

这能证明的只有一件事：当前受管 runtime 允许 Agent 在可写临时路径执行常规文件系统操作，没有对这类通用生命周期做额外阻断。它不能证明任何其他路径也可写，更不能证明所有 Multica 部署的配置相同。

同样，我们以只读方式查询了当前进程与可见系统进程数量、PID 1 的 RSS 元数据，以及机器级内存统计；命令成功。这说明当前环境可以看到一定范围的进程元数据和内存统计。它不等于“能读取其他进程的内存内容”——后者通常需要额外的调试/附加权限，且受操作系统安全机制约束，本次没有尝试。

联网也应作相同区分：相关受管会话曾成功调用 Web 工具，因此能够完成必要的公开资料核验；这不是“Multica 为所有 runtime 开启了网页搜索”的产品承诺。Provider、部署与网络策略都会改变结果。尤其不要把 Codex Cloud 的默认设置外推到本地 daemon：Codex Cloud 的 agent phase 默认关闭互联网，可按环境开启并限制域名与 HTTP 方法；本地 Multica runtime 则运行在用户自己的机器和网络中。OpenAI: Agent internet access

#为什么“自动审批”值得被当成高风险配置

Multica 的价值是让任务无人值守地跑完，因此它不会把每一条本地命令都变成人工确认对话。官方安全模型说明：默认路径下，Codex 以 danger-full-access 运行，Claude Code 使用绕过权限的模式；Windows 上若显式启用 Codex 原生 sandbox，Multica 会保留该 opt-in。即使某个工具层的 sandbox 开启了，也不应把它误认作完整的隔离边界。Multica Security model

换句话说，前半段通常是 Multica 的调度与授权，后半段是机器自己的安全模型：

图 2：危险操作从平台授权进入宿主机权限边界

flowchart LR
  S([开始：请求发起]) --> A[工作区与 Agent 触发授权]
  A --> B[runtime 认领任务]
  B --> C[任务 token 调用 Multica API]
  C --> D[本地 AI 工具执行命令]
  D --> E[OS 权限、凭据、网络与云 IAM]
  E --> F([结束：产生实际影响])

图中的分界点在本地工具执行之后：任务 token 约束的是 Multica API 身份，不能替代 OS、网络或云端权限控制。

若危险动作发生在最后一段，例如 rm、git push --force、aws s3 rm、向外部地址提交内容，不能期待“它来自 Multica”本身成为阻断理由。应该让这件事在更靠外的一层根本做不成。

#可操作的部署建议：把边界放到 daemon 外面

最轻量的做法是使用专用 OS 账号运行 daemon：只授予它所需仓库、最小范围的 deploy key 与云凭据，个人 SSH key、浏览器 profile 和生产管理员凭据不要放在该账号下。更强的选择是容器；要求更高时使用 VM。三种建议与 Multica 官方安全模型一致。Multica Security model

我会再补四条工程上常用的控制：

1. 让云权限最小化。为 Agent 使用单用途、可轮换的短期凭据，不复用个人管理员凭据。
2. 把网络单独收口。默认不出网或只允许必要域名；若可配置方法，优先只放行 GET、HEAD、OPTIONS。OpenAI 也明确把 prompt injection、密钥外传、恶意依赖与许可证风险列为 Agent 出网的主要风险。OpenAI: Agent internet access
3. 将发布、部署、删除生产资源放在独立审批链中。代码变更可以自动化，外部不可逆动作应由 CI、分支保护、云策略或人工批准门控制。
4. 审计实际生效的配置，而不是只看“我们开了 sandbox”。Multica 建议从 daemon log 与任务 CODEX_HOME 下的受管 config.toml 确认有效 sandbox 模式。Multica Security model

#最后的判断

Multica Runtime 擅长解决“谁在什么 runtime 上、为了哪条任务、以哪个任务身份执行”的问题；它不替你解决“这台机器上的这个用户应该被信任到什么程度”。

因此，正确的默认心智模型不是“危险命令会不会被 Multica 拦截”，而是：**将每一个 Multica task 当成 daemon OS 用户在执行自动化工作。**平台权限、任务级 token、独立 workdir 都很重要，但它们服务于协作隔离与降低误操作半径；真正的系统安全边界，应由专用身份、容器或 VM、最小权限凭据、网络策略和外部审批共同构成。

#参考资料

• Multica Security model
• Multica Tasks
• Multica Agents
• How Multica works
• OpenAI — Agent internet access