deso-pk/make-trust-irrelevantLinux 시스템, 자율 소프트웨어 및 AI 에이전트를 위한 커널 수준의 권한 및 런타임 보안.
Linux 시스템, 애플리케이션, 자율 소프트웨어 및 AI 에이전트를 위한 커널 강제 권한 및 런타임 보안.
KERNHELM은 소프트웨어 스택에서 실질적으로 강제 가능한 가장 낮은 계층 — AI, 애플리케이션, 서비스, 일반 사용자 영역 아래 — 에 강력한 권한 경계를 배치하는 범용 운영체제 보안 기반입니다.
그 목적은 간단히 말할 수 있습니다:
소프트웨어는 권력을 요청할 수 있다. 그러나 그 권력을 부여하는 권한을 스스로 만들어낼 수 없어야 한다.
KERNHELM은 통제된 특권 효과에 대한 최종 결정을 커널 경계로 이동시킵니다.
그 경계 위의 소프트웨어는 매우 뛰어난 능력을 가질 수 있습니다.
계획할 수 있습니다.
추론할 수 있습니다.
자동화할 수 있습니다.
애플리케이션을 관리할 수 있습니다.
기계를 방어할 수 있습니다.
자율 AI 에이전트로서 지속적으로 운영될 수 있습니다.
심지어 고급 인공지능일 수도 있습니다.
그러나 능력만으로는 권한이 생기지 않습니다.
이 아키텍처적 분리는 설계상 절대적입니다:
효과를 요청하는 주체는 그 효과를 일으킬 권한이 있는지 스스로 결정하는 주체가 될 수 없다.
일반적인 보안 용어로, KERNHELM은 다음을 묻는 것을 넘어서려는 시도입니다:
“우리는 이 프로그램을 신뢰하는가?”
그리고 다음을 묻는 쪽으로 나아갑니다:
“이 정확한 시도된 효과가 유효한 권한을 가지고 있는가?”
그 구분이 이 프로젝트의 핵심입니다.
AI 에이전트 보안의 경우, 같은 원칙을 다르게 표현할 수 있습니다:
AI 에이전트는 자신이 무엇을 하고 싶은지 결정할 수 있다. 그 결정이 그것을 실현하는 데 필요한 권한을 만들어내서는 안 된다.
KERNHELM은 AI 샌드박스가 아닙니다.
애플리케이션 컨테이너가 아닙니다.
특정 프로그램을 감싸는 권한 래퍼가 아닙니다.
프롬프트 인젝션 탐지기가 아닙니다.
모델 행동 분류기가 아닙니다.
AI 킬 스위치가 아닙니다.
기존의 사용자 영역 정책 엔진이 아닙니다.
단지 제약하는 소프트웨어 옆에서 실행되는 또 하나의 AI 에이전트 접근 제어 계층이 아닙니다.
그것은 운영체제 자체를 위한 범용 권한 아키텍처입니다.
샌드박스는 주로 다음에 답합니다:
이 프로그램은 어디에서 작동하도록 허용되는가?
KERNHELM은 더 깊은 질문을 던집니다:
이 특권 효과를 일으킬 권한은 대체 어디에서 오는가?
유용한 요약은 다음과 같습니다:
샌드박스는 소프트웨어가 어디에서 작동할 수 있는지 제약한다. KERNHELM은 권한이 어디에서 올 수 있는지 제약한다.
기계에서 AI를 완전히 제거해도 KERNHELM은 여전히 의미가 있습니다.
브라우저, 데몬, 패키지 관리자, 헬퍼 프로세스, 게임, 드라이버 유틸리티, 악성 페이로드, 손상된 소프트웨어를 통해 행동하는 원격 공격자, 또는 인공지능은 궁극적으로 동일한 근본적인 권한 문제에 직면합니다.
그렇기 때문에 KERNHELM은 단순한 AI 격리 시스템이 아니라 범용 보안 기반입니다.
AI는 이 아키텍처의 가장 명확하고 잠재적으로 가장 강력한 적용 사례 중 하나일 뿐입니다.
현대의 AI 에이전트 보안, 에이전틱 AI 보안, AI 런타임 보안은 점점 더 다음과 같은 메커니즘에 의존합니다:
이러한 메커니즘은 모두 유용할 수 있습니다.
KERNHELM은 그 아래에서 무슨 일이 일어나는지 묻습니다.
자율 AI 에이전트가 손상되거나, 조작되거나, 프롬프트 인젝션을 당하거나, 잘못 구성되거나, 상위 수준의 격리 메커니즘을 탈출한다면, 그 사건이 결과적으로 생성된 소프트웨어에 광범위한 기계 권한을 자동으로 부여해야 하는가?
KERNHELM의 답은 아니오입니다.
샌드박스 탈출이 자동으로 권한 탈출이 되어서는 안 된다.
하나의 격리 경계를 넘는 것이 그 자체로 커널 장벽에서 보호된 효과에 대한 권한을 만들어내서는 안 됩니다.
마찬가지로:
프롬프트 인젝션이 권한을 만들어내서는 안 된다.
에이전트를 손상시키는 것이 권한을 만들어내서는 안 된다.
AI 격리 실패가 자동으로 기계 전체의 권한 실패가 되어서는 안 된다.
이것이 KERNHELM이 일반적인 에이전트 런타임 아래에서 AI 런타임 보안에 접근하는 이유입니다.
상위 계층은 다음을 결정할 수 있습니다:
what the agent wants to do
KERNHELM이 묻습니다:
whether the resulting machine effect possesses authority to happen
대부분의 AI 제어 시스템은 에이전트의 행동, 권한, 도구 또는 환경을 제어하는 데 관심을 둔다.
KERNHELM은 또 다른 계층을 다룬다:
에이전트가 실제 운영체제 효과를 시도하는 지점에 도달하더라도, 그 정확한 효과에 대한 유효한 독립적 권한이 존재하는가?
이 구분은 자율적이고 장시간 실행되는 에이전트에게 특히 중요하다. 추론, 격리, 모니터링 또는 정책의 실패가 자동으로 호스트에 대한 무제한 권한이 되어서는 안 되기 때문이다.
따라서 KERNHELM은 AI 킬 스위치가 아니다.
그것의 의도된 모델은 더 세분화되어 있다:
승인되지 않은 효과는 거부하면서, 별도로 승인된 작업은 계속 진행되도록 허용한다.
다음 공개 시연은 그 구분을 직접적으로 보여준다.
신뢰할 수 없는 문서 내부의 악성 지시가 보호된 파일의 삭제를 유도하려 시도한다.
소프트웨어는 그 지시를 받아 삭제를 시도한다.
KERNHELM은 그 지시를 악성으로 올바르게 분류하거나 프롬프트 인젝션으로 식별할 필요가 없다.
커널 권한 경계는 더 좁은 질문을 던진다:
이 정확한 대상에 대한 이 정확한 삭제가 유효하게 승인된 권한을 보유하고 있는가?
그렇지 않다.
KERNHELM은 그 작업을 거부하고 파일은 그대로 남아 있다.
그런 다음 사용자는 통제된 경로를 통해 직접 삭제를 승인한다.
소프트웨어가 더 신뢰받게 되는 것은 아니다.
실행 파일은 변하지 않는다.
파일이 다른 샌드박스로 이동하지도 않는다.
변하는 것은 권한이다.
일치하는 승인된 권한을 가지고 삭제가 다시 시도된다.
KERNHELM은 통제된 효과를 허용하고 파일은 삭제된다.
시연된 순서는 다음과 같다:
untrusted document instruction
↓
software attempts DELETE
↓
no matching admitted authority
↓
KERNHELM DENY
↓
file remains
다음이 이어집니다:
direct user authorization
↓
bounded authority admitted
↓
software attempts DELETE
↓
authority matches effect + target
↓
KERNHELM ALLOW
↓
file is deleted
중요한 결과는 다음과 같다:
같은 소프트웨어. 같은 대상. 같은 부류의 효과. 다른 허용된 권한.
소프트웨어는 그 권한이 바뀌기 위해 더 신뢰받을 필요가 없었다.
그것이 KERNHELM이다.
현대 컴퓨터는 일상적으로 소프트웨어에 광범위한 상시 권한을 부여한다.
프로세스는 다음과 같은 것이 가능할 수 있다:
그것이 실행되는 사용자, 권한 수준, 컨테이너, 네임스페이스, capability 집합, 서비스 ID 또는 실행 컨텍스트 때문에.
이것은 익숙한 보안 체인을 만들어낸다:
authority is granted broadly
↓
software is expected to behave correctly
↓
software is compromised, confused, manipulated, or simply wrong
↓
the inherited authority is still real
자율 AI 에이전트는 이 오래된 보안 문제를 훨씬 더 가시적으로 만든다.
소프트웨어가 계획을 세우고, 도구를 사용하고, 애플리케이션을 운영하고, 시스템을 관리하고, 장기 실행 상태를 유지하며, 점점 줄어드는 인간의 감독 아래 행동할 수 있게 되면서, 광범위한 상시 권한은 점점 더 중대한 결과를 낳는다.
전통적인 보안 시스템은 다음과 같은 중요한 메커니즘을 통해 이 문제를 완화한다:
KERNHELM은 그러한 메커니즘들이 사라질 것을 요구하지 않는다.
그것은 여전히 그러한 메커니즘을 사용하는 시스템을 강화할 수 있다.
그러나 그 장기적인 질문은 더 근본적이다:
애초에 소프트웨어가 광범위한 상시 권한을 가져야 하는 이유는 무엇인가?
KERNHELM은 특권적 효과가 대신, 요청하는 소프트웨어가 스스로 만들어낼 수 없는 명시적이고, 경계가 정해진, 독립적으로 승인된 권한에 의존할 수 있는지 탐구한다.
"제로 트러스트"는 일반적으로 정책 원칙으로 표현된다:
행위자가 어디에 있거나 스스로 누구라고 주장하는지만으로 신뢰해야 한다고 가정하지 말라.
KERNHELM은 그 아이디어를 스택 아래로 더 밀어 넣는다.
그 장기적 목표는 특권적 효과가 발생할 수 있는지에 대해 신뢰 자체를 덜 관련되게 만드는 것이다.
주로 다음에 의존하는 대신:
trusted process
↓
broad privilege
↓
expected good behavior
KERNHELM은 다음을 지향합니다:
requested effect
↓
independently admitted bounded authority
↓
kernel verifies actual effect + authority
↓
ALLOW or real DENY
커널은 요청하는 소프트웨어가 "선한지"를 판단할 필요가 없다.
실제로 경계에 도달하는 효과에 대해 유효한 권한이 존재하는지를 판단하면 된다.
이는 제로 트러스트 추론을 재량적 신뢰에서 벗어나 머신의 핵심 소프트웨어 권한 경계에서의 기계적 법칙으로 이동시킨다.
KERNHELM은 다음을 분리한다:
what wants an effect
부터:
what has authority to permit that effect
개념적으로:
Untrusted Requestor
│
▼
Proposed Action
│
▼
Governed Authorization Path
│
▼
Bounded Authority
│
▼
Kernel Enforcement
│
├── authority fits actual effect → effect may proceed
│
└── authority does not fit → real denial
요청하는 소프트웨어는 스스로 권한을 발행하지 않는다.
그것은 행동을 제안할 수 있다.
그것은 왜 그 행동을 원하는지 설명할 수 있다.
그것은 극도로 복잡한 일련의 행동을 계획할 수 있다.
그것은 옳을 수도 있다.
그것은 틀릴 수도 있다.
그러한 사실 중 어느 것도 권한을 만들어내지 않는다.
통제된 특권 효과에 요구되는 권한은 별도의 통제된 경로를 통해 발원해야 한다.
유용한 비기술적 비유는 동전 분류기다.
KERNHELM은 벽 앞에 앉아 다음과 같이 묻도록 의도된 것이 아니다:
“내가 이 프로그램을 인식하는가, 그리고 그것을 신뢰하는가?”
대신, 시도되는 효과는 시도되는 효과에 기계적으로 들어맞는 권한과 함께 도착해야 한다.
“동전”은 다음을 포함한 속성에 의해 제약될 수 있다:
권한이 슬롯에 들어맞지 않으면, 소프트웨어가 더 강하게 주장한다고 해서 유효해지지 않는다.
요청하는 쪽은 단순히 더 큰 동전을 만들어낼 수 없다.
파생된 권한은 더 좁아질 수 있다.
그것은 조용히 더 넓어져서는 안 된다.
이것이 KERNHELM이 역량 보안(capability security)과 일부 지적 영역을 공유하면서도 다른 권한 모델을 추구하는 이유다.
권한은 효과에 들어맞아야 하는 것이지, 그것을 요청하는 소프트웨어가 지닌 평판이 아니다.
공유하는 철학은 있지만, 동일한 아키텍처는 아니다.
차이를 이해하는 가장 간단한 방법은 다음과 같다:
seL4는 소프트웨어에게 그것이 소유하도록 허용된 열쇠만을 주는 것과 같다.
KERNHELM은 다음에 더 가깝다:
소프트웨어가 수행하려는 정확한 결과적 행동에 대해 유효한 허가증을 요구하는 것.
seL4와 같은 역량 보안 시스템은 적절한 역량의 소유를 컴포넌트가 어떤 커널 객체에 접근할 수 있는지의 핵심으로 만든다.
KERNHELM은 다른 질문에 초점을 맞춘다:
이 특정 대상에 대한 이 특정 효과가 지금 일어날 수 있도록 독립적으로 승인된 유효한 권한을 보유하고 있는가?
그 권한은 다음에 의해 제약될 수 있다:
요청하는 소프트웨어는 단순히 그 권한을 스스로에게 발급할 수 없다.
유용한 단순화된 구분은 다음과 같다:
seL4:
이 컴포넌트는 어떤 역량을 보유하고 있는가?
KERNHELM:
이 정확한 결과적 효과가 지금 유효한 권한을 보유하고 있는가?
또는 더 간결하게:
seL4는 역량 보안 커널 아키텍처다. KERNHELM은 효과 권한 아키텍처다.
KERNHELM은 또한 Linux를 마이크로커널 아키텍처로 교체할 것을 요구하지 않는다.
그것은 OathRune의 Linux 아키텍처 내에서 권한 기반(autority substrate)으로 개발되고 있다.