---
title: 'Multica Runtime 到底拦了什么：一次危险操作会经过哪些边界？'
description: 'Multica 的 runtime 负责调度与身份隔离，不是通用的操作系统安全沙箱。本文结合一次受控实测与官方资料，拆开危险操作实际会经过的流程、能被拦住的地方，以及真正的安全边界。'
pubDate: 2026-08-12
slug: multica-runtime-security-boundary
tags: ['Multica', 'Codex', 'Agent', '安全']
lang: zh-CN
draft: false
---

我一开始问的问题很直接：如果我通过 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](https://multica.ai/docs/security-model)

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

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

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

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

```mermaid
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](https://multica.ai/docs/tasks) 任务的触发源可以是指派、评论提及、聊天或自动化；一次提及不是普通通知，而是一次新的执行触发。[Agents](https://multica.ai/docs/agents)

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

## 真正被隔离的是什么

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

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

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

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

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

| 请求                        | 主要经过的控制                                | 不能据此推断的事                   |
| --------------------------- | --------------------------------------------- | ---------------------------------- |
| “修改 Issue 状态、添加评论” | 任务 token、Agent/工作区权限、服务端 API 校验 | 不代表本机文件也被限制             |
| “删除仓库中的文件”          | OS 用户权限、Codex/工具的 sandbox 与审批配置  | 不代表 Multica 平台 API 会允许越权 |
| “调用 `aws` 或 `kubectl`”   | OS 用户可用凭据、网络与云 IAM                 | 不代表任务级 token 具有云权限      |
| “联网检索或下载依赖”        | Provider 能力、宿主网络策略和工具配置         | 不代表所有运行时都有相同网络策略   |

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

以下内容来自一次受控实测。为避免动到机器原有文件，测试只在 `/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](https://learn.chatgpt.com/docs/cloud/internet-access)

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

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

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

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

```mermaid
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](https://multica.ai/docs/security-model)

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

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

## 最后的判断

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

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

## 参考资料

- [Multica Security model](https://multica.ai/docs/security-model)
- [Multica Tasks](https://multica.ai/docs/tasks)
- [Multica Agents](https://multica.ai/docs/agents)
- [How Multica works](https://multica.ai/docs/how-multica-works)
- [OpenAI — Agent internet access](https://learn.chatgpt.com/docs/cloud/internet-access)