小規模で、監査可能、終了保証、決定論的なマイクロポリシーエンジン。
Gate0 を構築したのは、本番環境で正規表現ベースのポリシーをデバッグすることにうんざりしたからです。退屈で、境界があり、クラッシュしないものが欲しかったのです。柔軟で汎用的なポリシーエンジンが必要なら、OPA を使うべきです。サブ50マイクロ秒の評価と、セキュリティクリティカルなパスでゼロアロケーションを実現するポリシーエンジンが必要なら、Gate0 が最適です。
Gate0 は、ポリシー評価が決定論的でリソースに制約がなければならない高信頼環境向けに設計されています。脆弱性の報告についてはセキュリティポリシーを、脅威モデルと機械的保証の詳細についてはセキュリティモデルを参照してください。
Gate0 は線形の Deny-Overrides 評価戦略を使用します。各ルールは Target（高速パスマッチ）とオプションの Condition（深いロジック）で構成されます。
+----------+ +-------------+ +--------+
| Ephemera | ----> | GateBridge | ----> | Gate0 |
| (Legacy) | | (Normalize) | | (Core) |
+----------+ +-------------+ +--------+
| ^
| |
+----(Shadow Log)----+
Gate0 の正当性と安全性は、コアロジックとエッジケースをカバーするユニットテスト、proptest による数百の生成シナリオを用いたプロパティベーステスト、そして MIRI によるパニックフリーかつ未定義動作（UB）フリーの検証により、機械的に確認されています。最悪ケースの入力でも確実に終了するようにテストされています。
cargo test
cargo +nightly miri test --lib
Gate0 の評価器は固定サイズのスタック割り当てバッファを使用し、評価中のヒープアロケーションをゼロに保証します。デフォルト実装では MaybeUninit を使用して未使用スロットの初期化を回避し、O(capacity) ではなく O(used) の初期化コストを実現しています。
unsafe コードは単一モジュール (fixed_stack.rs) に限定され、不変条件は単純です（要素 0..len は初期化済み、要素 len..N は未初期化）。すべての unsafe パスは MIRI で検証されています。
unsafe コードをまったく使いたくないユーザー向けに、Gate0 は safe-stack 機能フラグの背後にある SafeFixedStack を提供します。このバリアントは [T; N]（T: Default + Copy）を使用し、すべてのスロットを事前に初期化します。トレードオフとして、評価呼び出しごとに O(capacity) の初期化が発生します。
cargo build --features safe-stack
どちらの実装も同一のセマンティクスと、評価中のゼロアロケーション保証を提供します。選択はパフォーマンス（O(used)）と絶対的な安全性（O(capacity)）の間のトレードオフです。bool のような安価な Default 型を使った小さなスタックの場合、その差は無視できます。
Gate0 は、より大きなホストアプリケーション内でポリシー決定点（PDP）として機能するように設計されています。決定論と厳格な境界を維持するため、Gate0 は I/O、ネットワーキング、オブジェクトのライフサイクルを処理しません。
推奨される統合パターンは、3つの層に責任を分離します。ホストアプリケーション（API ゲートウェイ、SSH サーバーなど）は、状態、アイデンティティ、副作用を管理します。アダプタ層は、この複雑な状態を Gate0 が理解できるプリミティブ（文字列、ブール値、整数）に正規化します。Gate0 は平坦化されたコンテキストを純粋に評価し、Decision を返します。
Host Application (User Request)
│
▼
[Adapter Layer] → Pre-computes context (time, IP ranges, MFA status)
│ Converts "complex" to "primitive"
▼
[Gate0 Engine] → Pure evaluation (0 allocations, bounded stack)
│
▼
Decision::Allow / Deny
この分離により、Gate0 に IP 範囲チェックや正規表現のような複雑なマッチャーが含まれていない理由が説明されます。アダプタ層がドメイン固有のロジックを処理し、Gate0 には事前計算されたブール値または文字列属性を渡します。Gate0 は小さく、監査可能で、決定論的なままです。
use gate0::{Policy, Rule, Target, Request, ReasonCode};
let policy = Policy::builder()
.rule(Rule::allow(Target::any(), ReasonCode(1)))
.build()?;
let decision = policy.evaluate(&Request::new("alice", "read", "doc"))?;
assert!(decision.is_allow());
examples/ ディレクトリには、Gate0 の一般的な使用パターンを示す説明用シナリオが含まれています。
SaaS API: 標準的な RBAC / マルチテナンシーのロジック。 Zero Trust Network: MFA と位置情報チェックを伴う属性ベースのアクセス制御（ABAC）。 Complex Overrides: Deny-Overrides の競合解決を示します。
以下のコマンドで実行できます：
cargo run --example saas_api
cargo run --example zero_trust_network
cargo run --example complex_overrides
Gate0 は、予測可能性とパフォーマンスを維持するために意図的に制約されています。
複雑なマッチャーなし: ビットマスク CIDR や高度な正規表現などのロジックは、アダプタ層の責任です。Gate0 は前処理されたプリミティブを評価します。
ネイティブのマルチスレッドなし: 現在の Python 向け FFI 実装はスレッドセーフではありません。高並列ユーザーはマルチプロセッシングを使用するか、グローバルロックに対処するフェーズ4の FFI 安定化を待ってください。
重複する決定なし: 単一の効果クラス（Allow/Deny）内では、最初に一致したルールのみが返されます。競合解決は厳密に順序依存です。
以下のプロジェクトは、Gate0 エンジンを特殊なユースケース向けに拡張しています。
gate0_dsl: hardliner66 によって開発された、Gate0 向けの Rust ネイティブドメイン固有言語です。Rust マクロを活用して、コード内でポリシーを定義するためのクリーンで読みやすい構文を提供します。実装とドキュメントは hardliner66/gate0_dsl で見つけることができます。
MIT