Authorization Compiler
Authorization, as a specification.
Ninka turns the declarative authorization specification Tegata into deterministic Rego, then connects it to executable OPA WASM.
npm install ninka-authznpm ↗Requirement (natural language)
Written by your AI agent
Deterministic Rego
Your app just calls check()
Problem
Authorization is a specification. Not implementation.
As AI writes more code, authorization logic spreads across implementations faster than humans can keep up.
if (user.role === "admin") { ... }
if (invoice.ownerId === user.id) { ... }
if (user.department === invoice.department) { ... }Defining authorization directly in implementation is no longer practical. Ninka is an authorization compiler — not a policy engine, policy language, or authorization platform.
How It Works
AI writes the spec. Humans review it. Ninka compiles it.
AI generates only Tegata. Humans review the authorization specification. Ninka deterministically emits Rego, OPA builds the WASM, and the Ninka Runtime evaluates that WASM in-process.
Live Demo
Features
What only a compiler can do
Review the authorization specification, not the implementation
AI writes only Tegata. Humans review changes to the authorization specification, and the compiler generates the implementation.
Tegata: A travel permit required to pass through Edo-period checkpoints.
Inspect the specification and generate validation
At compile time, Ninka checks mechanically detectable problems such as schema violations, inconsistent references, contradictions, and dead exceptions. It also derives validation vectors from Tegata and uses them to verify the generated policy.
Sekisho: A checkpoint where travel permits were inspected before passage was allowed.
Reproduce the same implementation from the same specification
The same canonical Tegata produces byte-identical Rego. Ninka uses a pinned OPA toolchain to build WASM from that Rego.
Hangi: A woodblock used in the Edo period to reproduce the same document repeatedly.
Add no meaning that was never written
Decisions not written in the authorization specification are never introduced into the executable policy. The runtime executes policy generated from the approved specification, not AI inference or implicit knowledge.
Unwritten rules: Customs or assumptions that exist only as implicit knowledge.
Authorization Reference
Review authorization as a specification, not as code.
The specification, the rules it compiled into, the validation results, and the decision the actual WASM returns — all on one screen.
Read the whole picture
From Policies, Resources, Roles, and Actions down to individual rules and conditions. Read the structure of your authorization without following implementation code.
Check the actual decision
Change an input in place and evaluate the compiled WASM. See how the authorization you read as a specification actually decides.
Know what you are looking at
LIVE is the current compiled state; when the specification moves ahead of it, it is marked STALE. SNAPSHOT fixes a verified authorization state so it can be shared.
$npx ninka docs
FAQ
FAQ
Q. What is Ninka — and what is it not?
A. Ninka is an Authorization Compiler. It is not a policy engine, policy language, or authorization platform. It turns reviewable Tegata into deterministic Rego and connects that output to executable OPA WASM.
Q. Is it okay to let AI write authorization?
A. AI writes the Tegata, not the enforcement code. Humans review the Tegata as the authorization specification, while Sekisho checks the mechanically detectable problems that Ninka defines.
Q. Do I need to know OPA or Rego?
A. You can use Ninka without them. Rego is generated from the Tegata, so nobody writes it by hand — though knowing it never hurts, and you can read the generated Rego at any time.
Q. Does this compete with OPA?
A. No. Ninka is not a policy engine. It compiles Tegata to Rego, OPA builds the WASM, and the Ninka Runtime evaluates that OPA WASM in-process.
Q. How is the generated policy verified?
A. The compiler derives validation vectors from Tegata and runs them against the built WASM. ninka verify re-derives the committed validation table, re-runs it against the committed WASM, and verifies artifact hashes and lineage.
Q. Is Authorization Reference an authorization server or admin dashboard?
A. No. It is a read-only projection of compiled authorization state. It never writes to the project or compiles. LIVE reads the current project on loopback; SNAPSHOT can be placed on a static host. Application authorization decisions never route through the Reference.
Q. Is it actually free?
A. The local tools are. The license is BUSL-1.1: read it, modify it, just don't resell it as a competing service. It converts to Apache-2.0 in 2030.
Get Started
Run Ninka locally
Install the CLI and create your first authorization specification.