mcpField
I
ironclaw

ironclaw

本地服务
ironclaw.sh开发工具195 天前更新

关于 ironclaw

IronClaw 是可自托管的 AI Agent 运行环境,重点在于将 Agent 放入隔离沙箱,并通过人工审批控制能力变更。它还提供用于评估容器隔离状况的命令行工具。

主要功能

  1. 01以 gVisor 隔离 Agent 沙箱
  2. 02限制沙箱网络访问
  3. 03人工审批能力变更
  4. 04加密会话消息队列
  5. 05评估容器与 Dockerfile 隔离

适用场景

  1. 01在受控环境运行不可信 Agent
  2. 02审查 Agent 配置或能力变更
  3. 03检查容器或 Dockerfile 的隔离状况
  4. 04在 CI 中评估沙箱安全性

配置

本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置
{
"mcpServers": {
"ironsecco-ironclaw": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"IRONCLAW_CONTROLPLANE_URL",
"-e",
"IRONCLAW_API_TOKEN",
"ghcr.io/ironsecco/ironclaw-mcp:v0.1.557"
],
"env": {
"IRONCLAW_CONTROLPLANE_URL": "<IRONCLAW_CONTROLPLANE_URL>",
"IRONCLAW_API_TOKEN": "<IRONCLAW_API_TOKEN>"
}
}
}
}
启动命令docker run -i --rm -e IRONCLAW_CONTROLPLANE_URL -e IRONCLAW_API_TOKEN ghcr.io/ironsecco/ironclaw-mcp:v0.1.557
需要配置的环境变量
IRONCLAW_CONTROLPLANE_URLBase URL of your running IronClaw control-plane, e.g. http://127.0.0.1:8787. This image is a thin client with no host privilege: it delegates every sandbox_exec run to the control-plane, which owns the hardened gVisor launch. Unset means no backend and the tool fails closed.
IRONCLAW_API_TOKEN密钥Bearer token for the control-plane API (the value the control-plane was started with).

本地服务需要在你的电脑上安装运行环境(如 Node.js 18+)。各客户端的配置文件位置不同,请参考客户端文档。

安装包
ocighcr.io/ironsecco/ironclaw-mcp:v0.1.557

工具

还没有获取到工具列表

本地服务需要在你的电脑上运行后才能读取工具,维护者暂未提供工具列表。

详细介绍

IronClaw
无需信任的可自托管 AI Agent。

每个 Agent 都在密封的沙箱中运行,并能以可验证的方式确保其无法向外通信、读取宿主机或改写自身规则。

OpenSSF Scorecard OpenSSF Best Practices CodeQL Signed releases (cosign) SBOM: SPDX + CycloneDX SLSA provenance GitHub Marketplace: IronClaw sandbox scan Sandbox scan: PR scorecard Sandbox Isolation Score

Documentation Status: alpha Latest release Go Reference License: AGPLv3 + Commercial GitHub Discussions Good first issues GitHub stars

IronClaw 可在你掌控的基础设施上运行自主 AI Agent,并通过你日常使用的聊天应用与它们交互。每个 Agent 都能像任何助手一样读取、写入、安排任务并回复,但它运行在设有 network=none 的密封沙箱中:它只能通过宿主代理访问模型,并且**无法更改自身配置。**它适合任何希望使用 Agent 功能、又不愿将机器的控制权交给自主程序的人。

现已登陆 GitHub Marketplace。ironctl scan 隔离性评估工具现以 GitHub Action 的形式提供:只需在工作流中添加一行, 每个拉取请求都会获得一份 0 到 100 分的沙箱隔离评分卡,并以置顶评论的形式发布。本地运行、只读且无需凭据。

# .github/workflows/scan.yml
- uses: IronSecCo/ironclaw@v1
  with:
    target: my-container   # 容器、compose 服务或 k8s 清单

默认仅生成报告;设置 min-score: 90 即可阻止合并。参见 在 CI 中扫描。

实时隔离演示:一条命令启动真正的按会话隔离沙箱,随后一个完全越狱的 Agent 在沙箱内尝试三种逃逸方式,全部被阻止。由于 network=none 仅保留环回接口且 DNS 解析失败,向攻击者外传数据会被拒绝;由于主机根目录位于沙箱挂载命名空间之外,读取操作员的主机文件系统会被拒绝;由于 Docker Engine 套接字从未挂载,且没有 docker 客户端,通过该套接字控制主机也会被拒绝。最后会输出隔离摘要,显示 3 次逃逸尝试全部被拒绝,沙箱成功守住。

看看它如何阻止真实的逃逸。 一个完全越狱的 Agent 在真正的沙箱内尝试联络外部、读取主机文件系统,以及通过 Docker 套接字控制主机。每次尝试都在隔离边界被拒绝,随后输出隔离摘要。一条命令,无需凭据,并支持减少动态效果。examples/live-containment/run.sh

⭐ 喜欢这种无需信任 Agent 的理念?请为仓库点亮 Star,这样只需点击一次即可关注进展,也能让更多人找到它。然后在 30 秒内运行上方的完整演示,无需注册,也无需 API 密钥。

30 秒快速体验(无需凭据)

确保 Docker 守护进程正在运行(启动 Docker Desktop,或在 Linux 上运行 sudo systemctl start docker),然后粘贴以下命令块:

git clone https://github.com/IronSecCo/ironclaw.git && cd ironclaw
examples/live-containment/run.sh   # builds the sandbox once, engages a real sandbox, proves it holds

这条命令会在你的笔记本电脑上运行完整的安全流程:启动离线模拟 Agent 控制平面(无需 API 密钥)、启用真正的按会话隔离沙箱、让越狱的 Agent 尝试逃逸,并输出你在上方看到的隔离摘要。想先在浏览器中与 Agent 聊天?运行 hello-ironclaw 或查看无需凭据的快速入门。生产环境会为每个沙箱启用 gVisor,并设置 network=none。

警告

Alpha 版软件,仍在开发中。依赖它之前请仔细阅读。

  • 这是 Alpha 版。 标志、磁盘格式和 HTTP/契约接口仍可能在没有通知或迁移方案的情况下发生变化。请勿将其用于任何无法承受损失的场景。
  • 并非所有功能都经过端到端测试。 控制平面、网关和加密队列核心经过了充分测试(800 多项 Go 测试,另有黑盒一致性测试套件);通道适配器、部分工具、多提供商路由和实际启动沙箱的测试较少。请将已测试核心之外的所有内容视为实验性功能。

macOS 的沙箱边界弱于 Linux+gVisor,且 原生 Windows 完全无法运行 Agent 沙箱(请使用 WSL2)。请参阅平台支持。

一句话概括安全模型:每个沙箱中的 Agent 都以 network=none 运行,只能通过主机代理连接大模型,且无法更改自身配置。每项能力变更都必须由网关拦截,等待人工决策。完整设计请参阅架构概览和威胁模型。

查看完整流程,端到端体验
零凭据聊天演示终端会话:运行一条命令(docker compose -f docker-compose.demo.yml up -d),即可启动离线 mock-agent 控制平面,无需 API 密钥;发送聊天消息后,Agent 会启动一个真实的独立会话沙箱容器(ic-sbx-…);回复通过加密的独立会话队列传回。

零凭据,一条命令。离线 mock-agent 无需 API 密钥,即可完整运行从聊天到独立会话沙箱再到回复的流程。生产环境会使用 gVisor 和 network=none 隔离每个沙箱。快速入门



IronClaw 端到端演示终端会话,分为三个部分。第 1 部分:运行一条命令启动离线 mock-agent,无需 API 密钥即可获得回复。第 2 部分:通过导出经过脱敏、由主机端持有的 ANTHROPIC_API_KEY 并启动真实控制平面来连接真实提供商(每个会话均使用 gVisor 和 network=none 隔离)。第 3 部分:Agent 提交一项人格变更,该变更在人工审批网关处被暂缓,人工审批通过后,提交、审批、应用的记录会写入只追加审计日志。

