deso-pk/make-trust-irrelevantKernel-erzwungene Autorität und Laufzeitsicherheit für Linux-Systeme, autonome Software und KI-Agenten.
Kernel-erzwungene Autorität und Laufzeitsicherheit für Linux-Systeme, Anwendungen, autonome Software und KI-Agenten.
KERNHELM ist ein allgemeines betriebssystemweites Sicherheitssubstrat, das eine harte Autoritätsgrenze auf der niedrigsten praktisch durchsetzbaren Ebene des Software-Stacks platziert — unterhalb von KI, Anwendungen, Diensten und gewöhnlichem Userland.
Sein Zweck ist einfach zu benennen:
Software darf Macht anfordern. Sie darf nicht in der Lage sein, die Autorität herzustellen, die diese Macht verleiht.
KERNHELM verlagert die endgültige Entscheidung über gesteuerte privilegierte Effekte an die Kernel-Grenze.
Software oberhalb dieser Grenze darf außerordentlich leistungsfähig sein.
Sie darf planen.
Sie darf schlussfolgern.
Sie darf automatisieren.
Sie darf Anwendungen verwalten.
Sie darf die Maschine verteidigen.
Sie darf kontinuierlich als autonomer KI-Agent operieren.
Sie darf sogar eine fortgeschrittene künstliche Intelligenz sein.
Doch Fähigkeit allein erzeugt keine Berechtigung.
Die architektonische Trennung ist konstruktionsbedingt absolut:
Die Sache, die einen Effekt anfordert, darf nicht die Sache sein, die entscheidet, ob sie die Autorität besitzt, diesen Effekt zu verursachen.
In gewöhnlicher Sicherheitssprache ist KERNHELM ein Versuch, über die Frage hinauszugehen:
„Vertrauen wir diesem Programm?“
und hin zur Frage:
„Besitzt genau dieser versuchte Effekt gültige Autorität?“
Diese Unterscheidung ist der Kern des Projekts.
Für die Sicherheit von KI-Agenten lässt sich dasselbe Prinzip auch anders formulieren:
Ein KI-Agent darf entscheiden, was er tun möchte. Diese Entscheidung darf nicht die Autorität herstellen, die erforderlich ist, um es zu bewirken.
KERNHELM ist keine KI-Sandbox.
Es ist kein Anwendungscontainer.
Es ist kein Berechtigungs-Wrapper um ein bestimmtes Programm.
Es ist kein Prompt-Injection-Detektor.
Es ist kein Klassifikator für Modellverhalten.
Es ist kein KI-Kill-Switch.
Es ist keine herkömmliche Userland-Policy-Engine.
Es ist nicht bloß eine weitere Zugriffskontrollschicht für KI-Agenten, die neben der Software läuft, die sie einschränkt.
Es ist eine allgemeine Autoritätsarchitektur für das Betriebssystem selbst.
Eine Sandbox beantwortet in erster Linie:
Wo darf dieses Programm operieren?
KERNHELM stellt eine tiefere Frage:
Woher kommt überhaupt die Autorität, diesen privilegierten Effekt zu verursachen?
Eine nützliche Kurzformel lautet:
Eine Sandbox beschränkt, wo Software operieren kann. KERNHELM beschränkt, woher Autorität kommen kann.
Entfernt man KI vollständig von der Maschine, ergibt KERNHELM immer noch Sinn.
Ein Browser, Daemon, Paketmanager, Hilfsprozess, Spiel, Treiber-Dienstprogramm, eine schädliche Nutzlast, ein entfernter Angreifer, der durch kompromittierte Software handelt, oder eine künstliche Intelligenz — letztlich begegnen alle demselben zugrundeliegenden Autoritätsproblem.
Deshalb ist KERNHELM ein allgemeines Sicherheitssubstrat und nicht bloß ein KI-Eindämmungssystem.
KI ist lediglich eine der klarsten und potenziell stärksten Anwendungen der Architektur.
Moderne KI-Agenten-Sicherheit, agentische KI-Sicherheit und KI-Laufzeitsicherheit stützen sich zunehmend auf Mechanismen wie:
Diese Mechanismen können alle nützlich sein.
KERNHELM fragt, was darunter geschieht.
Wenn ein autonomer KI-Agent kompromittiert, manipuliert, per Prompt-Injection angegriffen, fehlkonfiguriert wird oder einem übergeordneten Eindämmungsmechanismus entkommt — sollte dieses Ereignis der daraus resultierenden Software automatisch umfassende Maschinenautorität verleihen?
KERNHELMs Antwort ist nein.
Eine Sandbox-Flucht sollte nicht automatisch zu einer Autoritäts-Flucht werden.
Das Überschreiten einer Eindämmungsgrenze sollte nicht selbst Autorität für geschützte Effekte an der Kernel-Mauer herstellen.
Ebenso gilt:
Prompt-Injection sollte keine Autorität herstellen.
Die Kompromittierung eines Agenten sollte keine Autorität herstellen.
Ein KI-Eindämmungsfehler sollte nicht automatisch zu einem maschinenweiten Autoritätsfehler werden.
Deshalb nähert sich KERNHELM der KI-Laufzeitsicherheit von unterhalb der gewöhnlichen Agenten-Laufzeit.
Höhere Schichten mögen entscheiden:
what the agent wants to do
KERNHELM fragt:
whether the resulting machine effect possesses authority to happen
Die meisten KI-Kontrollsysteme befassen sich mit der Steuerung des Verhaltens, der Berechtigungen, der Werkzeuge oder der Umgebung des Agenten.
KERNHELM adressiert eine andere Ebene:
Selbst wenn der Agent den Punkt erreicht, an dem er den tatsächlichen Betriebssystemeffekt versucht, existiert für genau diesen Effekt eine gültige unabhängige Autorität?
Diese Unterscheidung ist besonders wichtig für autonome und langlaufende Agenten, denn ein Fehler beim Reasoning, bei der Eindämmung, bei der Überwachung oder bei der Richtlinie sollte nicht automatisch zu uneingeschränkter Autorität über den Host werden.
KERNHELM ist daher kein KI-Kill-Switch.
Sein beabsichtigtes Modell ist granularer:
Den nicht autorisierten Effekt verweigern, während separat autorisierte Arbeit fortgesetzt werden kann.
Die folgende öffentliche Demonstration zeigt die Unterscheidung direkt.
Eine bösartige Anweisung in einem nicht vertrauenswürdigen Dokument versucht, die Löschung einer geschützten Datei herbeizuführen.
Die Software empfängt die Anweisung und versucht die Löschung.
KERNHELM muss die Anweisung nicht korrekt als bösartig klassifizieren oder sie als Prompt Injection identifizieren.
Die Kernel-Autoritätsgrenze stellt eine engere Frage:
Besitzt genau diese Löschung, gegen genau dieses Ziel, eine gültige zugelassene Autorität?
Sie tut es nicht.
KERNHELM verweigert die Operation und die Datei bleibt vorhanden.
Der Benutzer autorisiert dann die Löschung direkt über den geregelten Pfad.
Die Software wird nicht vertrauenswürdiger.
Die ausführbare Datei ändert sich nicht.
Die Datei wird nicht in eine andere Sandbox verschoben.
Was sich ändert, ist die Autorität.
Die Löschung wird erneut versucht, mit passender zugelassener Autorität.
KERNHELM erlaubt den geregelten Effekt und die Datei wird gelöscht.
Die demonstrierte Sequenz ist:
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
gefolgt von:
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
Das wichtige Ergebnis ist:
Dieselbe Software. Dasselbe Ziel. Dieselbe Wirkungsklasse. Unterschiedliche zugestandene Autorität.
Die Software musste nicht vertrauenswürdiger werden, damit sich ihre Autorität ändert.
Das ist KERNHELM.
Moderne Computer verleihen Software routinemäßig weitreichende Autorität.
Ein Prozess kann möglicherweise: