deso-pk/make-trust-irrelevantAI 에이전트, 자율 시스템 및 일반 Linux 워크로드를 위한 커널 수준의 권한 및 런타임 보안.
TLDR: 나는 신뢰할 수 없는 에이전트, 스크립트, 그리고 손상된 사용자 공간 프로세스를 위한 커널 수준의 벽을 구축했다. 요점은 명시된 위협 모델 하에서, 특히 결코 실제로 부여되지 않은 권위나 신뢰를 상속받아 작동하는 것들을 포함하여, 허가되지 않은 권한 있는 효과의 전체 클래스가 실패-폐쇄되도록 만드는 것이다. 에이전트 능력의 안전한 확장에 관한 것이지, 제한에 관한 것이 아니다. 신뢰된 경로를 통해 명시적으로 서명된 행동이 아니라면, 누가 요청하든, 그 이유가 아무리 설득력 있게 들리든 실행되지 않는다.
KERNHELM은 내가 완전히 신뢰하지 않는 모든 것(AI 에이전트, 스크립트, 아직 아무도 눈치채지 못한 손상된 프로세스)과 그것이 실제로 수행하려는 권한 있는 효과 사이에 위치하는 커널 수준 시행 계층이다. 현재의 증명 차선은 파일-객체 및 실행 경계에서 그 형태를 보여준다. 더 넓은 설계는 네트워크 연결, 프로세스 검사, 장치 및 기타 권한 있는 표면으로 확장된 동일한 벽이다.
이것이 다른 모든 것과 다른 점이다. 지금까지 구축된 거의 모든 보안은 당신이 누구인지 묻는 어떤 버전을 사용한다. 비밀번호를 알고 있는가? 관리자인가? 이 키가 올바른 키인가? KERNHELM은 누구인지 묻지 않는다. 이유를 묻는다. 이 행동이 실제로 의도된 것인가, 시스템에 전혀 닿기 전에 무엇이든 서명할 수 있는 유일한 경로에 의해 서명된 것인가? 비밀번호를 아는 것은 당신이 비밀번호를 알고 있다는 것만 증명할 뿐이다. 지금 일어나고 있는 일이 일어나야 하는지에 대해서는 아무것도 말하지 않는다. 그래서 요청 측이 전혀 통제할 수 없는 완전히 별도의 경로에서 나온 암호학적으로 서명된 허가 없이는 어떤 것도 통과되지 않는다. 즉, 상대편에서 추론이 아무리 훌륭하게 들렸어도 상관없다. 신뢰할 수 없는 측은 처음부터 투표권을 얻지 못한다.
그리고 이것이 헛소리로 읽히지 않도록 하기 위해: 2026년 2월에 출원된 가특허이며, 이미 구축되고 측정되었으며, 시행 결정은 단일 자리 마이크로초에 도달하여 실제로 실행할 거의 모든 것에 중요하지 않을 정도로 작다.
나는 "모델이 아마 그렇게 하지 않을 것이다"라는 말을 실제 보안 모델로 가장하는 데 지쳐서 이것을 만들었다. 그것은 방어가 아니라 희망이며, 나는 업계 전체가 그 희망을 점점 더 정교한 언어로 포장하고 완성되었다고 말하는 것을 지켜봤다.
그래서 어떤 것이든 잘 행동하게 만들려고 시도하는 대신, 나는 더 기본적인 것을 추구했다: 잘못된 행동이 할 수 있는 모든 권한 있는 일을 하기 전에 기계적인 권위 경계에 부딪히도록 만드는 것, 그 잘못된 행동을 하는 것이 무엇이든, 그리고 들어올 때의 추론이 아무리 설득력이 있었든 상관없이.
그리고 여기 실제로 중요한 부분이 있다, 대부분의 보안 프레임워크가 반대로 이해하는 부분. 이것은 에이전트가 할 수 있는 것을 제한하는 것이 아니다. 그 반대다. 현재 사람들이 에이전트를 안전하게 실행한다고 느끼는 유일한 방법은 그것을 가두고, 도구를 빼앗고, 짧은 줄에 묶고, 계속 감시하는 것이다. 그들은 에이전트를 제한하는데, 그 이유는 그 아래의 바닥을 신뢰할 수 없기 때문이다. KERNHELM은 바닥을 견고하게 만들고, 바닥이 견고해지면 에이전트가 더 적게가 아니라 훨씬 더 많이 할 수 있게 된다. 실제 도구와 실제 접근 권한을 줄 수 있는데, 최악의 경우가 더 이상 재앙이 아니라 단지 거부된 요청과 영수증이 되기 때문이다. 벽은 에이전트가 시도할 수 있는 것을 줄이기 위해 있는 것이 아니다. 그것은 마침내 당신이 그것이 무엇인가 시도하는 것을 두려워하지 않게 하기 위해 있는 것이다.
이것은 AI 안전 프로젝트로 읽히는데, 그것이 현재 가장 시끄러운 이슈이기 때문에 말이 되지만, 실제로는 그렇지 않거나 적어도 그것만은 아니다. 내 출원서 자체도 위협을 설명할 때 "AI 모델"이라고 말하지 않는다. 그것은 통제되는 것이 LLM, 자율 스크립트, "또는 행동이 완전히 예측 가능하지 않은 다른 모든 프로세스"일 수 있다고 말하는데, 이것이 실제 목표다. 환각을 일으키는 모델과 발판을 찾은 루트킷은 이 벽에 똑같이 보인다. 왜냐하면 둘 중 어느 것도 투표권을 얻지 못하기 때문이다. 하나는 벽의 앞쪽에서, 다른 하나는 뒤쪽에서 부딪히지만 모두 시스템 호출에서 만난다.
그리고 그 범위는 당신의 것이 아닌 소프트웨어도 포함한다. 어떤 제공자가 에이전트 AI 제품을 만들고 당신이 그것을 설치하여 자신의 하드웨어에서 실행하게 한다면, 그 에이전트는 벽이 보기에 다른 신뢰할 수 없는 요청자일 뿐이며, 당신이 직접 작성한 스크립트와 다르지 않다. 그것은 여전히 동일한 로컬 확인, 동일한 로컬 입장, 동일한 서명된 허가 요구 사항을 통과해야 하며, 설치에 누구의 이름이 있는지 또는 소프트웨어가 원래 누구의 이익을 위해 구축되었는지에 관계없이 마찬가지다. 제공자는 자신의 제품이 당신의 기계에서 추가적인 지위를 얻도록 허용하지 않는다. Kernhelm이 여전히 결정한다.
내가 접한 거의 모든 접근 방식은 어떻게든 행위자를 관리하려고 시도한다. 더 나은 샌드박스, 더 똑똑한 정책, 입력에 대한 더 나은 탐지, 또는 실제로 그럴 시간이 있을 때 인간이 더 신중하게 검토하는 것 등이다. 그리고 그 모든 것은 실제로 가치 있고 할 만한 일이지만, 근본적인 문제의 형태를 실제로 바꾸지는 않는다. 즉, 하류에서 어떤 것이 행위자의 현재 행동에서 의도를 추론하려고 시도하는데, 현재 행동은 동기가 있는 공격자가 요구에 따라 만들어낼 수 있는 바로 그 것이다. 그 공격자가 한 문장을 정말 교묘하게 작성한 사람이든, 세 가지 버전 동안 조용히 앉아 있던 공급망 침해이든 상관없다.
그래서 어느 시점에서 나는 행위자가 행동하는 순간에 행위자로부터 의도를 읽으려는 시도를 중단하고, 대신 효과를 게이트하기 시작했다. 의도는 여전히 중요하며, 무엇보다 중요하지만, 그것은 사전에 실제 권위에 의해 설정되고 서명된 허가에 고정된다. 런타임에 어떤 것이 어떻게 행동하는지로부터 그것을 추측하려고 아무도 시도하지 않는다. 올바른 의도는 이미 찍혀 있었다. 벽은 형태만 확인한다.
그것이 실제로 의미하는 것은 무언가를 원하는 것과 무언가를 할 수 있는 것을 분리한 다음, 그 두 사이에 원하는 쪽이 전혀 권한을 가지고 있지 않은 벽을 두는 것이다. 오늘 특별히 잠겼기 때문이 아니라, 처음부터 열쇠를 받은 적이 없었기 때문이다.
정확히 말할 가치가 있다. 왜냐하면 우리가 실제로 에이전트가 무엇을 하길 원하는지, 어떤 가치를 제공해야 하는지, 어떤 맥락에서 어떤 행동이 완전히 괜찮고 같은 행동이 다른 곳에서는 재앙이 되는지를 결정하는 것은 인간의 질문이며, 항상 그래왔기 때문이다. 이 아키텍처에서 아무것도 그 질문에 답하려 하지 않으며, 여기 있는 어떤 것도 그렇게 의도된 적이 없다. 발행되는 모든 허가는 신뢰된 승인자(나는 이것을 Gate Clerk라고 부른다, 잠시 후에 더 설명하겠다)를 통해 사람이 내린 명시적인 결정으로 거슬러 올라간다. 벽은 무엇을 원할 가치가 있는지 처음부터 결정하지 않는다. 그것은 결코 벽의 일이 아니었다.
그것이 제거하는 것은 그 첫 번째 결정이 내려진 직후에 나타나는 두 번째 별도의 신뢰 요구 사항이다. 왜냐하면 지금은, 당신이 원하는 것을 결정한 후에, 당신은 또한 에이전트가 그것을 실제로 고수할 것이라고 신뢰해야 하기 때문이다, 매번, 공격자가 아직 생각하지도 못한 모든 가능한 표현에 대해. 그리고 그 두 번째 신뢰 요구 사항은 실제로 계속 실패하는 것이다. 왜냐하면 의도는 적대적이거나, 혼란스럽거나, 또는 당신이 의미한 바에 대해 단순히 틀린 시스템과의 접촉에서 살아남지 못하기 때문이다.
그래서 내가 "신뢰를 무의미하게 만든다"고 말할 때, 나는 가치 질문에 대해 전혀 말하는 것이 아니다. 나는 가치 질문이 이미 그것을 결정할 실제 지위를 가진 누군가에 의해 해결된 후에, 에이전트의 행동을 신뢰할 필요가 없다는 것에 대해 말하는 것이다. 당신은 여전히 당신이 원하는 것을 결정한다. 당신은 단지 에이전트가 그것을 올바르게 기억하기를, 속아서 잊지 않기를, 그리고 당신이 결정한 순간과 그것이 실제로 무언가를 한 순간 사이에 하류에서 무언가가 조용히 손상되지 않았기를 바라는 것을 멈춘다. 이것이 이 시스템이 닫는 유일한 격차다. 다른 하나는 내가 닫을 수 있는 것이 아니었으며, 코드로 누구도 닫을 수 있다고 생각하지 않는다.
메커니즘은 조각들을 보면 들리는 것보다 더 간단하다. 신뢰할 수 없는 것이 무엇이든, 당신의 에이전트, 당신의 스크립트, 무엇이든, 먼저 계획을 수립한다. 그리고 계획이란 단지 그것이 실제로 취하려는 구체적이고 명확한 일련의 행동을 의미하며, 어떤 모호한 목표 재진술이 아니다. "이 파일을 읽고, 이 주소에 연결한다"는 계획이다. "사용자의 요청을 돕는다"는 계획이 아니다. 그 계획은 계획 해시(plan hash)라는 것으로 지문이 찍힌다. 계획의 정확한 내용으로 계산된 암호학적 값으로, 계획의 세부 사항 하나라도 변경되면 해시도 함께 변경된다. 이것이 허가가 느슨한 행동 범주 대신 하나의 정확한 계획에 바인딩되도록 만드는 것이다.
그 계획은 Gate Clerk라고 부르는 신뢰된 승인자에게 전달되고, Gate Clerk는 그것을 현재 정책 입장(policy stance)에 대해 확인한다. 입장(stance)이 실제로 무엇인지는 잠시 후에 더 설명하겠다. 확인을 통과하면, SEALWYN이라고 하는 별도의 서명 엔진이 허가(permit)를 발행한다. 이것은 단지 하나의 특정 계획 해시, 하나의 효과 유형 집합, 하나의 대상 집합에 범위가 지정된 암호학적으로 서명된 토큰이며, 자체 만료 시간과 자체 제한이 내장되어 있다. 그리고 누군가가 그래야 한다고 결정하는 즉시 취소될 수 있으며, 타이머가 다 떨어질 때까지 기다리지 않는다. 행동할 권한은 이유가 나타나는 즉시, 비행 중에 즉시 철회될 수 있다.
또한 승인과 실행이 연속적으로 일어나지 않는 버전도 있다. 계획이 승인되고 허가가 발행될 수 있지만, 누군가가 명시적으로 커밋할 때까지 보류되며, 그 계획 해시는 그 동안 고정되어 있다. 이는 명백한 격차를 닫는다: 아무 것도 해롭지 않아 보이는 계획에 대해 승인을 받고 실제로 실행할 다른 계획을 조용히 바꿀 수 없다. 왜냐하면 허가는 그것이 발행된 계획 해시와만 일치하고, 다른 계획은 다른 해시를 생성하기 때문이다.
그래도 승인이 경로 문자열에 대한 느슨한 약속이 되는 것은 아니다. 현재 파일-객체 벽의 경우, 대상 정체성은 시행 지점에서 커널-가시 객체 자체에서 다시 파생되며, 파일의 장치 및 inode 정체성을 사용한다. 허가된 권한은 후크에 의해 실제로 도달된 객체와 맞아야 하며, 효과 권리, 마감일, 입장 및 취소 에포크도 포함된다. 승인이 하나의 객체에 대해 부여되었지만 실행이 다른 객체에 도달하면, 정체성이 변경되고 권한이 더 이상 맞지 않는다. 이것은 대상 및 효과 표류를 닫는다. 동일한 inode의 내용이 아래에서 변경되는 경우 파일 내용을 고정한다고 주장하지 않는다.
그리고 그 허가된 권한이 권한 있는 효과를 얻는 유일한 방법이다. 자신감, 좋은 논증, 또는 누가 묻고 있는지가 아니다. 현재 증명 차선에서 실제 벽 검사는 file_open, bprm_check_security 및 inode_unlink와 같은 LSM 검사 지점에서 커널 수준에서 발생하며, 보호된 파일-객체 액세스, 실행 및 정확한 unlink/delete를 다룬다. 더 넓은 설계는 네트워크 활동, 프로세스 검사, 장치 및 기타 권한 있는 표면에 대해 동일한 허가 형태를 목표로 하지만, 그것들은 입증된 벽에 해당 후크가 없는 한 확장 대상이다. 이 모든 것은 실제로 요청하는 것과는 완전히 별개로 존재한다. 요청자는 자신의 목줄에 근접하지도 못한다.
또한 특정 프로세스가 진정한 Gate Clerk라는 신뢰에 관한 것도 아니다. 요청 측은 자신의 권위를 설명하거나 자신의 목줄을 작성할 수 없다. Gate Clerk와 SEALWYN은 신뢰된 측에서 정책 및 서명 작업을 수행하고, 신뢰된 브리지는 제한된 허용-상태 레코드만 커널 벽에 주입한다. 후크에서 벽은 그 실시간 허용-상태를 실제로 접촉되는 것, 즉 대상 정체성, 효과 권리, 마감일, 입장 및 취소 에포크에 대해 확인한다. 메신저가 손상되어도 여전히 벽이 받아들일 상태를 발행할 수 없다.
허가 없음, 효과 없음. 누군가가 무엇을 의미했는지는 진정으로 중요하지 않다.
그리고 누군가가 "그래서 기본적으로 방화벽이군" 또는 "샌드박스 같군"이라고 말하기 전에, 차이를 분명히 해주는 그림을 보여주겠다. 전기식이 아닌 오래된 기계식 동전 분류기를 생각해보라. 단지 일렬로 늘어선 슬롯들로, 하나는 25센트용, 하나는 5센트용, 하나는 10센트용, 하나는 1센트용 크기로 되어 있다. 동전이 굴러가서 올바른 슬롯 크기이면 떨어져서 제자리에 간다. 크기가 맞지 않으면 중력이 옆으로 차낸다. 아무 것도 동전을 읽지 않는다. 동전에 대해 결정하지 않는다. 기하학은 그냥 그렇고, 잘못된 동전은 맞지 않는다. KERNHELM도 그렇게 작동한다. 허가된 행동은 올바른 크기이며, 맞아서 통과한다. 허가되지 않은 것은 단순히 맞지 않아서 차내진다. 그리고 처음부터 넣을 의도가 없었던 동전? 그것도 맞지 않았다.
그것이 방화벽이나 샌드박스가 아닌 이유다, 사람들이 먼저 그것들을 떠올리지만. 방화벽과 샌드박스는 누군가가 미리 작성한 규칙을 확인한다. 이 IP는 괜찮다, 이 syscall 범주는 괜찮다, 한 번 작성되고 대부분 그대로 두며, 개별 요청당 거의 다시 방문되지 않는다. 여기서 일어나는 일은 다르다. 왜냐하면 신뢰된 경로가 하나의 계획 해시, 하나의 효과, 하나의 대상에 대해 특별히 생성된 갓 발행된 암호학적으로 서명된 허가를 인정하고, 그것은 자체적으로 만료되기 때문이다. 커널 벽은 요청자의 이야기를 믿을 필요가 없다; 그것은 그 신뢰된 경로에서 나온 제한된 실시간 권위 상태를 확인한다. 어떤 것이 일치되기를 기다리며 앉아 있는 광범위한 목록이 없다. 신뢰된 경로가 정확히 이 요청의 형태를 지금 인정했거나, 아직 존재하지 않아서 답이 '아니오'이다. 이것은 보안 사람들이 역량 기반 권한 부여(capability-based authorization)라고 부르는 것에 더 가깝다. 접근 제어 목록은 "이 일반적인 범주의 것이 괜찮은가"에 답하는 반면, 역량은 "이 정확한 요청이 지금, 실제로 서명할 지위가 있는 누군가에 의해 서명되었는가"에 답한다.