零凭据演示、连接真实提供商、完成首个获批任务。唯一需要提供凭据的步骤会将密钥保留在主机端;Agent 的每项变更都会在网关处暂缓,等待人工审批,然后写入只追加审计日志。在 prefers-reduced-motion 设置下,动画会停留在最后一帧。快速入门

两分钟内启动

运行一条命令即可安装两个主机二进制文件(ironctl + ironclaw-controlplane);在开发模式下, 控制平面会在 http://127.0.0.1:8787 提供 API。从一台刚启动的机器开始,你可以在 两分钟内于安全网关看到一项待处理的能力变更:

# 1. Install — detects your OS/arch and verifies the SHA-256 checksum before installing
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sh

# 2. Start the control-plane in dev mode — API base URL: http://127.0.0.1:8787
export IRONCLAW_API_TOKEN=$(openssl rand -hex 32)
ironclaw-controlplane --dev --api-addr 127.0.0.1:8787 &

# 3. Your first command — submit a change; it is HELD at the gateway for a human decision
ironctl change submit --kind persona --group dev-agent --by you
ironctl change pending                       # see it waiting
ironctl change approve <change-id> --by you   # apply it

在 Windows 上,运行 irm https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.ps1 | iex 即可安装主机二进制文件(ironclaw-controlplane.exe + ironctl.exe),并以 --dev 模式运行,但 Agent 沙箱需要 WSL2 或 Linux——请参阅 通过 WSL2 使用 Windows。 版本固定、系统范围安装和从源代码构建的说明均见安装。

一键云端部署

无需本地工具,即可在约 2 分钟内将加固后的控制平面部署到 PaaS——包括 审批网关、加密的独立会话队列、由主机端保管的凭据和 Web 控制台:

