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である。
現代のコンピュータは、日常的にソフトウェアに広範な地位権限を与えている。
プロセスは以下のことができる場合がある：
それは、実行されているユーザー、特権レベル、コンテナ、名前空間、ケイパビリティセット、サービス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 がケイパビリティセキュリティと知的領域の一部を共有しながら、異なる権限モデルを追求する理由である。
権限とは効果に適合しなければならないものであり、それを要求するソフトウェアが持つ評判ではない。
共有された哲学はあるが、それらは同じアーキテクチャではない。
違いを理解する最も簡単な方法は：
seL4 はソフトウェアにそれが保持を許された鍵だけを与えるようなものである。
KERNHELM はより次のものに近い：
ソフトウェアが実行しようとしている正確な結果を伴うアクションに対して有効な許可証を要求する。
seL4 のようなケイパビリティセキュアシステムは、適切なケイパビリティの所持を、コンポーネントがどのカーネルオブジェクトにアクセスできるかの中心とする。
KERNHELM は別の問いに焦点を当てる：
この特定の効果が、この特定のターゲットに対して、今起こるための有効な独立して認められた権限を所持しているか？
その権限は以下によって制約されうる：
要求元のソフトウェアは単にその権限を自分自身に発行することはできない。
有用な簡略化された区別は：
seL4：
このコンポーネントはどのケイパビリティを所持しているか？
KERNHELM：
この正確な結果を伴う効果は今有効な権限を所持しているか？
あるいはより簡潔に：
seL4 はケイパビリティセキュアなカーネルアーキテクチャである。KERNHELM は効果権限アーキテクチャである。
KERNHELM はまた、Linux をマイクロカーネルアーキテクチャに置き換えることを要求しない。
それは OathRune の Linux アーキテクチャ内の権限基盤として開発されている。
KERNHELM は、従来のシステムがしばしば一緒に崩壊させてしまういくつかの役割を意図的に分離する。
信頼されていないプランナーは、何を達成したいかを決定する。
そのプランナーは以下のものでありうる：
計画は権限を生み出さない。