関所 (Sekisho)
関所 (Sekisho) は、手形 (Tegata) に対してコンパイル時に行う検査です。ポリシー集合の成果物を生成する前に実行されます。
手形はまず JSON Schema に適合している必要があります。そのうえで関所が、スキーマだけでは表現できない意味上の検査や、複数ポリシーをまたぐ整合性の検査を行います。
関所が検査すること
関所が扱うのは、Ninka が機械的に判定できる問題です。たとえば次のようなものがあります。
- 同じ適用範囲を allow と deny の両方で定義した直接的な矛盾
- より広い deny に完全に包含され、決して有効にならない allow ルール
- 入力属性の型の不整合や、不正な参照
- policy id の重複や、意図した allow に届かない別ポリシー側の deny
- 閉世界の
vocabulary.jsonを使っている場合の、未宣言の role・action・resource type・属性 - その他、手形仕様で定義された意味上の危険なパターン
検出結果には、コンパイルを停止するエラーだけでなく、レビュー上の注意点を示す警告や情報もあります。警告や情報は認可判定そのものを変更しません。
個々の検査規則と重要度の正確な定義は規範仕様が持ちます。このページでは、開発フローの中で関所が何を担うかを説明します。
関所が保証しないこと
すべての機械的な検査に通った手形でも、業務要件の解釈自体が間違っていることはあります。
責任の境界は次のとおりです。
- 人間が、認可仕様として何を定めるべきかをレビューする
- 関所が、Ninka が機械的に確認できる性質を検査する
- コンパイラが、受け入れた仕様を決定論的に Rego へ変換する
したがって、関所を通過したことは、人間による承認を意味しません。重要なシナリオをすべて試した証拠でも、一般的な意味でのセキュリティ認証でもありません。
診断は、問題の場所と対処を分かるようにする
検査に失敗した場合、Ninka の診断は、何が失敗したのかを問題箇所を特定できる文脈とともに示します。Ninka が具体的な修正方法を判断できる場合は、その対処方法も示します。
一方で、一行で表示すること自体は契約ではありません。現在の CLI は多くの診断を簡潔に表示しますが、「関所のエラーは必ず一行」という仕様はありません。また、内部の raw stack trace をそのまま利用者向けの診断として出力することもありません。
この性質により、AI コーディングエージェントは次のような修正ループを回せます。
エージェントが手形を提案する
↓
ninka-authz compile
↓
問題があれば関所が診断を返す
↓
エージェントが提案を修正する
↓
人間が最終的な認可仕様をレビューする
このループで減らせるのは、機械的に検出できる問題です。人間によるレビューそのものを置き換えるものではありません。
実行時ではなく、コンパイル時の検査
関所はポリシー集合をコンパイルするときに実行されます。アプリケーションのリクエスト処理には入りません。
実行時には、Ninka のランタイムが具体的な認可入力に対して、コンパイル済みの WASM を評価します。関所はビルド工程で仕様を検査し、ランタイムはアプリケーション実行時に判定する。この二つは別の責任です。
人間によるレビューについては 認可をレビューする、そのほかの検証やテストとの違いについては 認可をテストする を参照してください。