Authorization Compiler

Authorization, as a specification.

AI writes Tegata. Humans review it. Ninka compiles it into deterministic Rego/WASM.

ninka — live

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.

How It Works

AI writes the spec. Humans review it. Ninka compiles it.

AI generates only Tegata. Humans review the authorization spec; Ninka generates the Rego/WASM and validation vectors.

Live Demo
Ninka pipeline: AI → Tegata → Human review → Ninka Compiler(関所 / 版木)→ Artifacts

Features

What only a compiler can do

TEGATA

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.

SEKISHO

Generate validation from the authorization specification

Validation vectors are automatically generated from the authorization specification. Boundary values, type violations, and missing data are verified before compilation. Ambiguous specifications never become policy.

Sekisho: A checkpoint where travel permits were inspected before passage was allowed.

HANGI

Reproduce the same result, every time

The same authorization specification is deterministically compiled into the same Rego/WASM. No matter when or where it runs, the same specification always produces the same result.

Hangi: A woodblock used in the Edo period to reproduce the same document repeatedly.

Elimination of Unwritten Rules

Add no meaning that was never written

Decisions not written in the authorization specification are never introduced into the executable policy. Ninka executes the authorization specification itself, not AI inference or implicit knowledge.

Fubunritsu: Unwritten customs or implicit rules.

FAQ

FAQ

Q. Is it okay to let AI write authorization?

A. AI only writes the Tegata (JSON) — it never touches the enforcement code. Every Tegata is inspected at compile time, and a bad one simply does not compile.

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. OPA is powerful, but Rego is hard to write — Ninka gives you the Tegata, an abstraction layer for authorization, and deterministically compiles it to OPA. At runtime, what runs is OPA itself.

Q. Why should I trust the generated code?

A. The Kentei. The compiler auto-derives validation vectors from the Tegata — boundary values, type mismatches, and missing data included — and runs them against both an independent reference evaluator and the production WASM. The build passes only when every vector agrees. Nobody writes these tests.

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.

Contact

0/500