部署到 Fly.io ![部署到 Render](https://img.shields.io/badge/部署到 Render](https://render.com/deploy?repo=https://github.com/IronSecCo/ironclaw&path=deploy/render/render.yaml) 部署到 Railway

这些 PaaS 部署方式仅运行控制平面——单个容器没有 gVisor,也没有 Docker 套接字,因此不会在此启动 Agent 沙箱(与加固后的 Compose 部署方式具有相同边界)。如需完整的 Agent 隔离,请使用 gVisor 主机或 k8s 节点。详情和环境变量见部署指南(路径 D)。

以 CLI 和 API 为先

这是一项功能,而不是缺少仪表盘。每项功能都是有文档说明的 HTTP 端点,同时也是一个 ironctl 子命令,因此从第一条命令开始,IronClaw 就可编写脚本、可审计,也适合用于 CI—— 没有可供钓鱼、错误配置或暴露在外的公共 Web 界面。(现在新增了仅限私有网格访问的 Web 控制台,位于 /ui/——但它是附加功能,绝非唯一入口,并通过同一个绑定到 Tailscale 的 API 提供服务,因此不会新增公共端口。)


目录

与众不同之处

支柱说明消除的攻击面
密封运行时Agent 以编译后的 Go 二进制文件形式交付Agent 自我修改——容器内没有可供改写的源代码
经人工批准对运行框架的每项更改都必须通过确定性网关未经察觉的设置更改——未经人工查看和批准,任何内容都不会改变
加密队列按会话加密的消息队列;入站内容只读静态数据窃取和跨会话读取
密封沙箱gVisor 容器,无网络,由主机代理模型调用数据外泄和沙箱逃逸
私有控制面板仅通过私有网格(Tailscale)进行管理员访问针对控制功能的远程攻击

核心理念:将 Agent 视为不可信对象,并让安全边界可以验证——而不是只能凭信任接受。

⚖️ 正在权衡选项? 请参阅为什么选择 IronClaw / 与其他方案的比较, 了解我们对托管 Agent 平台、原始容器 + LLM 胶水方案以及其他可自托管 Agent 运行时所做的坦诚比较。

10 秒内审计自己的沙箱

不要只听我们怎么说。ironctl scan 会以 0 到 100 分的量表评估 任何正在运行的容器、docker-compose 服务或 Kubernetes Pod 的隔离状况。 它适用于你自己的环境,而不只是 IronClaw,因此在将沙箱交给不可信代码之前,你可以衡量实际拥有的隔离程度。它采用失败关闭策略:任何无法观测到的边界都会被评为不安全,绝不会放行。

ironctl scan my-container

它还可以在编写 Dockerfile 或 CI 阶段进行静态评分,无需守护进程,也无需拉取镜像,因此你可以在代码审查中发现泄露的凭据、未固定版本的基础镜像或默认以 root 身份运行的问题,而不是等到生产环境才发现:

ironctl scan --dockerfile Dockerfile --min-score 80

使用 pre-commit 钩子在每次提交时自动评估 Dockerfile;该钩子会从源代码构建 ironctl,因此无需预先安装任何内容:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/IronSecCo/ironclaw
    rev: v0.1.x
    hooks:
      - id: ironclaw-scan-dockerfile
        args: [--min-score=80]   # fail the commit below grade B

操作演示: 如何扫描 Dockerfile 中的安全问题 会逐步修复一个有意写得很糟糕的 Dockerfile,将其评分从 5/100(F) 提高到 100/100(A)。

按常规方式启动的容器(root 用户、默认能力、桥接网络,并挂载 docker.sock) 评分为 23/100,F。IronClaw 的 ic-sbx-* 会话沙箱则获得满分 100/100,A:

目标分数等级安全态势
典型的 docker run 容器23/100F以 root 身份运行,挂载了 docker.sock,根文件系统可写,通过 bridge 出站联网
IronClaw 会话沙箱100/100A非 root 用户,已删除所有能力,已启用 seccomp,network=none,根文件系统只读,使用 gVisor

每一项不合格的指标都会指出具体漏洞及其影响。使用 ironctl scan --badge scan.svg 将等级添加到你自己的 README 中,或使用 ironctl scan --min-score 90 在 CI 中设置门槛。

查看扫描参考,了解全部七个维度和所有标志。也可以浏览 容器隔离分数目录:其中列出了 150 多个下载量最高的公共镜像在默认配置下的等级,让你了解 已在运行的容器表现如何。排名请查看 容器隔离排行榜 (名人堂与最差表现者);交互式 分数浏览器则可让你筛选并为仓库获取徽章。

基于同一份扫描数据进行的正面对比: Alpine、Debian 与 Ubuntu 对比 (基础镜像会改变隔离效果吗?)、 Docker 默认配置与加固配置对比 (48 分的差距,逐项标志分析),以及 gVisor 与 runc 对比 (共享主机内核何时会成为薄弱环节)。 逐个镜像的加固指南、默认等级、未通过的维度,以及弥补差距所需的准确 ironctl scan --fix 标志。请从加固指南中心开始,或直接跳转到其中一篇: Postgres, MySQL, MariaDB, MongoDB, Cassandra, ClickHouse, Redis, Memcached, Elasticsearch, Kafka, NATS, RabbitMQ, Vault, Consul, MinIO, nginx, Grafana, Prometheus, Traefik, InfluxDB, CockroachDB, TimescaleDB, Valkey, HAProxy, ZooKeeper以及 不可信 Node.js。

为每个拉取请求评级

同一评级器也已发布到 GitHub Marketplace,名为 IronClaw sandbox scan。只需在工作流中添加一行,每个拉取请求都会获得一张隔离评分卡,以置顶评论的形式发布并原地更新:

# .github/workflows/scan.yml
- uses: IronSecCo/ironclaw@v1
  with:
    target: docker-compose.yml
    mode: compose
    min-score: 90        # omit / 0 = report-only, never blocks the check

它在未经修改的 ubuntu-latest 运行器上运行,无需凭据,也无需控制平面。mode: k8s 会添加 policy-check: true,若 --emit-policy 会生成任何规则,则检查失败;upload-sarif: true 会将未通过的维度发送到 Security 选项卡。完整的输入和输出见:在 CI 中扫描。

展示你的评分

像展示覆盖率或构建徽章一样,将你的隔离等级放进 README。生成 shields.io 端点文件并提交(无需服务器,因此访问徽章不会触发远程扫描),然后嵌入徽章:

ironctl scan my-container --badge-json .ironclaw/sandbox-isolation.json
git add .ironclaw/sandbox-isolation.json && git commit -m "chore: add sandbox isolation badge"
[![Sandbox Isolation Score](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/OWNER/REPO/main/.ironclaw/sandbox-isolation.json)](https://ironsecco.github.io/ironclaw/scan/)

本 README 顶部的徽章是 IronClaw 自己的评分:根据 .ironclaw/sandbox-posture.yml获得 100/100 A。完整指南: 为你的仓库添加实时 Sandbox Isolation Score 徽章。

工作原理

两个编译后的 Go 程序彼此不共享内存,每个对话仅通过一对加密的 SQLite 文件通信:

flowchart TB
  CHAT["Chat platforms<br/>12 channel adapters"]
  CLI["ironctl CLI"]
  WEB["Web console"]

  subgraph host["Trusted host — control-plane (cmd/controlplane)"]
    API["HTTP API<br/>Tailscale mesh-only + bearer"]
    GW["Gateway<br/>deterministic verifiers · human approval"]
    CORE["Router · delivery · sweep · key custodian"]
    CHAD["Channel adapters"]
    MP["Model proxy<br/>holds provider keys"]
    ISO["Isolation launcher<br/>gVisor / runsc"]
  end

  subgraph queues["Encrypted SQLCipher queues · per session"]
    INQ[("inbound.db<br/>read-only to agent")]
    OUTQ[("outbound.db<br/>append-only by agent")]
  end

  subgraph box["Agent sandbox · gVisor · network=none"]
    LOOP["Agent loop · tools · model provider"]
  end

  PROV["Model providers<br/>Anthropic · OpenAI · OpenRouter"]

  CHAT <--> CHAD
  CLI -->|mesh only| API
  WEB -->|mesh only| API
  CHAD --> CORE
  API --> GW --> CORE
  CORE -->|write| INQ
  OUTQ -->|read| CORE
  ISO -->|launch| LOOP
  INQ -->|ro bind mount| LOOP
  LOOP -->|append| OUTQ
  LOOP -->|unix socket| MP -->|HTTPS · key injected host-side| PROV

  classDef host fill:#eaf2ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef store fill:#b9d4ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef box fill:#1d4ed8,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef control fill:#16224a,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef ext fill:#f4f9ff,stroke:#8fb4ff,stroke-width:1px,color:#16224a;

  class API,CORE,CHAD,MP,ISO host;
  class GW control;
  class INQ,OUTQ store;
  class LOOP box;
  class CHAT,CLI,WEB,PROV ext;
  • 控制平面接收聊天消息、路由消息、持有密钥、运行审批网关,并代表 Agent 执行所有特权操作——但会先进行自己的检查。
  • 沙箱——每个对话一个,由 gVisor 封装且自身不具备网络访问能力——读取加密收件箱(只读),通过主机代理调用 AI 模型,并写入加密发件箱。它可以请求更改能力,但绝不能自行应用更改。
  • 冻结契约(internal/contract)是双方唯一共同导入的包:包含类型化 ID、行结构、内嵌 SQL 架构、固定的加密参数和网关协议。

单条消息会沿着一条简洁的循环传递;任何会改变 Agent 能做什么的操作,都会走单独的虚线流程,经过人工审批网关:

flowchart LR
  SENDER["External sender<br/>Slack · email · …"]
  ADAPTER["Channel adapter"]
  ROUTER["Router<br/>authorize + fan-out"]
  INQ[("inbound.db")]
  LOOP["Agent loop"]
  MODEL["Model provider"]
  OUTQ[("outbound.db")]
  DELIVERY["Delivery"]
  GW{"Gateway<br/>human approval"}
  APPLY["Control-plane<br/>applies change"]

  SENDER -->|message| ADAPTER --> ROUTER
  ROUTER -->|write · encrypted| INQ
  INQ -->|ro| LOOP
  LOOP <-->|model call via host proxy| MODEL
  LOOP -->|reply · append| OUTQ
  OUTQ --> DELIVERY --> ADAPTER
  ADAPTER -->|reply| SENDER
  LOOP -.->|capability-change request| GW
  GW -.->|approved| APPLY

  classDef host fill:#eaf2ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef store fill:#b9d4ff,stroke:#1d4ed8,stroke-width:1px,color:#0b1124;
  classDef box fill:#1d4ed8,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef control fill:#16224a,stroke:#63a0ff,stroke-width:2px,color:#ffffff;
  classDef ext fill:#f4f9ff,stroke:#8fb4ff,stroke-width:1px,color:#16224a;

  class ADAPTER,ROUTER,DELIVERY,APPLY host;
  class INQ,OUTQ store;
  class LOOP box;
  class GW control;
  class SENDER,MODEL ext;

完整设计请参阅 docs/architecture.md、docs/threat-model.md,以及使用通俗语言介绍的 docs/ironclaw-explained.md。

📚 完整文档站点: ironsecco.github.io/ironclaw — 快速入门、架构、威胁模型、频道、技能、OpenAPI 参考和安全内容,尽在一个可导航的站点中(由 docs/ 构建,并在每次推送到 main 时发布)。

🧭 初次使用? 动手教程将带你从 git clone 开始,直到运行起一个 Agent:5 分钟创建你的第一个沙箱 Agent、连接 Slack,以及编写自定义频道适配器。

平台支持

IronClaw 的安全模型依赖于 gVisor(runsc)——一种用户空间内核,可拦截 Agent 的 Linux 系统调用,并实际强制执行 network=none、seccomp 系统调用允许列表、已移除的 Linux 能力以及只读根文件系统。gVisor 仅支持 Linux,这一事实决定了整个跨平台方案:

能力Linux + gVisor(生产目标)macOS / Windows
主机端 — 控制平面、网关、API、ironctl、Web 控制台✅ 原生✅ 原生(包括原生 Windows)
真实的 Agent 沙箱✅ gVisor(runsc)⚠️ 仅支持 --runtime docker — Docker Desktop Linux 虚拟机中的 runc。macOS: Docker Desktop。Windows: WSL2(原生 Windows 无法访问它——见下文)
每个沙箱的系统调用拦截✅❌ 不可用
Seccomp 系统调用允许列表✅ 强制执行❌ Docker 路径下不会应用
network=none✅ 由 OCI 规范强制执行⚠️ 不会自动强制执行 — 你必须将 IRONCLAW_DOCKER_NETWORK 指向一个无出站流量的网络
已移除的能力 · 只读根文件系统✅ 由运行时强制执行⚠️ 安全性取决于 Docker Desktop 虚拟机内核

在 macOS 上,你可以原生构建、编写脚本、演示并针对整个系统进行开发,甚至可以通过 Docker Desktop 运行 Agent——但请注意,此时沙箱边界来自 Docker Desktop Linux 虚拟机中的 runc,而非 gVisor。 系统不会对每个沙箱进行系统调用拦截,也不会应用经过精心筛选的 seccomp 配置文件,而且 network=none 不会自动为你强制执行(Docker 隔离器会直接传递你配置的网络——请自行将 IRONCLAW_DOCKER_NETWORK 设置为无出站流量的桥接网络)。这比威胁模型所假设的安全态势更弱。

通过 WSL2 使用 Windows

install.ps1 PowerShell 安装程序可在 Windows 上原生运行主机平面: ironclaw-controlplane.exe 和 ironctl.exe 可以运行,加密的 SQLCipher 队列正常工作,--dev 模式(无真实沙箱)可以端到端运行。真实 Agent 沙箱无法在原生 Windows 上运行——gVisor(runsc)仅支持 Linux,而 Docker 回退方案通过 Unix 套接字(/var/run/docker.sock)与 Docker Engine 通信;原生 Windows Docker Desktop 不会公开该套接字(它提供的是 Windows 命名管道)。因此,在原生 Windows 上,你可以使用控制平面和 ironctl,但 Agent 运行时没有可用于启动的环境。

如需在 Windows 上实际运行 Agent,请使用 WSL2:

wsl --install -d Ubuntu          # one-time: install WSL2 + Ubuntu, then reboot

然后,在 WSL2 Ubuntu shell 中安装 Linux 版本,并按 Linux 上的方式运行:

curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sh

在 WSL2 中,/var/run/docker.sock 存在(由 Docker Desktop 的 WSL 集成提供,或在发行版中安装 Docker),因此 IRONCLAW_RUNTIME=docker 会启动真实的 Linux 沙箱容器。如需采用完整的 gVisor 安全配置,请像在裸机 Linux 上一样,在 WSL2 发行版中安装 runsc。将 WSL2 主机视同上方 Linux 行所述的主机。

除了本地开发之外,沙箱主机都应运行在装有 gVisor 的 Linux 上(裸机、虚拟机或 WSL2)。控制平面可以部署在你喜欢的任何位置——包括原生 Windows——但 Agent 沙箱需要 Linux + gVisor 基础环境,才能提供 IronClaw 所构建的隔离边界。

项目状态

Alpha。 架构已经确定,完整的控制平面和沙箱流水线已实现并通过测试。加密队列绑定现已接入:

  • 加密 SQLite 队列绑定 — ✅ 已接入(RFC-0001 已应用)。contract.Open* 通过 cgo 使用 github.com/mutecomm/go-sqlcipher/v4 打开每个会话对应的 SQLCipher 数据库;往返测试涵盖写入→读取、拒绝只读写入、错误密钥失败,以及确保磁盘上不留明文。现在构建需要 CGO_ENABLED=1(以及 C 工具链)。internal/host/queue 使用实时绑定;--dev 和测试仍使用内存后端。
  • 沙箱根文件系统预配 — ✅ 已通过可插拔的预配器接入:isolation 构建强化的 OCI 规范、预配捆绑包根文件系统(根据信任策略验证镜像摘要和签名),并执行 runsc。实际启动仍需要环境中存在 runsc 和已预配且已签名的镜像。
  • 生产环境加固(Wave 4) — 已实现耐久且可插拔的主密钥托管、Prometheus /metrics 接口、结构化日志、主机重启 + 沙箱提供方退避,以及模型代理速率限制/审计/脱敏,并已整合到 cmd/controlplane 中。API 服务加固选项(可选 TLS、速率限制、请求体大小限制、/readyz 就绪门控)已作为 api.With* 选项提供,但尚未接入入口(参见路线图)。

请参阅路线图,了解仍待完成的工作。你现在就可以构建、测试并运行控制平面;启动实时沙箱则需要 runsc 和已预配的镜像。

前提条件

要求用途说明
Go 1.23+ 和 C 工具链构建所有内容必须设置 CGO_ENABLED=1——加密 SQLite 绑定通过 cgo 构建
containerd + gVisor(runsc)生产环境沙箱运行时 io.containerd.runsc.v1;--dev 模式不需要
Tailscale远程管理访问控制平面 API 绑定到 tailnet IP;不开放公网端口
SQLCipher(已随附)加密队列驱动随附 SQLCipher C amalgamation;无需系统库
模型凭据实时模型调用Anthropic / OpenAI / OpenRouter 密钥,或 OneCLI 等网关——由主机侧注入模型代理,绝不注入沙箱(模型提供商)

三个外部运行时依赖(gVisor、Tailscale、加密 SQLite 绑定)均未随附。主机设置请参阅 deploy/README.md。

安装

Homebrew(macOS / Linux)
brew tap IronSecCo/ironclaw https://github.com/IronSecCo/ironclaw
brew install ironsecco/ironclaw/ironclaw

这会从公式当前固定的版本安装 ironctl、ironclaw-controlplane 和 ironclaw-sandbox。公式将每个归档文件固定为该版本签名的 SHA256SUMS 中记录的 SHA-256,因此 Homebrew 会在安装前验证下载文件。使用 ironctl version 确认。

tap 一次只包含一个版本。每次发布后都会有自动化拉取请求更新公式;只有在必需的 CI 检查根据该版本通过 cosign 验证的 SHA256SUMS 重新生成公式后,更新才会合并,因此 tap 可能会暂时落后于最新版本。请先运行 brew update,并参阅发布版本获取最新版本。若要安装特定版本(包括 tap 尚未收录的版本),请使用安装脚本的 IRONCLAW_VERSION(下文)。

请使用完整限定名称。 homebrew-core 也提供了一个名为 ironclaw 的无关公式,而 core 会优先匹配不带限定名称的写法——因此请安装 ironsecco/ironclaw/ironclaw,而不是直接使用 ironclaw。还必须指定明确的 tap URL:我们的 tap 位于此仓库中,而不在 homebrew-ironclaw 仓库中。

在生产环境中,控制平面通常以 GHCR 容器镜像的形式运行(请参阅部署指南);原生 ironclaw-controlplane 二进制文件则适用于本地运行或 --dev 模式。

预构建二进制文件(安装脚本)

运行一条命令即可安装最新版本——ironctl 和 ironclaw-controlplane。脚本会检测你的操作系统和架构,从 GitHub Releases 下载匹配的归档文件,并在安装前验证其 SHA-256 校验和。

macOS / Linux

curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sh

Windows(PowerShell)

irm https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.ps1 | iex

这会安装主机二进制文件(ironclaw-controlplane.exe + ironctl.exe)并原生运行 --dev 模式,但无法运行真正的 Agent 沙箱——这需要 Linux。在 Windows 上运行 Agent,请在 WSL2 中安装;请参阅 通过 WSL2 使用 Windows。

每次推送到 main 都会发布新版本,并提供以下平台的预构建归档文件:

操作系统架构
macOSIntel(amd64)· Apple Silicon(arm64)
Linuxamd64 · arm64
Windowsamd64

安装脚本会读取几个环境变量(请在管道的 sh 端传入):

# Pin a version instead of latest
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | IRONCLAW_VERSION=v0.1.102 sh

# Install system-wide (a normal user defaults to ~/.local/bin)
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | sudo sh

# Choose the install directory
curl -fsSL https://raw.githubusercontent.com/IronSecCo/ironclaw/main/scripts/install.sh | IRONCLAW_BINDIR="$HOME/bin" sh

然后确认已安装的内容:

ironctl --version

想手动获取文件?请从最新发布版本下载适用于你平台的归档文件和 SHA256SUMS。

版本管理器(mise / asdf)

使用 mise 或 asdf 按项目固定 IronClaw 版本,无需账户,也无需 sudo。最快的方式是使用 mise 的 ubi 后端,直接从 GitHub 发布版本安装 ironctl CLI(无需插件仓库):

mise use -g "ubi:IronSecCo/ironclaw[exe=ironctl]@latest"
ironctl --version

如需使用两个主机二进制文件(ironctl + ironclaw-controlplane)和固定版本的 .tool-versions,请使用 packaging/asdf-ironclaw/ 下的 asdf 风格插件。它会下载发布压缩包,根据已发布的 SHA256SUMS 验证文件,并将两个二进制文件放到受管理的 PATH 中:

ironclaw 0.1.217

该插件会解析为独立仓库(asdf 通过 URL 克隆插件),因此插件迁移到独立的 IronSecCo/asdf-ironclaw 仓库后,即可使用 asdf plugin add ironclaw 和 mise use asdf:...。在此之前,可直接运行 packaging/asdf-ironclaw/ 中的脚本(参见该目录下的 README.md)。

验证发布版本

发布版本均经过签名和证明——使用密钥无关的 cosign 对 SHA256SUMS 进行签名,提供 SBOM(SPDX + CycloneDX),并为每个压缩包和容器映像提供构建来源证明。有关如何创建、验证和撤回发布版本,请参阅发布操作手册。

验证已签名的发布版本

每个发布版本都附带 SHA256SUMS、SHA256SUMS.sig + SHA256SUMS.pem(cosign 签名及其证书)、*.spdx.json / *.cdx.json SBOM,以及每个压缩包和映像的证明。

验证校验和签名(无需管理密钥——身份由发布工作流确定):

cosign verify-blob SHA256SUMS \
  --signature SHA256SUMS.sig --certificate SHA256SUMS.pem \
  --certificate-identity-regexp '^https://github.com/IronSecCo/ironclaw/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com
sha256sum -c SHA256SUMS        # then confirm your archive matches

验证压缩包、解压后的二进制文件或映像的构建来源:

gh attestation verify ironclaw_<version>_<platform>.tar.gz --repo IronSecCo/ironclaw
gh attestation verify ./ironctl --repo IronSecCo/ironclaw   # a binary extracted from the archive
gh attestation verify oci://ghcr.io/ironsecco/ironclaw-controlplane:latest --repo IronSecCo/ironclaw

容器映像还附带已签名的 SBOM 证明(CycloneDX),可匿名验证和读取:

gh attestation verify oci://ghcr.io/ironsecco/ironclaw-controlplane:latest \
  --repo IronSecCo/ironclaw \
  --predicate-type https://cyclonedx.org/bom

每个第三方 GitHub Action 都固定到提交 SHA;构建使用固定的工具链 + -trimpath,并通过双重构建 CI 作业检查是否逐位可复现(ironctl 和 sandbox 已验证字节完全一致;较大的控制平面二进制文件可在较新版本的 Go 下复现,并针对固定工具链持续跟踪);项目的供应链安全状况还由 OpenSSF Scorecard 持续评分(请参阅上方徽章)。

从源代码构建

需要 Go 1.23+ 和 C 工具链(CGO_ENABLED=1——加密 SQLite 绑定通过 cgo 构建)。

# Clone
git clone https://github.com/IronSecCo/ironclaw.git
cd ironclaw

# Build all binaries
make build            # == go build ./...

# Or install the two host binaries onto your PATH
go build -o /usr/local/bin/ironclaw-controlplane ./cmd/controlplane
go build -o /usr/local/bin/ironctl               ./cmd/ironctl

如需完整安装系统——构建并安装二进制文件、配置 /etc/ironclaw 和 /var/lib/ironclaw,并启用服务(Linux 上使用 systemd,macOS 上使用 launchd)——请运行 sudo deploy/install.sh。该脚本需要 root 权限才能写入 /etc 和 /var/lib。它依赖的外部运行时(containerd + gVisor 和 Tailscale)需单独设置——请参阅 deploy/README.md。

使用 Docker(docker compose)

只需一条命令即可自托管控制平面。从克隆的仓库开始:

cp .env.example .env          # fill in ANTHROPIC_API_KEY (optional to boot)
docker compose up -d          # builds locally on first run, or pulls the GHCR image
docker compose logs -f controlplane   # CLAIM the admin token printed once on first run

管理/API 令牌会在首次运行时生成,并且只在日志中显示一次(无法恢复),除非你自行设置 IRONCLAW_API_TOKEN。管理 API 仅发布在 127.0.0.1:8787 上;如需远程访问,请在前面配置 Tailscale。

更喜欢使用已发布的镜像?每次发布时都会将镜像推送到 GitHub Container Registry:

docker pull ghcr.io/ironsecco/ironclaw-controlplane:latest
# or pin a release: docker pull ghcr.io/ironsecco/ironclaw-controlplane:v0.1.102

在 .env 中设置 IRONCLAW_IMAGE,即可为 docker compose 固定该标签。控制平面读取的所有变量都记录在 .env.example 中。Agent 沙箱本身不是 compose 服务——控制平面会将它们作为 gVisor(runsc)子进程启动,并设置 network=none;运行真实沙箱需要支持 runsc 的主机(参见 deploy/README.md)。

准备部署到生产环境?**部署指南**介绍了经过加固、可靠持久化的部署方案:在 TLS 反向代理(deploy/Caddyfile)后运行受限的 deploy/docker-compose.prod.yml(只读根文件系统、移除 capabilities、资源限制),通过 env 文件管理密钥,备份/恢复加密状态,使用固定摘要进行升级,以及 Prometheus /metrics。

快速开始

更完整的本地操作指南——在开发模式下从源代码运行控制平面(不使用 gVisor,绑定到回环地址),并使用管理 CLI 操作:

# Terminal 1 — start the control-plane in dev mode
export ANTHROPIC_API_KEY=sk-ant-...        # held host-side; never enters the sandbox
export IRONCLAW_API_TOKEN=$(openssl rand -hex 32)
go run ./cmd/controlplane --dev --api-addr 127.0.0.1:8787

# Terminal 2 — talk to the gateway with ironctl
export IRONCLAW_API_TOKEN=<same token as above>

# Submit a capability change — it is HELD pending a human decision (the gateway choke point)
ironctl change submit --kind persona --group dev-agent --by alice

# See what's waiting for approval, then approve or reject by id
ironctl change pending
ironctl change approve <change-id> --by alice

# Inspect the append-only audit log
ironctl audit --limit 20

所有变更——角色设定、已启用的工具、软件包、连接配置、权限、挂载——都通过同一个网关完成。不存在绕过网关的文件编辑途径。

示例

其中两个示例无需任何凭据即可端到端运行——不需要模型密钥,也不需要频道令牌, 只需 Docker。复制一行命令,看看它如何运行:

hello-ironclaw 终端演示:一条命令(examples/hello-ironclaw/run.sh)构建沙盒镜像,在无需凭据的情况下启动离线 mock-agent 控制平面,通过真实的 engage → 每会话沙盒 → 加密队列 → 回复路径发送一条聊天消息,并在收到 Agent 回复后打印 PASS。

hello-ironclaw — 标准的“它能正常工作”示例。一条命令即可通过真实的安全路径(engage → 每会话沙盒 → 加密队列 → 回复)发送一条聊天消息,并验证回复确实返回。无需任何凭据;也可用作 CI 冒烟测试。在 prefers-reduced-motion 下,动画会停在最后一帧。



live-containment 终端演示(最后一帧):一个完全越狱的 Agent 在沙盒内尝试三种逃逸方式,全部遭到阻止——网络数据外传因 network=none(仅限回环)而被拒绝,读取主机文件系统因挂载命名空间而被拒绝,通过 Docker Engine 套接字接管主机因该套接字从未挂载进沙盒而被拒绝——最后显示隔离摘要,表明 3 次逃逸尝试均遭拒绝,沙盒正常运行。

live-containment — 观看它拦截真实的逃逸尝试。用 60 秒带来安全方面的顿悟:一条命令即可启用真实沙盒,一个完全越狱的 Agent尝试逃逸(网络数据外传、逃出主机文件系统、通过 Docker 套接字接管主机),终端会显示每次尝试都被拒绝,并附上隔离摘要。这是 red-team-escape 的精选演示。无需任何凭据。



red-team-escape 终端演示:假设一个完全越狱的 Agent,测试工具会在沙盒内运行一系列逃逸测试,并打印 PASS 表格——网络出口已阻止(接口:lo)、Docker 套接字不存在、无法编排同级容器、主机根目录未挂载、自我修改在网关处受阻、无法访问主机主密钥和同级密钥——随后报告所有核心隔离断言均成立。

red-team-escape — 可验证的隔离能力。live-containment 背后的完整六项断言测试:增加了同级容器逃逸和跨会话密钥保管探测,并生成带签名和版本号的隔离报告;每次推送时都会作为 CI 隔离门禁运行。无需任何凭据。

可运行的示例位于 examples/ 中——每个示例都是一个包含 README.md 和 setup.sh 的目录。 其中三个示例附带 run-mock.sh,可在离线 mock 提供方上驱动完整的入站 → Agent → 回复流水线,因此新克隆的仓库无需模型密钥或频道令牌即可运行:

docker compose -f docker-compose.demo.yml up -d --build   # seeds the offline mock-agent
./examples/scheduled-report/run-mock.sh                   # cron-style self-scheduling summary
./examples/webhook-responder/run-mock.sh                  # inbound webhook → agent reply
./examples/slack-triage/run-mock.sh                       # classify/label every message
  • scheduled-report/ — 按计划自动唤醒(schedule_task)、生成摘要并发布到频道。(无需凭据的演示)
  • webhook-responder/ — 将入站 HTTP webhook 转发给会回复的 Agent。(无需凭据的演示)
  • slack-triage/ — 对每条传入的 Slack 消息进行分类和标记。(无需凭据的演示)
  • personal-assistant/ — 在 Telegram 上提供私密的一对一助手,并演示强制变更审批流程。
  • channel-triage/ — 仅在收到 @mention 且发送者已知时才响应的 Slack 分类机器人。
  • multi-agent-team/ — 两个 Agent 共享一个频道,并通过 engage 模式和优先级区分。

用法

ironclaw-controlplane — 主机守护进程
ironclaw-controlplane \
  --api-addr "$(tailscale ip -4):8787" \            # bind to the tailnet IP (no public port)
  --model-proxy-socket /run/ironclaw/modelproxy.sock \
  --runtime runsc \                                 # container runtime for sandboxes
  --state-dir /var/lib/ironclaw \
  --sweep-interval 60s
标志默认值用途
--api-addr127.0.0.1:8787控制平面 API 地址;在生产环境中设置为 tailnet IP
--model-proxy-socket/run/ironclaw/modelproxy.sock绑定到每个沙箱中的 Unix 套接字,用于模型出站流量
--state-dirOS-specific网关变更存储、审计日志、密钥库
--runtimerunsc沙箱使用的 OCI 运行时
--bundle-root<state-dir>/bundles每个会话的 OCI bundle
--sweep-interval60s清理过期沙箱/到期消息的频率
--egress-socket""(封闭)选择启用:主机 Unix 套接字,供出站代理使用,并绑定到每个沙箱中,让 Agent 能访问已批准的外部主机(默认拒绝,且会审计)
--egress-allow""出站代理允许访问的主机名,以逗号分隔(仅与 --egress-socket 配合使用)
--search-backend""(关闭)为每个沙箱提供 web_search 工具:duckduckgo(无需密钥)或 brave[:cred](通过密钥库提供密钥)。需要 --egress-socket;后端主机会自动加入允许列表
--mcp-catalog""(关闭)选择启用:开启 MCP 服务——每会话主机代理、mcp_access 变更类型和 MCP 控制台标签页。配置好的服务对应的 0600 JSON 目录
--mcp-isolationcontainer本地(stdio)MCP 服务的运行方式:container(强化隔离,network=none——生产环境)或 none(直接运行主机进程——仅限开发)
--mcp-runtime / --mcp-image""OCI 运行时(例如用于 gVisor 的 runsc)以及隔离运行的本地 MCP 服务的默认镜像
--devfalse绑定到环回地址,不使用 gVisor——仅限本地开发;同时开放仅限 DuckDuckGo 的出站通道,让 web_search 开箱即用,并通过 --mcp-isolation=none 启用 MCP
MCP 服务

通过 Model Context Protocol 服务(本地的 stdio 子进程或远程的 HTTPS 端点)扩展 Agent 的工具,同时不削弱沙箱安全性。MCP 仅在主机侧运行:本地服务隔离在经过强化且设置为 network=none 的容器中,远程服务通过 TLS 建立连接;沙箱无法直接访问这两者,而是与每会话代理套接字通信,所有调用都会根据逐工具、经人工批准的授权进行检查并接受审计。这弥补了参考设计中“盲目批准 MCP”的缺陷。使用 --mcp-catalog 启用,在控制台的 MCP 标签页中添加服务并向 Agent 授权,然后使用捆绑的 cmd/mcp-sample 服务端到端体验。完整指南:docs/mcp.md。 要将 IronClaw 的 sandbox_exec 工具作为 MCP 服务提供给 Claude Desktop、Cursor 或 Windsurf,请参阅 docs/mcp-server/。

环境变量:ANTHROPIC_API_KEY(模型代理凭据,仅限主机侧)和 IRONCLAW_API_TOKEN(设置后,每次 API 调用都必须提供 bearer token)。

网页搜索

沙箱设置为 network=none;只能通过由主机中介并接受审计的出站代理访问主机。web_search 工具通过该代理运行,因此默认关闭,只有同时设置 --egress-socket 和 --search-backend 才会启用:

  • duckduckgo — 无需密钥,也不需要机密信息。最快可用的搜索方式,但 DuckDuckGo 的无密钥 API 返回的是即时答案/相关主题,而非完整的排序网页索引,因此特定查询(例如某人的姓名)可能返回的内容较少。
  • brave[:cred] — 通过密钥库按名称访问 Brave Search(vault://<cred>/…),因此 API 密钥保留在主机侧的注入器中,不会进入沙箱。需要设置 --vault-endpoint,并提供匹配的凭据。

--dev 会自动启用 DuckDuckGo 后端(将出站套接字放在模型代理套接字旁边,以便它们通过同一个沙箱挂载点接入)。使用 Docker 隔离器时,确保包含这些套接字的目录已添加到 IRONCLAW_DOCKER_BINDS,以便沙箱能够访问。

ironctl — 管理 CLI

控制平面 API 的轻量客户端。--addr 默认值为 http://127.0.0.1:8787;承载令牌来自 IRONCLAW_API_TOKEN 或 --token。

ironctl change submit  --kind <k> --group <g> --by <user>   # k: persona|enabled_tools|packages|wiring|permissions|mounts
ironctl change pending                                       # list changes awaiting a decision
ironctl change history                                       # all changes and their outcomes
ironctl change approve <id> --by <user>
ironctl change reject  <id> --by <user>
ironctl audit [--limit N]                                    # append-only gateway audit log
轻松定义 Agent

你无需了解工具名称,也不用手写 JSON。选择一个入门模板,稍作调整即可使用——一步完成,可通过 CLI 或 Web 控制台的 Agents → Create 构建器进行:

ironctl tools                                  # browse every built-in tool, grouped, with descriptions
ironctl agent templates                        # list starter presets (assistant, researcher, …)

# Guided wizard (run in a terminal with no flags): name → template → persona → tools → confirm
ironctl agent create

# Or one-shot/scriptable — template + a couple extra tools, persona override, default model:
ironctl agent create --name "Research Bot" --template researcher --tool schedule_task
ironctl agent create --name "Helper" --template assistant --all-tools --yes

ironctl agent list                             # all agents, with model + live session/channel counts
ironctl agent show research-bot                # persona, model, enabled tools, installed skills

将角色设为独立文档。 Agent 的角色不会塞进一个不透明的提示词,而是按关注点拆分为 IDENTITY.md(它是谁)、SOUL.md(个性/语气)和 AGENTS.md(它如何工作),并组合成系统提示词。可直接内联设置,也可以指定包含这些文件的目录(构建器会显示相同的三个字段):

ironctl agent create --name "Atlas" \
  --identity "You are Atlas, a research assistant for the data team." \
  --soul     "Curious and precise. You cite sources and admit uncertainty." \
  --instructions "Search before answering; prefer primary sources; summarize with links."

ironctl agent create --name "Atlas" --persona-dir ./atlas/   # loads IDENTITY.md / SOUL.md / AGENTS.md

这会通过一次面向操作员的直接写入,定义 Agent(名称 + 角色文档 + 模型 + 工具)。启用 Web/API 工具只会让 Agent 看见该工具——实际出站流量仍须通过网关访问已批准的主机,因此网络安全态势不变。

sandbox — 沙箱内的 Agent

由控制平面的隔离器启动,而非手动启动。它会接收会话密钥和队列路径,并运行推理循环。主要标志(cmd/sandbox):--inbound、--outbound、--key、--workspace、--heartbeat、--model-socket、--model-host、--model。

控制平面 HTTP API
方法与路径用途
GET /healthz存活状态(无需身份验证)
POST /v1/changes提交 ChangeRequest
GET /v1/changes/pending列出待处理的变更
GET /v1/changes/history列出所有变更
POST /v1/changes/{id}/decision记录批准/拒绝决定
GET /v1/audit读取审计日志

模型提供商

默认情况下,每个 Agent 都会与 Anthropic(Claude)通信。你可以将 Agent 指向 OpenAI 或 OpenRouter,也可以在 IronClaw 完全不持有任何模型密钥的情况下,通过操作员运行的凭据网关(例如 OneCLI)进行路由,由网关注入真实凭据。无论哪种情况,沙箱始终保持 network=none 且不含凭据:它仅通过主机模型代理的 Unix 套接字访问模型,而主机代理会对调用进行身份验证并强制执行出站允许列表。后端在主机侧按 Agent 组选择——沙箱永远无法选择或更改自己的提供商。

直接使用提供商密钥

在主机侧设置一个或多个密钥(守护进程环境变量,或 docker compose 使用的 .env)。仅当存在某个提供商的密钥时,才会将其上游主机加入允许列表:

export ANTHROPIC_API_KEY=sk-ant-...     # default / primary
export OPENAI_API_KEY=sk-...            # optional
export OPENROUTER_API_KEY=sk-or-...     # optional
通过 OneCLI 等凭据网关(ChatGPT/Codex——IronClaw 内不含密钥)

凭据网关是在主机本地运行的 HTTP CONNECT 代理,它持有真实凭据并按请求注入,因此控制平面和沙箱都不会看到模型密钥。 通过 OneCLI 使用 ChatGPT/Codex 账户为 Agent 提供支持,就是这种方式:IronClaw 的 codex 提供商使用 ChatGPT Codex Responses API(chatgpt.com),OneCLI 则附加 OAuth 凭据。

在主机上运行 OneCLI(默认地址为 127.0.0.1:10255),然后将模型代理指向它,并将其服务的主机加入允许列表:

# The gateway URL carries your per-agent OneCLI token as Basic userinfo — Go's HTTP
# client sends it as Proxy-Authorization on CONNECT. The gateway terminates TLS with
# its own CA, so upstream TLS verification is skipped (intended for a loopback gateway).
export IRONCLAW_MODEL_GATEWAY_URL="http://x:aoc_<your-onecli-agent-token>@127.0.0.1:10255"
export IRONCLAW_MODEL_GATEWAY_HOSTS="chatgpt.com"

# No ANTHROPIC_API_KEY needed — the gateway is the only credential path. Make the
# default backend Codex so every agent uses it out of the box:
export IRONCLAW_DEV_PROVIDER=codex
export IRONCLAW_DEV_MODEL=gpt-5.5

ironclaw-controlplane --api-addr 127.0.0.1:8787   # (+ your other flags)

设置网关后,不要再为它服务的主机设置密钥——网关就是凭据通道,控制平面不会为网关所服务的主机注入任何内容。在 docker compose 下,网关必须能从容器内访问,因此请使用 host.docker.internal:10255(Docker Desktop),或将 OneCLI 与控制平面置于同一个 Docker 网络中,而不是使用 127.0.0.1。

运行 100% 本地模型(Ollama、LM Studio、vLLM)——无需云端密钥

将 IronClaw 指向自托管的兼容 OpenAI端点,整个技术栈即可在你自己的设备上运行,无需任何云端凭据——没有任何数据会离开设备。Ollama、LM Studio、vLLM 和 llama.cpp 均提供 OpenAI /v1 API(Ollama 的地址为 http://localhost:11434/v1)。

ollama pull llama3.2                                # 1. run a model locally
export IRONCLAW_LOCAL_MODEL_URL=http://localhost:11434/v1
export IRONCLAW_LOCAL_MODEL=llama3.2                # 2. point IronClaw at it
ironclaw-controlplane --dev --api-addr 127.0.0.1:8787   # 3. chat — no API key

此配置会将本地主机加入允许列表,通过普通 HTTP 向其转发(这些服务不提供 TLS),并将其设为部署默认模型,因此所有未固定服务提供方的 Agent 组都会在本地运行。无需密钥;只有在少数需要密钥的本地服务(例如受保护的 vLLM)中,才需设置 IRONCLAW_LOCAL_MODEL_KEY。使用 docker compose 时,控制平面容器必须能访问该服务,因此请使用 http://host.docker.internal:11434/v1(Docker Desktop),而不是 localhost。 完整教程:运行搭载 100% 本地模型的 IronClaw(Ollama)。

为每个 Agent 选择服务提供方

IRONCLAW_DEV_PROVIDER / IRONCLAW_DEV_MODEL 为所有未固定服务提供方的 Agent 组设置部署级默认值(环境变量名称保留 DEV_ 前缀,但适用于整个部署)。如需为每个 Agent 单独选择——这与其他配置变更一样,需经网关批准:

ironctl agent create --name "Codex Bot" --provider codex  --model gpt-5.5
ironctl agent create --name "GPT Bot"   --provider openai --model gpt-4o
ironctl agent create --name "Local Bot" --provider local  --model llama3.2   # uses IRONCLAW_LOCAL_MODEL_URL

有效的 --provider 值:anthropic(默认)、openai、openrouter、codex、gemini、 vertex、local(自托管的兼容 OpenAI 端点——Ollama/LM Studio/vLLM/llama.cpp),以及 mock(用于演示和测试的确定性离线后端)。每个值都会映射到经 model-proxy 允许列表批准的上游服务;codex 的目标为 chatgpt.com,默认使用 gpt-5.5 模型;local 则继承 IRONCLAW_LOCAL_MODEL_URL 中的环回主机。

配置

  • 状态存储在 --state-dir 下:持久化的网关变更存储(重启后仍保留)、只追加的 JSONL 审计日志,以及主机密钥库。
  • 密钥仅保留在主机上。模型凭据(Anthropic / OpenAI / OpenRouter 密钥,或 OneCLI 等凭据网关——参见模型服务提供方)由主机 modelproxy 应用于发往模型的调用;沙盒无法访问该凭据,且其 network=none。主机会生成并持有每个会话的 256 位密钥,并在启动时通过 tmpfs 将其交给沙盒——绝不通过环境变量传递,也绝不写入镜像。
  • **网状网络。**将 --api-addr 绑定到 Tailscale 接口,并在所有其他接口上对 API 端口进行防火墙限制。参见 deploy/README.md。

开发

make build     # go build ./...
make test      # go test ./...
make vet       # go vet ./...
make fmt       # gofmt -w .

在仅使用标准库的代码树上,所有测试均可通过(加密 SQLite 的 CGo 路径除外)。黑盒行为测试套件位于 test/parity/,仅通过可观测接口(两个队列和 API)测试路由扇出、交互模式、会话解析、投递去重、网关强制审批流程,以及跨挂载实时轮询规范。

冻结的契约。internal/contract/** 是双方导入的唯一接口,并且处于冻结状态:要修改它,必须在 docs/contract.md 中提交带日期的 RFC,并获得两位 CODEOWNERS 的批准。此处发生偏差会在运行时表现为静默解密失败或路由失败,而非构建错误——这正是严格冻结的原因。参见 CONTRIBUTING.md。

仓库布局

ironclaw/
  cmd/
    controlplane/   # host daemon entrypoint
    sandbox/        # in-sandbox agent entrypoint
    ironctl/        # admin CLI
  internal/
    contract/       # FROZEN SEAM — shared types, schema, crypto, gateway protocol
    host/           # control-plane: api gateway isolation router delivery sweep keys channels modelproxy registry scheduling queue
    sandbox/        # sandbox: loop provider tools queue
  api/              # control-plane API reference
  deploy/           # host install script + notes (gVisor, containerd, Tailscale, systemd)
  docs/             # architecture, threat-model, contract (+ RFC log), building
  test/parity/      # black-box behavioral suite over the queues + API

安全性

IronClaw 假设沙箱中的 Agent 可能已遭入侵,并通过设计边界确保其无法提升权限。完整的威胁与缓解措施表见 docs/threat-model.md。要点如下:

  • 使用编译后的 Go,沙箱中没有解释器 → Agent 无法读取或修改自身源码。
  • 所有配置变更都必须经过网关 → 确定性验证器链 → 人工审批 → 幂等应用。不存在未经审批的操作路径(从设计上杜绝了旧版 script 字段导致的远程代码执行漏洞类别)。
  • 按会话加密队列;通过三种方式强制实施最小权限访问(Go 接口隔离、PRAGMA query_only、只读 OS 绑定挂载)。
  • 使用 network=none 沙箱;模型调用只能经由主机代理,并受目标地址允许列表限制。

**供应链问题,我们以反面案例的形式记录:**我们发布的某个容器镜像带有两份绿色的 SLSA 来源证明,但其中只有一份是真的。我们无法撤回该镜像,因此将此事记录下来: 我们的某个容器镜像带有两份绿色的来源证明,其中只有一份是真的。 文章介绍了摘要,说明了为何绿色的 gh attestation verify 是必要但不充分的,以及你应该检查自己发布流水线中的哪些内容。

如需报告漏洞,请提交私密安全公告,而不要公开创建议题。

路线图

持续更新的路线图位于文档网站: 迈向 1.0 — 这是唯一可信来源。它追踪产品迈向 1.0 的进程(公开发布、Web UI、频道和供应链信任),并提供一目了然的状态表以及与同类产品的比较。若要查看面向贡献者的简版路线图,了解发展方向、1.0 的含义以及欢迎协助的主题,请参阅 ROADMAP.md。下方清单是安全后端(Wave 0–5)的工程构建日志,以及后续的加固工作。

  • 架构和威胁模型
  • 可编译的骨架:冻结的契约、控制平面和沙箱存根、CI
  • 控制平面(路由、网关、隔离规范、密钥托管、交付、清理),基于内存后端
  • 沙箱(Agent 循环、模型提供方、队列访问、工具)
  • 加密 SQLite 队列绑定(RFC-0001)——实时加密的会话级队列
  • 加密后端上的跨挂载实时轮询集成
  • 沙箱 rootfs 配置(可插拔)+ 持久化的群组级工作区/记忆 + 镜像信任策略验证
  • 具体的频道适配器:Telegram、Slack、Discord
  • 注册表管理 HTTP API + ironctl 资源子命令
  • 交互式 ask_user_question + 任务管理工具(列出/取消/暂停/恢复/更新)
  • 端到端生命周期集成测试(通过真实堆栈运行的模拟隔离器/提供方)

生产环境加固(Wave 4)——已整合至守护进程:

  • 持久化/可插拔的主密钥托管(文件封装的密钥库 + KMS 接口)——已接入
  • Prometheus 指标(/metrics)和结构化(slog)日志记录——已接入
  • 主机重启崩溃循环退避 + 沙箱提供方退避/熔断器——已接入
  • 模型代理速率上限 + 审计日志记录 + 密钥脱敏——已接入
  • 守护进程接线——上述子系统已整合至 cmd/controlplane
  • 生产部署单元:systemd 服务 + launchd plist、安装程序、容器镜像、docker compose
  • 在入口点接入 API 服务器加固选项(TLS、速率限制、请求体大小限制、/readyz 门控)——api.With* 选项已存在,但尚未接入
  • 在已配置且使用签名镜像的环境中实际启动 runsc

超越参考设计——已完成:

  • 面向获准外部主机的出口代理——默认拒绝、全程审计,且沙箱保持封闭的 network=none(通过 unix socket 由主机代理);为 web_search 工具提供支持
  • 在相同的加固版 Isolator 接口后接入 Kata Containers 隔离后端
  • Agent 间(a2a)消息传递 + 需审批的 create_agent(RFC-0004)
  • 多个模型提供方——Anthropic、OpenAI、OpenRouter——可按 Agent 群组选择
  • MCP 服务——由主机代理,并为每个工具提供经人工审批的授权
  • 位于 /ui/ 的私有、仅限网状网络访问的 Web 控制台
  • 覆盖首批三个频道之外的更多频道——WhatsApp、Email/SMTP、Matrix、Google Chat、Microsoft Teams、Signal、iMessage 和 Webhook,以及产品内的 Web 聊天体验场景(共十二种交付渠道)

需经设计批准(已构建,默认关闭):

  • 网关自动审批策略 + RBAC——已实现为验证器/审批器,但默认不启用:在操作员选择启用之前,唯一生效的路径是强制要求人工审批

社区

有问题、有想法,或者想问“这是个错误,还是我用错了?”——欢迎到 **GitHub 讨论区**交流。这里是项目的 问答、设计讨论和成果展示中心,也是维护者优先答疑的地方。

  • 刚接触项目,或想全面了解? 请阅读 文档网站——架构、威胁模型、快速入门、 通道和技能,均可在此一站式浏览。
  • 发现错误或有功能请求? 请提交问题。
  • 要报告安全问题? 请不要提交公开问题——请按 SECURITY.md 中的说明操作。
  • 想贡献代码? 可以从 适合新手的问题开始, 或筛选出 可认领的问题 (good first issue + help wanted)。这些问题规模小、边界清晰,并有导师指导;每个问题 都带有标准标签,供 up-for-grabs.net 和 goodfirstissue.dev 等贡献者看板索引。最适合入门的是两个边界最清晰的子系统—— ironctl scan (隔离评分;internal/host/scan/)和 隔离评分数据集(examples/isolation-survey/, 仅涉及数据变更)。工作流程请参阅贡献指南。
  • 第一次来这里? 所有与项目互动的人都应遵守我们的 行为准则——彼此友善、尊重。

整个社区都在 GitHub 上——无需注册 Discord 或 Matrix。 讨论区是实时交流渠道:订阅相应类别以便跟进动态,并关注仓库以接收公告。

贡献

请参阅 CONTRIBUTING.md,了解契约冻结规则、代码布局 (控制平面和沙箱目录树均基于冻结接口构建)、如何报告漏洞 (SECURITY.md)、我们的行为准则,以及如何提交拉取请求。 刚加入?可以挑选一个适合新手的问题 (或从 help wanted 中挑选可认领的问题)。 除 GitHub 本身外,无需账户或注册。

许可证

IronClaw 采用双重许可——请参阅 LICENSING.md:

  • GNU AGPLv3 适用于开源用途。将修改后的 IronClaw 作为网络 服务运行会触发 AGPL 的著佐权要求——你必须向用户提供对应的源代码。
  • 商业许可证 适用于闭源/专有用途,无需遵守 AGPL 义务——请通过 LinkedIn 联系维护者(Omer Zamir 或 Topaz Aharon)。

© 2026 IronSecCo

评论

支持 Markdown

第一次接触 MCP?

从协议是什么,到在客户端里装上第一个服务,这几条回答覆盖了大多数入门问题。

一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。