面向 Linux 系统、应用程序、自主软件和 AI 智能体的内核强制权威与运行时安全。
KERNHELM 是一种通用操作系统安全基板，它在软件栈中实际可强制的最低层级——位于 AI、应用程序、服务和普通用户态之下——设置了一道硬性权威边界。
其目的用一句话即可说明：
软件可以请求权力。但它绝不能制造授予该权力的权威。
KERNHELM 将关于受管控特权效果的最终决策移入内核边界。
该边界之上的软件可以极其强大。
它可以规划。
它可以推理。
它可以自动化。
它可以管理应用程序。
它可以防御机器。
它可以作为自主 AI 智能体持续运行。
它甚至可以是一种先进的人工智能。
但能力本身并不产生许可。
这种架构上的分离在设计上是绝对的：
请求某种效果的一方，不得同时是决定其是否有权造成该效果的一方。
用普通的安全语言来说，KERNHELM 试图超越这样的提问：
“我们信任这个程序吗？”
转而提出：
“这个确切的尝试效果是否拥有有效权威？”
这一区别正是该项目的核心。
对于 AI 智能体安全，同样的原则可以换一种方式表述：
AI 智能体可以决定它想做什么。但该决定绝不能制造使其得以实现所需的权威。
KERNHELM 不是 AI 沙箱。
它不是应用容器。
它不是针对某个特定程序的权限包装器。
它不是提示注入检测器。
它不是模型行为分类器。
它不是 AI 终止开关。
它不是传统的用户态策略引擎。
它也不仅仅是另一个运行于其所约束软件旁边的 AI 智能体访问控制层。
它是面向操作系统本身的通用权威架构。
沙箱主要回答的是：
这个程序被允许在哪里运行？
KERNHELM 则提出一个更深层的问题：
造成这一特权效果的权威究竟从何而来？
一个有用的简要表述是：
沙箱约束软件可以在哪里运行。KERNHELM 约束权威可以来自哪里。
即使将 AI 从机器中完全移除，KERNHELM 依然成立。
浏览器、守护进程、包管理器、辅助进程、游戏、驱动工具、恶意载荷、通过被攻陷软件行事的远程攻击者，或人工智能，最终都会遇到同一个底层权威问题。
这就是为什么 KERNHELM 是一种通用安全基板，而不仅仅是 AI 遏制系统。
AI 只是该架构最清晰、也可能最强大的应用之一。
现代 AI 智能体安全、智能体式 AI 安全和 AI 运行时安全越来越依赖如下机制：
这些机制都可能有用。
KERNHELM 追问的是它们之下会发生什么。
如果一个自主 AI 智能体被攻陷、被操纵、被提示注入、被错误配置，或逃逸了更高层的遏制机制，该事件是否应自动授予由此产生的软件广泛的机器权威？
KERNHELM 的回答是不。
沙箱逃逸不应自动变成权威逃逸。
跨越一个遏制边界本身不应在内核之墙处为受保护效果制造权威。
同样：
提示注入不应制造权威。
攻陷智能体不应制造权威。
AI 遏制失败不应自动变成全机器范围的权威失败。
这就是为什么 KERNHELM 从普通智能体运行时之下入手处理 AI 运行时安全。
更高层可以决定：
what the agent wants to do
KERNHELM 提问：
whether the resulting machine effect possesses authority to happen
大多数 AI 控制系统关注的是控制智能体的行为、权限、工具或环境。
KERNHELM 针对的是另一个层面：
即使智能体已经到达尝试产生真实操作系统效果的地步，对于该确切效果是否存在有效的独立授权？
这一区分对于自主运行和长期运行的智能体尤为重要，因为推理、隔离、监控或策略上的失败不应自动转变为对主机的无限制权限。
因此，KERNHELM 不是 AI 终止开关。
其预期模型更为细粒度：
拒绝未授权的效果，同时允许单独授权的工作继续进行。
以下公开演示直接展示了这一区分。
不受信任文档中的恶意指令试图诱导删除受保护的文件。
软件接收到该指令并尝试执行删除。
KERNHELM 无需正确地将该指令归类为恶意，也无需将其识别为提示注入。
内核权限边界提出的问题更为狭窄：
针对该确切目标的这一确切删除操作，是否拥有有效的已准入权限？
它没有。
KERNHELM 拒绝该操作，文件保持存在。
随后用户通过受治理路径直接授权该删除。
软件并未变得更受信任。
可执行文件没有改变。
文件也没有移入另一个沙箱。
改变的是权限。
在具备匹配的已准入权限的情况下再次尝试删除。
KERNHELM 允许该受治理的效果，文件被删除。
演示的序列为：
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
后跟：
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
重要的结果是：
相同的软件。相同的目标。相同类别的效果。不同的被承认的权限。
软件不需要变得更受信任，其权限就可以改变。
这就是 KERNHELM。
现代计算机通常赋予软件广泛的常设权限。
一个进程可能能够：
因为用户、权限级别、容器、命名空间、能力集、服务身份或执行上下文的原因，它恰好正在这些条件下运行。
这形成了一条熟悉的安全链：
authority is granted broadly
↓
software is expected to behave correctly
↓
software is compromised, confused, manipulated, or simply wrong
↓
the inherited authority is still real
自主 AI 代理使这一古老的安全问题变得更加突出。
随着软件逐渐具备规划、使用工具、操作应用程序、管理系统、维护长期运行状态以及在人类监督日益减少的情况下采取行动的能力，广泛的常驻权限变得越来越重要。
传统安全系统通过以下重要机制来缓解这一问题：
KERNHELM 并不要求这些机制消失。
它可以强化仍在使用这些机制的系统。
但其长期问题更为根本：
软件为何首先就应该拥有广泛的常驻权限？
KERNHELM 探索的是，特权效果是否可以转而依赖于显式的、有界的、独立准入的权限，且请求软件自身无法创建这种权限。
“零信任”通常被表述为一项策略原则：
不要仅仅因为一个行为者所处的位置或其声称的身份就假定它应当被信任。
KERNHELM 将这一理念进一步推向技术栈的底层。
其长期目标是使信任本身与特权效果能否发生变得更加不相关。
不再主要依赖于：
trusted process
↓
broad privilege
↓
expected good behavior
KERNHELM 朝着以下方向迈进：
requested effect
↓
independently admitted bounded authority
↓
kernel verifies actual effect + authority
↓
ALLOW or real DENY
内核不需要判断发起请求的软件是否“善意”。
它需要确定的是，对于实际触及边界的效果，是否存在有效的授权。
这将零信任推理从自由裁量式信任转向机器核心软件授权边界处的机械法则。
KERNHELM 将以下两者分离：
what wants an effect
从：
what has authority to permit that effect
概念上：
Untrusted Requestor
│
▼
Proposed Action
│
▼
Governed Authorization Path
│
▼
Bounded Authority
│
▼
Kernel Enforcement
│
├── authority fits actual effect → effect may proceed
│
└── authority does not fit → real denial
请求软件不会自行铸造权限。
它可以提议一个操作。
它可以解释为什么想要该操作。
它可以规划极其复杂的操作序列。
它可能是正确的。
它可能是错误的。
这些事实都不会产生权限。
受治理的特权效果所需的权限必须通过一条独立的受治理路径产生。
一个有用的非技术类比是硬币分拣机。
KERNHELM 的意图不是坐在墙边询问：
“我是否认识这个程序，我是否信任它？”
相反，尝试执行的效果必须携带在机制上与该效果相匹配的权限。
这枚“硬币”可能受到以下属性的约束：
如果权限与槽位不匹配，它不会因为软件更加强硬地坚持而变得有效。
请求方不能简单地制造一枚更大的硬币。
派生权限可以变得更窄。
它绝不能悄然变得更宽。
这就是为什么 KERNHELM 与能力安全共享部分思想领域，同时追求一种不同的权限模型。
权限是必须与效果相匹配的东西，而不是请求它的软件所拥有的声誉。
有共同的理念，但它们不是相同的架构。
理解差异的最简单方式是：
seL4 就像只给软件它被允许拥有的钥匙。
KERNHELM 更接近于：
要求软件试图执行的每一个具体后果性操作都必须持有有效许可。
像 seL4 这样的能力安全系统，将拥有适当能力作为组件可以访问哪些内核对象的核心。
KERNHELM 关注另一个问题：
这个针对这个具体目标的具体效果，是否拥有有效的、独立准入的权限，可以在现在发生？
该权限可以受到以下约束：
请求软件不能简单地把该权限签发给自己。
一个有用的简化区分是：
seL4：
这个组件拥有哪些能力？
KERNHELM：
这个确切的具体后果性效果现在是否拥有有效权限？
或者更简洁地说：
seL4 是一种能力安全的内核架构。KERNHELM 是一种效果权限架构。
KERNHELM 也不要求用微内核架构取代 Linux。
它正在作为 OathRune 的 Linux 架构内的权限基底进行开发。
KERNHELM 有意分离了传统系统常常混为一谈的若干角色。
一个不受信任的规划器决定它想要完成什么。
该规划器可能是：
规划不会产生权限。
OathRune 更广泛的架构可能会在墙之上使用复杂推理来解释意图、分类提案、缩减过于宽泛的请求、关联依赖关系，或将不安全的请求重定向到更安全的替代方案。
该层最终可能变得极其复杂。
它仍然不会成为权限来源。
模糊推理仍然在墙之上。
一条独立的受治理授权路径决定有界权限是否应当存在。
请求规划器必须无法为自己签署、铸造、拓宽、续期、伪造或悄然扩展该权限。
这有意不同于传统的 AI 代理授权，在后者中，同一运行时或周围应用可能对其行使的权限拥有相当大的自由裁量权。
KERNHELM 在内核边界执行最终的受治理效果检查。
执行路径有意比其上的推理更简单。
智能可以思考。墙必须执行。
KERNHELM 不把普通用户态服务视为最终安全边界。
用户态可以：
但对于受治理效果，最终执行属于该层之下。
架构目标是：
用户态可以请求权限，但用户态必须无法制造、拓宽、禁用或重写约束它的权限之墙。
规划器不是权限。
执行器不是权限。
请求者不是权限。
AI 不是权限。
普通运行时用户态不是权限。
内核边界是执行之墙。
KERNHELM 的墙旨在治理真实的操作系统效果。
这一区分很重要。
一个仅仅告诉软件的用户态包装器：
permission denied
而不实际阻止底层操作并不等同于 KERNHELM。
同样，一个假装操作失败的测试框架并不能证明强制执行。
预期的架构是：
software attempts the real operation
↓
kernel enforcement point is reached
↓
KERNHELM checks admitted authority
↓
ALLOW
or
real kernel DENY
受治理的效果包括通过正常的系统调用驱动的操作系统行为所达到的效果，但 KERNHELM 的架构单元是被治理的效果，而不仅仅是一个编号的系统调用。
墙必须拥有最终裁决权。
这就是在运行时观察 AI 代理与对机器效果本身进行运行时强制执行之间的区别。
如果请求软件可以简单地以一种方式描述某个动作，却执行实质上不同的操作，安全系统就会变得脆弱。
KERNHELM 的设计使得权限是依据在强制执行边界实际观察到的效果和目标身份来检查的。
请求者的描述不是最终真相。
对于已演示和已指定的文件对象权限，目标身份源自内核可见的对象身份，而不是简单地信任用户态提供的文件名。
原则是：
不要询问软件它触碰了什么并直接相信答案。将权限绑定到内核实际看到被操作的对象上。
这防止用户态描述替代强制执行真相。
KERNHELM 围绕有界权限而非常驻的管理员式特权进行设计。
权限可以通过以下属性进行约束：
被委托的权限可以变得更窄。
它不能仅仅因为持有者请求更多就变得更宽。
当需要额外权限时，请求必须通过受治理的授权路径返回。
因此，授权并不意味着：
“这个软件是可信的。”
它更接近于：
“这个特定的有界权限针对这类效果、针对这个目标、在这些条件下存在。”
KERNHELM 的核心权限法则之一是，被委托的权限应当衰减而非扩展。
子权限可以接收：
它不能静默地获取比其父权限更多的权限。
这使得权限缩减成为一种结构性属性，而不仅仅是要求软件礼貌行事的请求。
权限在传递过程中可以缩小。扩大需要返回治理。
曾经有效的权限不能自动永远保持有效。
KERNHELM 的权限模型包含新鲜度和撤销属性，旨在拒绝：
撤销是权限生命周期的一部分，而不是事后的清理。
已撤销的权限不再被期望授权未来的受治理效果。