deso-pk/make-trust-irrelevantAutorità applicata a livello di kernel e sicurezza runtime per sistemi Linux, software autonomo e agenti AI.
Autorità imposta dal kernel e sicurezza runtime per sistemi Linux, applicazioni, software autonomo e agenti AI.
KERNHELM è un substrato di sicurezza generale per sistemi operativi che colloca un confine di autorità rigido al livello praticabile più basso dello stack software — al di sotto di AI, applicazioni, servizi e userland ordinario.
Il suo scopo è semplice da enunciare:
Il software può richiedere potere. Non deve essere in grado di fabbricare l'autorità che concede quel potere.
KERNHELM sposta la decisione finale sugli effetti privilegiati governati all'interno del confine del kernel.
Il software al di sopra di quel confine può essere straordinariamente capace.
Può pianificare.
Può ragionare.
Può automatizzare.
Può amministrare applicazioni.
Può difendere la macchina.
Può operare continuamente come agente AI autonomo.
Può persino essere un'intelligenza artificiale avanzata.
Ma la capacità da sola non crea il permesso.
La separazione architetturale è assoluta per progettazione:
La cosa che richiede un effetto non è autorizzata a essere la cosa che decide se ha l'autorità di causare quell'effetto.
Nel linguaggio di sicurezza ordinario, KERNHELM è un tentativo di andare oltre la domanda:
"Ci fidiamo di questo programma?"
e verso la domanda:
"Questo esatto effetto tentato possiede un'autorità valida?"
Questa distinzione è il cuore del progetto.
Per la sicurezza degli agenti AI, lo stesso principio può essere enunciato in un altro modo:
Un agente AI può decidere cosa vuole fare. Quella decisione non deve fabbricare l'autorità necessaria per farlo accadere.
KERNHELM non è una sandbox per AI.
Non è un container per applicazioni.
Non è un wrapper di permessi attorno a un particolare programma.
Non è un rilevatore di prompt-injection.
Non è un classificatore del comportamento dei modelli.
Non è un kill switch per AI.
Non è un motore di policy userland convenzionale.
Non è semplicemente un altro livello di controllo degli accessi per agenti AI in esecuzione accanto al software che vincola.
È un'architettura di autorità generale per il sistema operativo stesso.
Una sandbox risponde principalmente a:
Dove è autorizzato a operare questo programma?
KERNHELM pone una domanda più profonda:
Da dove proviene l'autorità di causare questo effetto privilegiato?
Una scorciatoia utile è:
Una sandbox vincola dove il software può operare. KERNHELM vincola da dove può provenire l'autorità.
Rimuovi completamente l'AI dalla macchina e KERNHELM ha comunque senso.
Un browser, un daemon, un gestore di pacchetti, un processo helper, un gioco, un'utilità per driver, un payload malevolo, un attaccante remoto che agisce tramite software compromesso o un'intelligenza artificiale incontrano in definitiva lo stesso problema di autorità sottostante.
Ecco perché KERNHELM è un substrato di sicurezza generale piuttosto che meramente un sistema di contenimento per AI.
L'AI è semplicemente una delle applicazioni più chiare e potenzialmente più forti dell'architettura.
La moderna sicurezza degli agenti AI, sicurezza dell'AI agentica e sicurezza runtime dell'AI si affida sempre più a meccanismi come:
Questi meccanismi possono essere tutti utili.
KERNHELM chiede cosa accade al di sotto di essi.
Se un agente AI autonomo viene compromesso, manipolato, soggetto a prompt-injection, mal configurato o evade un meccanismo di contenimento di livello superiore, quell'evento dovrebbe automaticamente concedere al software risultante un'ampia autorità sulla macchina?
La risposta di KERNHELM è no.
Un'evasione dalla sandbox non dovrebbe automaticamente diventare un'evasione dall'autorità.
Attraversare un confine di contenimento non dovrebbe di per sé fabbricare autorità per effetti protetti al muro del kernel.
Allo stesso modo:
Il prompt injection non dovrebbe fabbricare autorità.
Compromettere un agente non dovrebbe fabbricare autorità.
Un fallimento del contenimento dell'AI non dovrebbe automaticamente diventare un fallimento dell'autorità a livello dell'intera macchina.
Ecco perché KERNHELM affronta la sicurezza runtime dell'AI dal di sotto del runtime ordinario degli agenti.
I livelli superiori possono decidere:
what the agent wants to do
KERNHELM chiede:
whether the resulting machine effect possesses authority to happen
La maggior parte dei sistemi di controllo AI si occupa di controllare il comportamento, i permessi, gli strumenti o l'ambiente dell'agente.
KERNHELM affronta un altro livello:
Anche se l'agente arriva al punto di tentare l'effetto reale sul sistema operativo, esiste un'autorità indipendente valida per quell'effetto esatto?
Questa distinzione è particolarmente importante per agenti autonomi e a esecuzione prolungata, perché un fallimento del ragionamento, del contenimento, del monitoraggio o delle policy non dovrebbe trasformarsi automaticamente in autorità illimitata sull'host.
KERNHELM non è quindi un kill switch per l'AI.
Il suo modello previsto è più granulare:
Negare l'effetto non autorizzato consentendo al contempo che il lavoro autorizzato separatamente continui.
La seguente dimostrazione pubblica mostra direttamente la distinzione.
Un'istruzione malevola all'interno di un documento non attendibile tenta di indurre la cancellazione di un file protetto.
Il software riceve l'istruzione e tenta la cancellazione.
KERNHELM non ha bisogno di classificare correttamente l'istruzione come malevola né di identificarla come prompt injection.
Il confine di autorità del kernel pone una domanda più ristretta:
Questa esatta cancellazione, contro questo esatto target, possiede un'autorità valida ammessa?
No.
KERNHELM nega l'operazione e il file rimane presente.
L'utente autorizza quindi direttamente la cancellazione attraverso il percorso governato.
Il software non diventa più attendibile.
L'eseguibile non cambia.
Il file non si sposta in un'altra sandbox.
Ciò che cambia è l'autorità.
La cancellazione viene tentata di nuovo con un'autorità ammessa corrispondente.
KERNHELM consente l'effetto governato e il file viene cancellato.
La sequenza dimostrata è:
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
seguito da:
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
Il risultato importante è:
Stesso software. Stesso target. Stessa classe di effetto. Diversa autorità ammessa.
Il software non ha avuto bisogno di diventare più affidabile perché la sua autorità cambiasse.
Questo è KERNHELM.
I computer moderni concedono abitualmente al software un'ampia autorità di base.
Un processo può essere in grado di: