Ninka

Ninka lets you treat authorization as a specification instead of as code.

The problem

Let an AI write your application and the authorization rules arrive as conditionals: if (user.role === "admin"), scattered across dozens of handlers. Each one looks right on its own. By the time there are forty of them, nobody can state what the application currently permits.

That is not a code-quality problem. It is what happens when the thing under review is code.

What you write instead

In Ninka, one authorization policy is one small JSON document. It is called a Tegata (手形).

{
  "tegata": "0.1",
  "policy": { "id": "invoice-access" },
  "rules": [
    {
      "id": "allow-employee-view-invoice",
      "effect": "allow",
      "subject": { "roles": ["employee"] },
      "actions": ["view"],
      "resource": { "type": "invoice" }
    }
  ]
}

"An employee may view an invoice." That is the whole rule. This document is what a human reviews. Not the generated code.

Compiling it gives your application one call:

const allowed = authz.check(policies.invoiceAccess, input);

The rule itself appears nowhere in your application code.

What Ninka guarantees

What you approved is what runs. The Tegata a human reviewed and the bytes that execute are joined by a chain of hashes. The same Tegata compiled by the same Ninka release produces byte-identical Rego, every time.

Nothing is inferred. The compiler guesses at nothing. Where an AI agent interpreted a requirement, that interpretation is recorded in the Tegata itself, and a new role cannot reach the policy set without showing up in a diff.

Uncertainty closes the door. Missing input never widens access. An absent value stops an allow rule from matching, and it makes a deny rule fire — so omitting an attribute is not a way past a prohibition. See missing input.

Where Ninka stops

Ninka is not an authorization server and not an approval workflow. OPA is used to build the WASM and is not on the request path; decisions run in your own process.

Your application still owns when to ask, which resource to ask about, how to build the input, and what to do with the answer.

Where to go next

• Quickstart — get one authorization decision running.
• Tegata — the specification a human reviews.
• Review Authorization — what to check before accepting a change.
• Authorization Compiler — how a Tegata becomes the bytes that run.