Skip to main content

Review Authorization

A successful compile tells you that Ninka can mechanically accept and compile a Tegata. It does not tell you that the Tegata expresses the authorization requirement your product intended.

That question belongs to human review.

This page describes what to review before accepting an authorization change, whether the Tegata was written by a person or an AI agent.

1. Start from the requirement​

Compare the Tegata with the requirement that caused the change.

Do not start by asking whether the generated Rego looks reasonable. The Tegata is the authorization specification and the intended human review surface.

Confirm at least:

  • who should be allowed or denied;
  • which actions are in scope;
  • which resource type is in scope;
  • which attributes or relationships narrow the decision;
  • whether an exception is intentionally broader or narrower than the surrounding rules.

If the requirement itself is ambiguous, resolve that ambiguity before accepting the authorization change.

2. Read each rule as a decision​

For every rule, read the combination of:

  • effect — allow or deny;
  • subject roles;
  • actions;
  • resource type;
  • conditions;
  • relationships.

The important question is not only whether each field is syntactically valid, but what the rule actually permits or refuses when those constraints are combined.

Use Tegata Schema when you need the exact field and evaluation rules.

3. Inspect audit.ambiguities​

When audit.ambiguities is present, treat it as review material, not decorative metadata.

It records interpretation choices that the authoring process intentionally surfaced. Check that the chosen interpretation is acceptable. If it is not, clarify the requirement or change the canonical rule that encodes the decision.

The audit block itself does not change authorization semantics and is not part of tegata_hash.

4. Inspect the policy as a whole​

Run:

npx ninka-authz docs

The Authorization Reference is a read-only view of the current specification and generated state. Use it to inspect the whole policy instead of looking only at the lines changed in a diff.

When a verified WASM bundle is available, Try it can evaluate concrete inputs. Generated validation examples and interactive checks are useful evidence, but they do not replace review of the specification.

5. Treat Sekisho as a mechanical checkpoint​

Sekisho checks properties Ninka can determine mechanically, including schema, semantic, and policy-set consistency rules defined by the toolchain.

A pass means those checks succeeded. It does not mean:

  • the business requirement was correct;
  • the policy grants exactly what a product owner intended;
  • every important real-world scenario has been tested;
  • a human approved the change.

Ninka's local toolchain does not store or enforce human approval state.

6. Keep the evidence layers separate​

A green verify is not business approval. A correct Tegata is not evidence that the application mapped its session and resource data correctly. An application test does not prove that the business requirement itself was right.

Test Authorization explains what each evidence layer establishes and what it does not.

Review outcome​

Before accepting an authorization change, you should be able to answer two different questions:

  1. Does this Tegata say what the product intends?
  2. Do we have enough evidence that this accepted specification is translated, integrated, and enforced correctly for the system we are shipping?

Human review owns the first question. Ninka supplies reproducible mechanical evidence for the part of the second question that belongs to its compiler, artifacts, and runtime. The application remains responsible for its own input construction, call placement, and enforcement behavior.