Skip to main content

Sekisho

Sekisho (関所) is Ninka's compile-time inspection of a Tegata. It runs before Ninka publishes artifacts for that policy set.

A Tegata first has to satisfy the JSON Schema. Sekisho then applies the semantic and set-level checks that Ninka defines beyond the schema.

What Sekisho checks​

Sekisho is deliberately narrower than human review. It rejects or warns about problems that Ninka can determine mechanically, such as:

  • a direct allow/deny contradiction with the same scope;
  • an allow rule that can never take effect because a deny rule fully contains it;
  • inconsistent input types or invalid references;
  • duplicate policy ids or cross-policy deny placement that cannot affect the policy it was meant to restrict;
  • undeclared roles, actions, resource types, or attributes when the project uses a closed-world vocabulary.json;
  • other semantic hazards defined by the Tegata specification.

Some checks are errors and stop compilation. Others are warnings or informational findings that make a review concern visible without changing the authorization decision.

The exact rules and severities belong to the Tegata specification and the toolchain contract; this page explains the role Sekisho plays in the workflow.

What Sekisho does not prove​

A Tegata can pass every mechanical check and still express the wrong business requirement.

The responsibility boundary is:

  • a human reviews what the authorization specification should say;
  • Sekisho checks the properties Ninka can determine mechanically;
  • the compiler deterministically turns the accepted specification into Rego.

Passing Sekisho is therefore not human approval, not a proof that every important scenario was tested, and not a general security certification.

Diagnostics are actionable​

When a check fails, Ninka's diagnostic identifies what failed with enough context to locate the problem. When Ninka knows a concrete remediation, the diagnostic also tells you how to fix it.

The exact wording or number of lines is not part of the contract. Current CLI messages are usually compact, but Sekisho is not specified as a “one-line error” system. Ninka also does not dump an internal raw stack trace as the user-facing diagnostic.

This still gives an AI coding agent a useful feedback loop:

agent proposes Tegata
        ↓
ninka-authz compile
        ↓
Sekisho diagnostic, if any
        ↓
agent revises the proposal
        ↓
human reviews the resulting specification

The loop can remove mechanically detectable defects before review. It cannot replace the review itself.

Compile-time, not request-time​

Sekisho runs when the policy set is compiled. It is not on the application's request path.

At runtime, the Ninka runtime evaluates the compiled WASM for each authorization check. These are different responsibilities: Sekisho inspects the specification during the build workflow; the runtime evaluates concrete authorization inputs during application execution.

See Review Authorization for the human review boundary and Test Authorization for the other evidence layers.