deso-pk/make-trust-irrelevantAutorité appliquée par le noyau et sécurité d'exécution pour les systèmes Linux, les logiciels autonomes et les agents d'IA.
Autorité imposée par le noyau et sécurité d'exécution pour les systèmes Linux, les applications, les logiciels autonomes et les agents IA.
KERNHELM est un substrat de sécurité général pour système d'exploitation qui place une frontière d'autorité stricte au niveau praticable le plus bas de la pile logicielle — sous l'IA, les applications, les services et l'espace utilisateur ordinaire.
Son objectif est simple à énoncer :
Un logiciel peut demander du pouvoir. Il ne doit pas pouvoir fabriquer l'autorité qui accorde ce pouvoir.
KERNHELM déplace la décision finale concernant les effets privilégiés gouvernés vers la frontière du noyau.
Le logiciel situé au-dessus de cette frontière peut être extraordinairement capable.
Il peut planifier.
Il peut raisonner.
Il peut automatiser.
Il peut administrer des applications.
Il peut défendre la machine.
Il peut fonctionner en continu comme un agent IA autonome.
Il peut même être une intelligence artificielle avancée.
Mais la capacité seule ne crée pas la permission.
La séparation architecturale est absolue par conception :
L'entité qui demande un effet n'est pas autorisée à être celle qui décide si elle a l'autorité de provoquer cet effet.
Dans le langage de sécurité ordinaire, KERNHELM est une tentative de dépasser la question :
« Faisons-nous confiance à ce programme ? »
pour aller vers :
« Cet effet exactement tenté possède-t-il une autorité valide ? »
Cette distinction est le cœur du projet.
Pour la sécurité des agents IA, le même principe peut être énoncé autrement :
Un agent IA peut décider ce qu'il veut faire. Cette décision ne doit pas fabriquer l'autorité nécessaire pour le réaliser.
KERNHELM n'est pas un bac à sable pour IA.
Ce n'est pas un conteneur d'application.
Ce n'est pas une enveloppe de permissions autour d'un programme particulier.
Ce n'est pas un détecteur d'injection de prompt.
Ce n'est pas un classificateur de comportement de modèle.
Ce n'est pas un interrupteur d'arrêt pour IA.
Ce n'est pas un moteur de politique conventionnel en espace utilisateur.
Ce n'est pas simplement une autre couche de contrôle d'accès pour agent IA s'exécutant à côté du logiciel qu'elle contraint.
C'est une architecture d'autorité générale pour le système d'exploitation lui-même.
Un bac à sable répond principalement à :
Où ce programme est-il autorisé à opérer ?
KERNHELM pose une question plus profonde :
D'où vient l'autorité de provoquer cet effet privilégié, tout simplement ?
Une formule utile est :
Un bac à sable contraint où un logiciel peut opérer. KERNHELM contraint d'où l'autorité peut provenir.
Retirez complètement l'IA de la machine et KERNHELM garde tout son sens.
Un navigateur, un démon, un gestionnaire de paquets, un processus auxiliaire, un jeu, un utilitaire de pilote, une charge utile malveillante, un attaquant distant agissant via un logiciel compromis ou une intelligence artificielle rencontre finalement le même problème d'autorité sous-jacent.
C'est pourquoi KERNHELM est un substrat de sécurité général plutôt qu'un simple système de confinement pour IA.
L'IA n'est qu'une des applications les plus claires et potentiellement les plus fortes de l'architecture.
La sécurité des agents IA, la sécurité de l'IA agentique et la sécurité d'exécution de l'IA modernes reposent de plus en plus sur des mécanismes tels que :
Ces mécanismes peuvent tous être utiles.
KERNHELM s'interroge sur ce qui se passe en dessous d'eux.
Si un agent IA autonome est compromis, manipulé, soumis à une injection de prompt, mal configuré ou s'échappe d'un mécanisme de confinement de niveau supérieur, cet événement doit-il automatiquement accorder au logiciel résultant une large autorité sur la machine ?
La réponse de KERNHELM est non.
Une évasion de bac à sable ne doit pas automatiquement devenir une évasion d'autorité.
Franchir une frontière de confinement ne doit pas en soi fabriquer l'autorité pour des effets protégés au mur du noyau.
De même :
L'injection de prompt ne doit pas fabriquer d'autorité.
La compromission d'un agent ne doit pas fabriquer d'autorité.
Une défaillance de confinement de l'IA ne doit pas automatiquement devenir une défaillance d'autorité à l'échelle de la machine.
C'est pourquoi KERNHELM aborde la sécurité d'exécution de l'IA depuis en dessous de l'exécution ordinaire des agents.
Les couches supérieures peuvent décider :
what the agent wants to do
KERNHELM demande :
whether the resulting machine effect possesses authority to happen
La plupart des systèmes de contrôle de l'IA visent à contrôler le comportement, les permissions, les outils ou l'environnement de l'agent.
KERNHELM s'attaque à une autre couche :
Même si l'agent atteint le point de tenter l'effet réel sur le système d'exploitation, une autorité indépendante valide existe-t-elle pour cet effet exact ?
Cette distinction est particulièrement importante pour les agents autonomes et de longue durée, car une défaillance du raisonnement, du confinement, de la surveillance ou de la politique ne devrait pas automatiquement se transformer en autorité illimitée sur l'hôte.
KERNHELM n'est donc pas un interrupteur d'arrêt pour l'IA.
Son modèle prévu est plus granulaire :
Refuser l'effet non autorisé tout en permettant à un travail autorisé séparément de se poursuivre.
La démonstration publique suivante montre directement cette distinction.
Une instruction malveillante contenue dans un document non fiable tente de provoquer la suppression d'un fichier protégé.
Le logiciel reçoit l'instruction et tente la suppression.
KERNHELM n'a pas besoin de classer correctement l'instruction comme malveillante ni de l'identifier comme une injection de prompt.
La frontière d'autorité du noyau pose une question plus étroite :
Cette suppression exacte, contre cette cible exacte, possède-t-elle une autorité valide admise ?
Ce n'est pas le cas.
KERNHELM refuse l'opération et le fichier reste présent.
L'utilisateur autorise ensuite directement la suppression via le chemin gouverné.
Le logiciel ne devient pas plus fiable.
L'exécutable ne change pas.
Le fichier ne se déplace pas dans un autre bac à sable.
Ce qui change, c'est l'autorité.
La suppression est tentée à nouveau avec une autorité admise correspondante.
KERNHELM autorise l'effet gouverné et le fichier est supprimé.
La séquence démontrée est la suivante :
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
suivi de :
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
Le résultat important est :
Même logiciel. Même cible. Même classe d'effet. Autorité admise différente.
Le logiciel n'avait pas besoin de devenir plus fiable pour que son autorité change.
C'est KERNHELM.
Les ordinateurs modernes accordent couramment aux logiciels une large autorité permanente.