Technical brief
Model output is intent, not authority.
Aukora is a cryptographic authority and receipt layer for AI agents. A model may propose an action; a separate kernel decides whether it happens, scopes the permission to a single use, and records the outcome — allowed or refused — as a signed, hash-chained receipt anyone can verify. This brief is for people evaluating the system, so it states plainly what is working today and what is still designed.
The model proposes. The kernel decides. The receipt proves.
1 · Architecture
Aukora separates three planes that most agent stacks fuse together:
A small policy layer that classifies every proposed effect and decides allow / refuse. It is deliberately not the model, not the editor, and not the tool — it is the checkpoint they all pass through.
Permission to cause a specific effect. It is scoped to that effect, consumed exactly once, and never held ambiently by the model. No standing or blanket grants.
An append-only, hash-chained log where each entry names the one before it by hash and is signed. It is the trust object — not a dashboard, not the model's prose.
Because the boundary lives at the one line where any agent reaches for a tool, the host — an IDE, an API, an MCP server, a workflow, an agent runtime — stays swappable. Aukora attaches to the host's action surface rather than replacing it.
2 · Core invariants
These are the load-bearing rules. They hold regardless of which model, engine, or tool is in play.
- Model output is intent, not authority. A model can propose, draft, rehearse, and argue for an action. It can never be the thing that authorizes it.
- A separate kernel decides. The component that judges an action is not the component that produced it. Advice — even unanimous multi-model advice — is evidence, never a grant.
- Authority is scoped and consumed once. A permission authorizes one specific effect and cannot be replayed for another.
- Every protected effect leaves a receipt — and so does every refusal. A blocked action is recorded, not silent.
- High-risk effects require a human signature. They are bound to proof that a person approved the exact scope, made deliberately, every time — no silent self-authorization.
- Evidence is portable. The receipt chain can be verified by a second party without trusting the model's claims or the machine that produced them.
3 · The authority flow
End to end, a protected action moves through the same path:
intent→classify (ring / risk)→gate: allow / refuse→scoped one-time token→mediated effect→signed receipt→independent verify
Low-risk reads and drafts flow freely. The moment an action would change your world — write a file, call a tool, touch data, reach outside the machine — it is classified, gated, and (if allowed) executed only through a permission minted for that one effect. Refusals short-circuit before any effect and are themselves receipted.
model→tool→effectOutput becomes an action directly. No authority boundary, no record.
model→intent→gate→token→mediated tool→receipt→verifierThe effect happens only through a scoped, one-time token — and it's provable afterward.
4 · The receipt
A receipt is the atom of evidence. Each one records what was authorized and what happened (or was refused), names the receipt before it by hash, and is signed — so rewriting recorded history breaks the chain and shows. From that single object several proofs can be derived without trusting the model:
Signatures are Ed25519. Content can be erased on request (right-to-be-forgotten) while the chain still proves the erasure occurred. The exact on-disk record format is being stabilized ahead of public release; treat field-level specifics as not-yet-final.
5 · What is working vs designed
Conservative on purpose. "Lab" means proven in the working tree with a large real test suite; "dev-real" means running but still hardening; "research lab" means running live in the experimental lane, not yet merged into the core; "designed" means specced, not yet built; "research · direction" means a direction being explored — nothing built yet.
6 · Integrating a tool
Adoption is at the effect boundary, not a rewrite. Conceptually:
- Identify the effect you want governed (a shell call, an API request, a broker order).
- Route that call through the gate: the agent submits it as intent, not a direct call.
- The kernel classifies and decides. If allowed, it mints a one-time token scoped to that effect.
- The effect executes only with that token, then a signed receipt is written.
- Any party can later verify the receipt chain independently.
Aukora can also help generate adapters for a new host, but a generated adapter gains no authority automatically. New adapters must be approved, scoped, tested, and activated through the gate — the same rule as any other effect.
7 · Limitations — what it does not claim
- It authorizes and records the AI's actions. It does not replace formal model validation, and it is not a certification (HIPAA, SR 11-7, etc.).
- It closes the physical / tokenizer-level covert channel (invisible-Unicode, homoglyph'd authority words). Semantic steganography — a payload hidden in ordinary wording — remains unsolved industry-wide; we don't claim otherwise.
- The human key is, today, the whole authority. Lose it and there is no reset; whoever holds it can act as you. Additional proofs (starting with voice) are being built, not shipped.
- It is a young, actively-built project. The receipt chain would expose an overclaim, so we don't make them.