deso-pk/make-trust-irrelevantAutoridade imposta pelo kernel e segurança em tempo de execução para sistemas Linux, software autônomo e agentes de IA.
Autoridade imposta pelo kernel e segurança em tempo de execução para sistemas Linux, aplicações, software autônomo e agentes de IA.
KERNHELM é um substrato de segurança de sistema operacional de propósito geral que coloca uma fronteira de autoridade rígida no nível aplicável mais baixo da pilha de software — abaixo de IA, aplicações, serviços e userland comum.
Seu propósito é simples de enunciar:
O software pode solicitar poder. Ele não deve ser capaz de fabricar a autoridade que concede esse poder.
KERNHELM move a decisão final sobre efeitos privilegiados governados para a fronteira do kernel.
O software acima dessa fronteira pode ser extraordinariamente capaz.
Pode planejar.
Pode raciocinar.
Pode automatizar.
Pode administrar aplicações.
Pode defender a máquina.
Pode operar continuamente como um agente de IA autônomo.
Pode até ser uma inteligência artificial avançada.
Mas capacidade por si só não cria permissão.
A separação arquitetural é absoluta por design:
A coisa que solicita um efeito não tem permissão para ser a coisa que decide se tem autoridade para causar esse efeito.
Em linguagem de segurança comum, KERNHELM é uma tentativa de ir além de perguntar:
"Confiamos neste programa?"
e avançar para perguntar:
"Este efeito exato tentado possui autoridade válida?"
Essa distinção é o cerne do projeto.
Para a segurança de agentes de IA, o mesmo princípio pode ser enunciado de outra forma:
Um agente de IA pode decidir o que quer fazer. Essa decisão não deve fabricar a autoridade necessária para realizá-la.
KERNHELM não é um sandbox de IA.
Não é um contêiner de aplicação.
Não é um wrapper de permissão em torno de um programa específico.
Não é um detector de injeção de prompt.
Não é um classificador de comportamento de modelo.
Não é um kill switch de IA.
Não é um motor de políticas de userland convencional.
Não é meramente outra camada de controle de acesso de agente de IA executando ao lado do software que restringe.
É uma arquitetura de autoridade de propósito geral para o próprio sistema operacional.
Um sandbox responde primariamente:
Onde este programa tem permissão para operar?
KERNHELM faz uma pergunta mais profunda:
De onde vem, afinal, a autoridade para causar este efeito privilegiado?
Uma abreviação útil é:
Um sandbox restringe onde o software pode operar. KERNHELM restringe de onde a autoridade pode vir.
Remova a IA da máquina inteiramente e KERNHELM ainda faz sentido.
Um navegador, daemon, gerenciador de pacotes, processo auxiliar, jogo, utilitário de driver, payload malicioso, atacante remoto agindo através de software comprometido ou inteligência artificial, em última análise, encontra o mesmo problema subjacente de autoridade.
É por isso que KERNHELM é um substrato de segurança de propósito geral, e não meramente um sistema de contenção de IA.
A IA é simplesmente uma das aplicações mais claras e potencialmente mais fortes da arquitetura.
A moderna segurança de agentes de IA, segurança de IA agêntica e segurança em tempo de execução de IA dependem cada vez mais de mecanismos como:
Esses mecanismos podem todos ser úteis.
KERNHELM pergunta o que acontece por baixo deles.
Se um agente de IA autônomo for comprometido, manipulado, sofrer injeção de prompt, for mal configurado ou escapar de um mecanismo de contenção de nível superior, esse evento deve conceder automaticamente ao software resultante ampla autoridade sobre a máquina?
A resposta de KERNHELM é não.
Uma fuga de sandbox não deve se tornar automaticamente uma fuga de autoridade.
Cruzar uma fronteira de contenção não deve, por si só, fabricar autoridade para efeitos protegidos na muralha do kernel.
Da mesma forma:
Injeção de prompt não deve fabricar autoridade.
Comprometer um agente não deve fabricar autoridade.
Falha de contenção de IA não deve se tornar automaticamente falha de autoridade em toda a máquina.
É por isso que KERNHELM aborda a segurança em tempo de execução de IA a partir de baixo do runtime comum de agentes.
Camadas superiores podem decidir:
what the agent wants to do
KERNHELM pergunta:
whether the resulting machine effect possesses authority to happen
A maioria dos sistemas de controle de IA preocupa-se em controlar o comportamento, as permissões, as ferramentas ou o ambiente do agente.
O KERNHELM aborda outra camada:
Mesmo que o agente chegue ao ponto de tentar o efeito real no sistema operacional, existe autoridade independente válida para esse efeito exato?
Essa distinção é particularmente importante para agentes autônomos e de longa duração, porque uma falha de raciocínio, contenção, monitoramento ou política não deve se tornar automaticamente autoridade irrestrita sobre o host.
O KERNHELM, portanto, não é um kill switch de IA.
Seu modelo pretendido é mais granular:
Negar o efeito não autorizado enquanto permite que o trabalho autorizado separadamente continue.
A demonstração pública a seguir mostra a distinção diretamente.
Uma instrução maliciosa dentro de um documento não confiável tenta induzir a exclusão de um arquivo protegido.
O software recebe a instrução e tenta a exclusão.
O KERNHELM não precisa classificar corretamente a instrução como maliciosa nem identificá-la como prompt injection.
A fronteira de autoridade do kernel faz uma pergunta mais restrita:
Esta exclusão exata, contra este alvo exato, possui autoridade válida admitida?
Não possui.
O KERNHELM nega a operação e o arquivo permanece presente.
O usuário então autoriza diretamente a exclusão pelo caminho governado.
O software não se torna mais confiável.
O executável não muda.
O arquivo não se move para outro sandbox.
O que muda é a autoridade.
A exclusão é tentada novamente com autoridade admitida correspondente.
O KERNHELM permite o efeito governado e o arquivo é excluído.
A sequência demonstrada é:
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
seguido por:
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
O resultado importante é:
Mesmo software. Mesmo alvo. Mesma classe de efeito. Autoridade admitida diferente.
O software não precisou se tornar mais confiável para que sua autoridade mudasse.
Isso é KERNHELM.
Computadores modernos rotineiramente concedem ao software uma autoridade ampla e permanente.
Um processo pode ser capaz de:
por causa do usuário, nível de privilégio, contêiner, namespace, conjunto de capacidades, identidade de serviço ou contexto de execução sob o qual ele por acaso está sendo executado.
Isso cria uma cadeia de segurança familiar: