deso-pk/make-trust-irrelevantAutoridad impuesta por el kernel y seguridad en tiempo de ejecución para sistemas Linux, software autónomo y agentes de IA.
Autoridad impuesta por el kernel y seguridad en tiempo de ejecución para sistemas Linux, aplicaciones, software autónomo y agentes de IA.
KERNHELM es un sustrato de seguridad de propósito general para sistemas operativos que sitúa una frontera de autoridad dura en el nivel aplicable más bajo posible de la pila de software — por debajo de la IA, las aplicaciones, los servicios y el espacio de usuario ordinario.
Su propósito es simple de enunciar:
El software puede solicitar poder. No debe ser capaz de fabricar la autoridad que otorga ese poder.
KERNHELM traslada la decisión final sobre los efectos privilegiados gobernados a la frontera del kernel.
El software por encima de esa frontera puede ser extraordinariamente capaz.
Puede planificar.
Puede razonar.
Puede automatizar.
Puede administrar aplicaciones.
Puede defender la máquina.
Puede operar continuamente como un agente de IA autónomo.
Puede incluso ser una inteligencia artificial avanzada.
Pero la capacidad por sí sola no crea permiso.
La separación arquitectónica es absoluta por diseño:
La cosa que solicita un efecto no tiene permitido ser la cosa que decide si tiene autoridad para causar ese efecto.
En el lenguaje de seguridad ordinario, KERNHELM es un intento de ir más allá de preguntar:
"¿Confiamos en este programa?"
y avanzar hacia preguntar:
"¿Posee este intento de efecto exacto una autoridad válida?"
Esa distinción es el núcleo del proyecto.
Para la seguridad de agentes de IA, el mismo principio puede enunciarse de otra manera:
Un agente de IA puede decidir qué quiere hacer. Esa decisión no debe fabricar la autoridad necesaria para llevarla a cabo.
KERNHELM no es un sandbox de IA.
No es un contenedor de aplicaciones.
No es un envoltorio de permisos alrededor de un programa concreto.
No es un detector de inyección de prompts.
No es un clasificador de comportamiento de modelos.
No es un interruptor de emergencia para IA.
No es un motor de políticas convencional en espacio de usuario.
No es meramente otra capa de control de acceso para agentes de IA ejecutándose junto al software que restringe.
Es una arquitectura de autoridad de propósito general para el propio sistema operativo.
Un sandbox responde principalmente:
¿Dónde tiene permitido operar este programa?
KERNHELM plantea una pregunta más profunda:
¿De dónde proviene en absoluto la autoridad para causar este efecto privilegiado?
Una forma útil de resumirlo es:
Un sandbox restringe dónde puede operar el software. KERNHELM restringe de dónde puede provenir la autoridad.
Elimina la IA de la máquina por completo y KERNHELM sigue teniendo sentido.
Un navegador, un demonio, un gestor de paquetes, un proceso auxiliar, un juego, una utilidad de controladores, una carga maliciosa, un atacante remoto actuando a través de software comprometido o una inteligencia artificial acaban enfrentándose al mismo problema subyacente de autoridad.
Por eso KERNHELM es un sustrato de seguridad de propósito general y no meramente un sistema de contención de IA.
La IA es simplemente una de las aplicaciones más claras y potencialmente más potentes de la arquitectura.
La seguridad de agentes de IA, la seguridad de IA agéntica y la seguridad en tiempo de ejecución de IA modernas dependen cada vez más de mecanismos como:
Todos estos mecanismos pueden ser útiles.
KERNHELM pregunta qué ocurre por debajo de ellos.
Si un agente de IA autónomo es comprometido, manipulado, objeto de inyección de prompts, mal configurado o escapa de un mecanismo de contención de nivel superior, ¿debería ese evento otorgar automáticamente al software resultante una amplia autoridad sobre la máquina?
La respuesta de KERNHELM es no.
Un escape de sandbox no debería convertirse automáticamente en un escape de autoridad.
Cruzar una frontera de contención no debería por sí mismo fabricar autoridad para efectos protegidos en el muro del kernel.
Del mismo modo:
La inyección de prompts no debería fabricar autoridad.
Comprometer un agente no debería fabricar autoridad.
Un fallo de contención de IA no debería convertirse automáticamente en un fallo de autoridad a escala de toda la máquina.
Por eso KERNHELM aborda la seguridad en tiempo de ejecución de IA desde por debajo del runtime ordinario del agente.
Las capas superiores pueden decidir:
what the agent wants to do
KERNHELM pregunta:
whether the resulting machine effect possesses authority to happen
La mayoría de los sistemas de control de IA se ocupan de controlar el comportamiento, los permisos, las herramientas o el entorno del agente.
KERNHELM aborda otra capa:
Incluso si el agente llega al punto de intentar el efecto real sobre el sistema operativo, ¿existe una autoridad independiente válida para ese efecto exacto?
Esta distinción es particularmente importante para agentes autónomos y de larga duración, porque un fallo de razonamiento, contención, monitoreo o política no debería convertirse automáticamente en autoridad sin restricciones sobre el host.
Por lo tanto, KERNHELM no es un interruptor de apagado de IA.
Su modelo previsto es más granular:
Denegar el efecto no autorizado mientras se permite que el trabajo autorizado por separado continúe.
La siguiente demostración pública muestra la distinción directamente.
Una instrucción maliciosa dentro de un documento no confiable intenta inducir la eliminación de un archivo protegido.
El software recibe la instrucción e intenta la eliminación.
KERNHELM no necesita clasificar correctamente la instrucción como maliciosa ni identificarla como inyección de prompt.
La frontera de autoridad del kernel plantea una pregunta más acotada:
¿Esta eliminación exacta, contra este objetivo exacto, posee autoridad válida admitida?
No la posee.
KERNHELM deniega la operación y el archivo permanece presente.
Luego, el usuario autoriza directamente la eliminación a través de la ruta gobernada.
El software no se vuelve más confiable.
El ejecutable no cambia.
El archivo no se mueve a otro sandbox.
Lo que cambia es la autoridad.
La eliminación se intenta de nuevo con la autoridad admitida correspondiente.
KERNHELM permite el efecto gobernado y el archivo se elimina.
La secuencia demostrada es:
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
seguido de:
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
El resultado importante es:
El mismo software. El mismo objetivo. La misma clase de efecto. Diferente autoridad admitida.
El software no necesitó volverse más confiable para que su autoridad cambiara.
Eso es KERNHELM.
Las computadoras modernas otorgan rutinariamente a el software una autoridad amplia y permanente.
Un proceso puede ser capaz de: