cjohnstoniv/wardyn

# Wardyn [](LICENSE) [](#状态) [](go.mod) [](https://github.com/cjohnstoniv/wardyn/actions/workflows/ci.yml) **面向编码 agent 的开源治理控制平面 — identity、controls 和 audit 即产品；sandbox 是一种可插拔的商品。** Wardyn 治理工作负载的运行 identity 和 token：一个 *wardyn* 授权一项具体且受限的 scope 操作 — 这正是 broker 所生成的。 一切均为 Apache-2.0。没有 `enterprise/` 目录。也没有托管后端 — 它要么运行在你的基础设施上，要么根本不运行。CNCF Sandbox 是其治理目标。  ## Wardyn 是什么 如今的编码 agent (Claude Code、Codex CLI 及其后续产品) 继承了其启动时所使用的完整开发者凭证。被提示词注入的 agent、被投毒的依赖项或被攻陷的 MCP server 都会继承相同的凭证 — 相同的代码仓库、相同的云访问权限、相同的爆炸半径。Wardyn 是位于人类操作者和运行中的 agent 之间的治理层。它提供： - **单次运行 identity。** 每次 agent 执行都会获得一个 SPIFFE ID (`spiffe:///agent-run/`)，这与生成它的人类身份不同。人类的 `sub`、agent 运行的 `act` 和负责任的 `sponsor` 在每个 token、每次提交和每个审计事件中共同传递。 agent 从未在归因链中取代人类 — 它只是被添加到其中。**[已交付]** (嵌入式 JWT-SVID 签发器；基于 SPIRE 的签发器为 **[v0.5+ — 计划中]**。) - **由 broker 生成的受限凭证。** agent 永远不会持有凭证。 token broker 按需生成短生命周期、仅限 repo 范围、 权限降级的凭证，并在代理端注入，因此 agent 进程永远看不到 bearer token。需要审批的授权在验证该特定 运行+scope 的 `APPROVED` (已批准) `ApprovalRequest` 的同一个 Postgres 事务中生成 — 在审批者看到的范围和实际生成的范围之间没有任何扩大。 **[已交付]** - **分层 egress。** L0 结构性 **[已交付]** (无默认路由；sandbox egress 仅通过 `wardyn-proxy`) → L1 默认拒绝 L3/L4 (nftables / NetworkPolicy) **[v0.5+ — 计划中]** → L2 `wardyn-proxy` **[已交付]** (L7 domain 白名单，方法规则，代理端凭证注入，首次使用 审批) → L3 MCP/tool gateway **[v0.5+ — 计划中]**。`HTTP_PROXY`/ `HTTPS_PROXY` 确实设置在了 sandbox 中 (为了客户端兼容性)，但是 有文档记录的 Copilot 环境变量绕过类别在 L0 层面受到 *结构性* 的防御：每次 运行的网络都是无网关的 (`Internal:true`)，因此忽略 代理环境变量的 agent 没有默认路由，什么也访问不到 — 唯一离开宿主机的路径 是 `wardyn-proxy` sidecar。这种绕过是通过路由的缺失而设计消除的，而不是 因为环境变量的缺失。 - **三流只追加审计。** 控制平面事件日志 (Postgres trigger 阻止 UPDATE/DELETE) **[已交付]**，通过 `wardyn-rec` 进行的 PTY 会话重播 **[已交付]**，以及 eBPF/Tetragon ground-truth (基准真相) 流 (来自宿主机 sensor 的 `kernel.*` 事件，通过 `run_id` 关联) **[已交付]**。 (ground-truth 流的控制平面管道和如实降级 (honest-degradation) 功能已经交付 并经过单元测试；其 Tetragon 事件映射器已针对文档记录的导出格式进行了验证，但尚未 针对实时的 Tetragon 部署进行验证 — 参见 `threatmodel/` 遗留问题 #12。) ground-truth 流是**检测，而非预防** — 它会标记 `ld-linux`/`mmap` 加载器绕过行为，而不是声称阻止 exec — 并且 **能够如实降级**：没有 sensor 的宿主机会报告 `/healthz` `ebpf_groundtruth=unavailable`，并且在 CC3/Kata 客户机内部它是盲目的 (一次性 `kernel.sensor.blind` 事件，由 `wardynd` 为 每次 CC3 运行自动发出，使得该缺口可见)。每个流都以 `run_id` 为键。 SIEM 导出以 JSON webhook/syslog/file 形式交付 **[已交付]**；OTLP 和 OCSF v1.8 `ai_operation` sink 为 **[v0.5+ — 计划中]**。审计导出是免费的，永远不会被付费墙限制。 - **隔离级别 (Confinement Classes)。** 在 UI 中，它们以友好的名称显示： **Fence** = CC1，**Wall** = CC2，**Vault** = CC3。CC1/Fence (强化的 共享内核 runc) **[已交付]**，CC2/Wall (gVisor 用户态内核 — 默认) **[已交付]**，CC3/Vault (Kata microVM) **[实验性]** — 已在注册了 Kata runtime 的 Docker daemon 上进行了端到端的实时验证 (需要 `/dev/kvm`；在 Docker Desktop 上不可用)；打包/GA 强化是 路线图项目。Policy 可以强制要求最低级别；控制平面拒绝 在无法满足该策略的底层上调度运行。 可在任何运行 Docker 的地方运行。Fence 仅需 Docker — 这就是最低要求。Wall 是默认选项，需要在宿主机上安装 gVisor 的 `runsc`。Vault 是最强等级，需要 `/dev/kvm` 外加 Kata runtime。选择你的硬件 支持的最低要求 (`wardyn setup wall` / `wardyn setup vault` 会打印出针对这台机器的 确切步骤)；控制平面拒绝在你的策略的最低标准之下调度运行。 ## 架构一览