尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

IronClaw 内核权威边界(Authority Perimeter):九阶段权限管线、密封见证与逐阶段 Fail-Closed 安全设计解析

发布时间:2026/9/24 14:50:38

资讯中心
01
ARTICLE

IronClaw 内核权威边界(Authority Perimeter):九阶段权限管线、密封见证与逐阶段 Fail-Closed 安全设计解析

IronClaw 内核权威边界(Authority Perimeter):九阶段权限管线、密封见证与逐阶段 Fail-Closed 安全设计解析
人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载本文以 crates/kernel/CLAUDE.md 为骨架结合仓库源码与架构测试系统拆解 IronClaw 的 kernel 层它为什么是一个安全边界而非普通 crate 集合九个 crate 如何各自独占权限管线的一个阶段Authorized、EffectiveTrustClass等密封见证如何保证不可伪造以及每个阶段 fail-closed 规则在源码与测试中的具体落地。读完你可以看懂任何一条特权效果特权效果从准入到受管执行的完整调用链在新增或修改内核 crate 时对照架构测试清单自查并正确回答这段代码应不应该放进 kernel。1. Kernel 是什么安全边界而不是一个 crateIronClaw 把内核定义为权威边界authority perimeter而不是一个可被普通依赖关系绕过的大型 crate。文档给出两层判定层Layerkernel 位于七层阶梯contracts substrates runtimes kernel loops products app中的第四层。九个 crate 的Cargo.toml都声明了[package.metadata.ironclaw] layer kernel见 ironclaw_trust/Cargo.toml 等九份清单。依赖方向kernel 只能依赖contracts、substrates、runtimes及同层兄弟loops、products、app全部通过 kernel 定义的端口下行调用绝不允许 kernel 反向依赖上层。为什么是九个 crate 而不是一个大 crate文档给出明确理由每个阶段都是一个可被独立消费的契约且有自己的 fail-closed 规则。如果合并就会把编译器可证明的阶段隔离私有 mutator 在 crate 外不可见降级为模块纪律。因此调用方——loop、extension、product surface——永远不直接触碰阶段而是调用膜membraneironclaw_capabilities由膜去调用其余八个 crate。2. 九个 crate 的职责清单CrateCharter一句话什么时候该看它ironclaw_trustrequested→effective trust ceiling 策略引擎sealed问题在于这个包可以被信任到什么程度ironclaw_authorization默认拒绝的 grant 匹配 capability-lease 状态机问题在于某条 grant/lease 是否恰好覆盖这个效果ironclaw_approvals精确调用的人为同意pending 记录 → 指纹化 lease 或持久化拒绝人工/策略决定必须变成膜可执行的东西ironclaw_resources对每个预算维度做 reserve → execute → reconcile-or-release 记账有成本/配额限制的工作需要在运行前决定容量ironclaw_runtime_policy纯函数(deployment, profile, org policy) → EffectiveRuntimePolicy 每个 capability 的 lane 规划零 I/O部署姿态必须选择 lane/后端且不做任何 I/Oironclaw_capabilitiesCapabilityHost 膜六个调用方工作流 授权折叠authorization fold任何调用方想要特权效果——这是唯一入口ironclaw_processes唯一持久化生命周期权威row-native journal supervisor工作需要被 claim、lease、heartbeat、恢复或查询它在干什么ironclaw_turnsturn 准入one-active-run、幂等 loop 退出校验对话工作必须变成持久化的或 loop 的退出声明必须被检查ironclaw_host_runtime受管服务 封闭 lane 执行器obligations、egress、secret staging、dispatch 组合一个被授权的见证必须真正运行且在受管之下3. 特权效果管线与阶段归属每一个特权效果都经过同一套有序阶段其中turns与processes作为准入/生命周期权威分别夹住管线的两端其余七个 crate 组成膜。阶段发生了什么归属 crate准入Admission请求变成持久化的已准入工作每个线程至多一个活跃 run幂等ironclaw_turns认领执行Claimed execution已准入工作被认领、lease、heartbeat 跟踪至终态ironclaw_processes信任上限Trust ceiling请求的信任解析为宿主校验后的有效上限ironclaw_trust授权Authorization上限 grants 解析为 allow / deny / require-approvalironclaw_authorization同意Approvalrequire-approval 解析为有作用域的、指纹化的 lease 或持久化拒绝ironclaw_approvals预留Reservation运行前预估成本/容量并预留运行后对账ironclaw_resources策略规划Policy planningdeployment/org 策略选择 lane 与执行姿态ironclaw_runtime_policy膜The membrane之前所有阶段折叠进一个 sealed 决策Authorized见证ironclaw_capabilities受管执行Mediated execution见证只授权恰好一个 lane 调用——受限挂载、staged secrets、有作用域 egress、脱敏证据ironclaw_host_runtime关键规则不允许跳阶段no stage skipping——first-party 是上限而非旁路。更高的信任上限依然需要显式 grants、有作用域挂载、lease、预算和 obligations 处理走和其他调用方完全相同的膜。项目自带的一切以及任何在高信任等级运行的东西都不能以其他路径触达特权效果。4. 四个密封铸币Sealed Mints不可伪造的证明管线中四个制品证明某个阶段确实运行过。每个制品只有一个受认可的铸币方mint边界之上的任何东西都无法伪造。密封制品仅由谁铸造如何密封Authorized见证ironclaw_host_api::authorizedCapabilityAuthorizergrant trait 见 :61零尺寸AuthorizationGrant(())见 :75Authorized见 :106ironclaw_capabilities——唯一的CapabilityAuthorizer实现host/mod.rs:107grant 门控构造 架构测试 reborn_authorized_seal_ratchet.rs 中capability_authorizer_is_implemented_only_by_the_kernel有效信任上限EffectiveTrustClassironclaw_trust::TrustPolicy::evaluate——特权变体没有公开构造函数也没有Deserializedecision.rs:18-33crate 作用域可见性host_api 的#[serde(skip_deserializing)]守护线上wire半边指纹化同意 leaseironclaw_approvals::ApprovalResolver签发进ironclaw_authorization的 lease store决定在 lease之前持久化lib.rs:240签发端口是公开的所以铸币限制靠 charter 阶段BoundaryRuleapprovals 不得命名 capabilities/host_runtimekernel 之上的任何东西不得绕过膜命名 store crate——不是类型密封已验证入站证据位于ironclaw_extension_hostT2的入站验证器——在此目录之外但在概念边界之内kernel 把它作为 sealed 输入消费架构测试 reborn_sealed_evidence_mint_ratchet.rs用grep -cF #[test] crates/app/ironclaw_architecture_tests/tests/reborn_sealed_evidence_mint_ratchet.rs可复算测试数——一个对 mint 函数归属、退役 feature 缺席的独占实现者普查ironclaw_extension_contracts的verified_inbound_seal4.1Authorized见证的结构性密封是怎么做到的从 authorized.rs 源码可以看清这个类型密封 测试密封的双层机制字段私有Authorized的所有字段invocation、descriptor、lane、mounts、reservation、deadline都是私有的没有公开字段构造函数。grant 门控构造唯一铸造路径是Authorized::seal它消费一个AuthorizationGrant而AuthorizationGrant是零尺寸见证唯一构造函数是CapabilityAuthorizer::authorization_grant。因此不持有impl CapabilityAuthorizer就无法构造Authorized。测试密封Rust 无法跨 crate 表达纯类型密封host_api定义类型但唯一合法铸币方ironclaw_capabilities是另一个 crate所以 reborn_authorized_seal_ratchet.rs 用 workspace 级扫描把impl CapabilityAuthorizer限制在 kernel crate 内且带自检防止扫描本身静默退化。见证还具有单次使用不实现Clonedispatch()消费它未派发的路径显式调用Authorized::abort释放预留绝不依赖Drop做异步 I/O与截止期限约束is_expired在超过冻结事实的最短寿命——同意/凭证 lease——的截止点后 fail-closed两个性质。dispatch()只接受Authorized因此未授权的调用在结构上就无法被派发。5. 什么永远不该放进 kernel每条排除规则都指名了替代归属这是判断代码归属的权威清单由 product/loop/extension crate 持有的 kernel 阶段。九个阶段只在这里kernel 之上的 crate 想要阶段行为就调用膜。Loop 策略 →crates/loop/product 工作流/UX →crates/product/可安装行为 →crates/extensions/。向上依赖。没有 kernel crate 依赖loops、products、app。上层只能通过 kernel 定义的端口下行例如ironclaw_turn_runner/ironclaw_host_runtime注册ProcessExecutor——端口定义在低层、实现在高层绝不反过来。在别处铸造 sealed 证据。见铸币表。为Authorized、EffectiveTrustClass或已验证入站类型新增构造函数、Default、Deserialize或 test-only 逃生门是安全回归而非便利。Prompt 组装、任务编排、技能选择、渠道呈现。userlandcrates/loop/、crates/product/、crates/domains/ironclaw_skills。厂商特定行为。厂商名位于crates/extensions/packages/*、ironclaw_llmproviders 及其他 §8.1-rule-4 归属处——绝不在 kernel crate由reborn_extension_specificity.rs扫描。Lane 执行机制。容器/WASM/MCP 机制位于crates/lanes/ironclaw_host_runtime只持有封闭执行器和适配器接缝bollard/rcgen是 lane 家族的依赖不是 kernel 的。存储后端实现。后端位于crates/substrates/ironclaw_filesystem/ironclaw_libsql_runtime/crates/events/ironclaw_event_storekernel crate 消费挂载目录ironclaw_host_runtime残留的直接 driver 依赖由reborn_persistence_driver_boundary.rs冻结为只减不增。kernel crate 输出中的原始载荷。错误、事件、快照、日志里不得出现 secrets、宿主路径、后端错误细节或未脱敏的用户内容——脱敏义务在ironclaw_host_runtime。6. 逐阶段 fail-closed 规则与执行证据默认全拒default-deny贯穿始终缺失前置条件时隐藏或拒绝 capability绝不降级。下表是文档给出的逐阶段规则与强制者阶段Fail-closed 规则强制 / 钉住者准入turns活跃线程上第二次 submit → busy/幂等重放绝不二次运行LoopExit是声明任何持久化迁移前必须对照宿主铸造证据校验coordinator.rs、loop_exit.rs由仓库根tests/integration/套件驱动生命周期processes终态只写一次——迟到完成不能覆盖journal_store/state.rs:603-661 的终态守卫结果先于终态存储store 查询从不枚举集合reborn_process_storage_scan_gate.rsjournal 契约套件信任trust特权上限在TrustPolicy::evaluate之外不可获得降级在较低决定返回之前同步发布到InvalidationBus只能通过mutate_with变更policy.rs:269per-source mutator 为pub(crate)——sources.rs:144-570编译器可见性 crate 测试授权authorization无匹配 grant ⇒ deny指纹化 lease 是单赢家 claim-then-consumelib.rs:268-291永不变成 ambient grantlib.rs:308-313crate 测试BoundaryRule同意approvals决定在 lease 签发之前持久化lib.rs:240拒绝是持久化的且不签发 leasecrate 测试reborn_origin_gate_matrix_ratchet.rs 冻结哪些 capability 可跳过此阶段预留resources预留失败——包括存储失败——是拒绝绝不先进行后补账resource_governor_contract.rsfilesystem_resource_governor_fails_closed_then_recovers_after_delta_append_error、..._store_fails_closed_on_byte_only_backend、reserve_denies_when_usd_limit_would_be_exceeded策略规划runtime_policy非法(deployment, profile)→ResolveError而非静默降级resolver.rs:129宽松*Yolo*profile 要求显式披露确认resolver.rs:61对ProcessBackendKind::None的过程效果 →PlannerErrorplanner.rs:140crate 测试膜capabilities授权拒绝或未支持/失败的 obligation 在 dispatch、进程启动或 lease claim之前失败见证只由折叠铸造且只消费一次reborn_authorized_seal_ratchet.rscrate 测试受管执行host_runtime未配置的 lane fail-closed凭证只附着于 HTTPS 或字面loopback 主机D-Rstaged secrets 一次性无已验证租户沙箱 ⇒ process/shell capability 隐藏surface.rs且被 planner 拒绝——绝不是宿主 shellhost_http_egress_refuses_to_attach_a_credential_over_plaintext_http 与..._attaches_a_credential_over_literal_loopback_httptests.rs:6136.1 两个值得展开的落地细节同意阶段先持久化后签发F2 审计修复。在 ironclaw_approvals/src/lib.rs:240 的注释中可以看到设计演进旧顺序先签发 lease 再批准、失败时尽力回滚留下一个窗口——瞬时存储错误可能产生一个 lease 已存活但批准状态仍为Pending的记录。新顺序把批准记录作为事实权威一旦翻转为Approved后续任何 lease 重签都是对已决定请求的可恢复操作已批准但无 lease窗口由retry_lease_issue_for_dispatch/retry_lease_issue_for_spawn恢复。信任变更的编译期保证AC #6。policy.rs:269 的mutate_with把评估前 → 暂存变更 → 提交 → 评估后 → 同步发布TrustChange→ 释放门编排硬编码进方法本身闭包通过SourceMutators句柄暂存变更而不触碰活跃源状态错误则丢弃暂存任何真正降低信任或收缩授权上限的变更都无法绕过发布因为编排是编译期保证的。EffectiveTrustClass的authority_levelSandbox0、UserTrusted1、FirstParty/System2见 decision.rs:80用于区分降级与同类变更——FirstParty与System同为 2 级但属不同特权种类监听方仍须撤销。7. 规则清单与架构测试的强制方式每一条都是可运行的任何依赖或 API 变更后请运行架构套件cargo test -p ironclaw_architecture_tests层矩阵。九个 manifest 都声明layer kernel七层阶梯由 reborn_dependency_boundaries.rs 检查异常登记表为空LAYER_MATRIX_EXCEPTIONS []基线 0——kernel→loops 或 kernel→products 的边不可能落地。每 crate 禁止边。reborn_dependency_boundaries.rs中七个 cratetrust、authorization、approvals、resources、processes、turns、capabilities的BoundaryRule钉住阶段顺序——例如authorization不得命名approvalscapabilities不得命名host_runtime。ironclaw_runtime_policy与ironclaw_host_runtime没有自己的BoundaryRule由矩阵和同层清单执行。同层边是登记的不是自由的。reborn_same_layer_edge_inventory.rs 以等式形式钉住全部21条 kernel→kernel 边每条带 owner 与决策工作流——新边失败移除的边必须在同一 PR 中离开清单。见证密封。capability_authorizer_is_implemented_only_by_the_kernel——CapabilityAuthorizer只由ironclaw_capabilities实现workspace 内别无他处且带自检。证据铸造密封。reborn_sealed_evidence_mint_ratchet.rs 做 mint grant trait 的独占实现者普查、mint 函数只能由 owner 命名、退役的host-auth-mintfeature 在所有 manifest/脚本/workflow 中保持缺席。kernel 永不触达组装根。reborn_composition_boundaries.rs 的no_substrate_crate_depends_on_composition_root列出九个 kernel crate 中的八个ironclaw_runtime_policy也不在列——实测如此层矩阵仍禁止该边。driver 保管。reborn_persistence_driver_boundary.rs 按 crate 允许清单化 DB driver只减不增ironclaw_host_runtime被点名残留长期收窄目标而非 charter。同意门数据保持诚实。reborn_origin_gate_matrix_ratchet.rs 冻结经评审的、模型可无门调用的 capability 种子集并要求每个声明的 capability 具备格式良好的origin_gate_matrix。家族目录不是编译或信任单元。强制事实是每个 crate 的layer元数据家族归属只是所有权与可发现性。crate 在家族间移动不是重命名——目录携带完整包名。新增第十个 crate 之前命名你的阶段与 fail-closed 规则或给出多于一个生产实现的原因——否则它只是九个 crate 之一的模块families/kernel.md收尾规则。新 crate 落地需带README.md、上表一行、layer 元数据且scripts/ci/check-target-tree.py绿灯。8. 跨出本家族上下层边界如何协作向下到crates/contracts/ironclaw_host_api、ironclaw_loop_contracts、ironclaw_extension_contracts——共享词汇与 kernel 为上层定义的端口turn/scope/id 词汇位于host_api::turn绝不放这里。向下到crates/substrates/——kernel 中介的机制ironclaw_filesystem挂载、ironclaw_secrets加密保管、ironclaw_networkegress 传输、ironclaw_safety。substrate 从不决定权威只有host_runtime及各 crate 注明的 stores直接触碰它们。向下到crates/events/ironclaw_event_log——持久化审计追加。向下到crates/lanes/ironclaw_wasm、ironclaw_mcp、ironclaw_sandbox——仅从ironclaw_host_runtime出发用于构造封闭执行器的适配器。Lane 接收 sealed 工作和受管服务它们从不授权。向上到crates/loop//crates/product/——绝不作依赖。loop 层注册进程执行器并满足退出证据端口product 调用ProductSurface→ 膜。如果需要在上面获取行为在这里定义端口让上层实现它。9. 查阅与延伸阅读crates/kernel/CLAUDE.md —— 本文骨架来源家族规范正文。docs/internal/reborn/target-architecture/families/kernel.md—— 家族规格设计记录文档与代码不一致时代码及其门优先两者都会得到带日期的更正。PROPOSAL §6.5.1–§6.5.10各 crate 契约、§7信任迁移 T1–T8、§8依赖模型、§11.2机械强制、§12.13 D-Rloopback 例外与 D-S生命周期权威再验证。docs/internal/reborn/target-architecture/ws12-security-audit.md—— 2026-08-05 对证据铸造、secrets、verifier 与 D-R 接缝的对抗性再验证结论HOLDS / HOLDS-WITH-RESIDUAL残留记录于该文。.claude/rules/safety-and-sandbox.md—— 本家族实现的整体安全框架。docs/internal/reborn/guidance-conventions.md—— 说明本文档是什么、不是什么。架构测试基座crates/app/ironclaw_architecture_tests/tests 下的reborn_*_ratchet.rs系列是上述所有强制的可运行证据。赞分享人工智能AI 应用交互助手AI Agent【免费下载链接】ironclawIronClaw is an Agent OS focused on privacy, security and extensibility项目地址https://gitcode.com/gh_mirrors/iro/ironclaw点击查看免费下载相关推荐IronClaw 权威词汇层 ironclaw_host_api零依赖契约 crate 的工作规则、密封证据与安全边界解析IronClaw 权威词汇层 ironclaw_host_api零依赖契约 crate 的工作规则、密封证据与安全边界解析 ironclaw_host_api人工智能AI 应用交互助手AI AgentFerretDB 聚合管道阶段Aggregation Stages完全指南从 $match 到 $unwind 的九个核心阶段FerretDB 聚合管道阶段Aggregation Stages完全指南从 $match 到 $unwind 的九个核心阶段 聚合管道Aggregat后端数据库文档数据库Maka Computer Use Foundation Contract 深度解析从观察权威到执行所有权的 fail-closed 设计Maka Computer Use Foundation Contract 深度解析从观察权威到执行所有权的 fail closed 设计 本篇技术指南围绕AI Agent人工智能AI 应用桌面应用工具调用AI 评测CLIAgent 评测MCP Clients上一篇Wand-Enhancer 使用指南免费 WeMod 本地补丁工具解锁 Pro 与手机远程的完整教程下一篇视频到视频转换技术深度解析vid2vid框架的完整重构指南创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。