Risk-Tiered Autonomy: How Koinessa Gates Agent Authority

2026-08-30 · Engineering ·

You want the leverage. You do not want the incident report. Every technical founder running AI agents against a real codebase hits the same wall: the agents are fast enough to be dangerous, and the only two configurations on offer seem to be "approve everything yourself, forever" or "let it rip and hope." The first makes you the bottleneck on every dependency bump. The second means an autonomous process can delete data, push to production, or email a customer while you are asleep. Neither is an operating model.

There is a third option, and it is not new. It is the answer mature engineering disciplines arrived at decades ago: grade actions by blast radius, make controls proportional to risk, and encode those controls as testable, versioned artifacts rather than vibes in a prompt. This post expands Section 5 of the Koinessa brain white paper, which builds that answer into a working system as two machine-readable tier axes — and shows what it costs to cross a boundary between them.

The false choice between manual everything and autonomous everything

Full manual review does not scale with agent throughput, and full autonomy does not survive contact with irreversible actions. Tiering beats both because it refuses to treat "what the agent is doing" as one category. Writing a documentation index and deleting a production table are both "actions the agent performed," but they differ by orders of magnitude in reversibility, blast radius, and the evidence you would want before allowing them. One gate for both either strangles the safe 90 percent or waves through the dangerous 10 percent.

The white paper's framing is worth stating precisely: autonomy should expand by proving which classes of action can be delegated under which controls — never by declaring a system autonomous. That is a claim about process, not model quality. A better model does not change the blast radius of DROP TABLE; it only changes how confidently the mistake is made.

Two axes, one discipline

Koinessa carries two tier axes, and they measure different things. Confusing them is how permission systems rot.

The first axis is the verification tier R0-R3 (designator AAV-001, live). Every work item gets a machine-readable tier that deterministically derives its required gates, its brief requirement, and its approval policy. This axis answers: how much rigor does this work item owe?

The second axis is the action tier 1-4 (EGA-001, live), which grades action classes by blast radius from reversible to irreversible, evaluated fail-closed by versioned policy. It answers: how dangerous is this kind of action, regardless of who or what requests it?

The action axis, with the nominal work-item correspondence in parentheses:

One honest caveat the white paper prints: the two axes collided in type names during development, and a work item (EGD-002) removes the residual collision and pins the crosswalk as a tested module. That is what a tier model looks like as code rather than slideware — the seams get tracked as engineering work.

Policy as versioned code, not prompt text

The load-bearing decision in the whole design is where the permission logic lives. If the rule "agents may not delete production data without approval" exists only as a sentence in a system prompt, it is enforced by the same stochastic process it is supposed to constrain. Prompt text is advisory. It drifts with model versions, gets truncated under context pressure, and cannot be diffed, tested, or audited.

The cloud-native ecosystem settled this years ago. The Open Policy Agent — a graduated CNCF project and the reference the white paper cites for the pattern — is a general-purpose policy engine built on one idea: decouple policy decision-making from enforcement, and express policy in a declarative language (Rego) so that "which actions are allowed under which conditions" is code, evaluated against structured input. Policy as code means the rule has a version history, a test suite, and a review trail, exactly like the rest of your engineering. The white paper is careful here: OPA is one source for the general pattern, and Koinessa does not claim to embed OPA. What Koinessa takes is the discipline — permissions evaluated against versioned policy with persisted decisions, so every allow or deny is itself a receipt you can replay.

This is also what makes the fail-closed property meaningful. When policy evaluation cannot produce a positive decision, the default is refusal, not best-effort. A tier system that fails open is a labeling exercise.

NIST already wrote the job description

None of this requires inventing a governance vocabulary. Two NIST publications do most of the framing work, and the white paper maps its controls onto them explicitly.

The NIST AI Risk Management Framework — AI RMF 1.0, released January 26, 2023, with the Generative AI Profile (NIST AI 600-1) following on July 26, 2024 — is a voluntary framework for incorporating trustworthiness into the design, development, use, and evaluation of AI systems. Its core move is the one tiered autonomy makes concrete: AI risk management is not a posture you declare, it is a set of functions you operate continuously, with rigor proportional to the risk of the use case. A documentation generator and an autonomous deployment pipeline are both "AI systems," and the RMF's premise is that treating them identically is a category error.

The second anchor is the NIST Secure Software Development Framework, SP 800-218 v1.1 (February 2022), plus SP 800-218A, the generative-AI SSDF Community Profile finalized in 2024. The SSDF exists because few SDLC models address security in detail, so it supplies a core set of practices and a common vocabulary that software purchasers can use with suppliers. The white paper's limitation section is blunt about what this means for Koinessa itself: frameworks are guidance, a control is implemented behavior, evidence proves the behavior occurred, and certification is a separate determination the platform has not undergone. That ordering is exactly the audit answer a tiered system is built to preserve.

Crossing a tier boundary should cost ceremony

The strongest paragraph in Section 5 is not about policy. It is about a database migration. Renaming the identity key stamped on every row of the Koinessa Brain — part of the primary key in many tables — sounds like one UPDATE statement. The system executed it as forty-seven sequential full-table rebuilds instead: build, bulk-insert, atomic rename, checkpoint, verify, with 110,811 rows re-keyed live and zero corruptions. The reason is the best part: an earlier in-place key update had corrupted the database. The expensive path was chosen because the cheap path had already failed once, in production, with receipts.

That is the tier model's philosophy in miniature. Tier boundaries are only credible when crossing them costs ceremony — measured criteria, recorded per activation: collision rates, stale-worker rates, verified success rates, human-intervention frequency, rollback effectiveness. Promotion is earned from operating history, never granted because the system has been quiet lately. Quiet is not evidence. This is the same discipline behind evidence-gated development: the loop does not grade its own homework, and the gate does not relax because passing became routine.

Built-but-gated is a feature, not a confession

Koinessa's Autopilot path — the machinery that takes an approved requirements document through implementation to a verified green pipeline — is labeled built-but-gated, and the label is deliberately unglamorous. It has run supervised live drills end to end. Its ruling-locked posture is fail-closed, and re-arming it is an explicit operator action, not a timeout that quietly expires.

This matters for how you read capability labels generally. The white paper prints a status and limitations report alongside the architecture: live, in flight, built-but-gated, and planned are distinct claims, and conflating them is how vendor decks lie to you. A system that tells you which parts it does not yet trust itself with gives you more usable information than one claiming full autonomy. Systems should earn authority from operating history, and the earning process should be boring.

Raising autonomy without losing the audit answer

The payoff of all this structure is not caution for its own sake — it is that autonomy becomes raisable. When every work item carries its verification tier, every action class carries its blast-radius grade, and every permission decision is a persisted record evaluated against versioned policy, then "give the agents more rope" stops being a leap of faith and becomes a controlled experiment. You promote one action class, on one axis, with measured criteria in front of you, and the audit trail of what changed and why writes itself. The evidence bundles map onto SSDF-style assurance expectations, so when a client, investor, or security reviewer asks "who authorized this, under whose authority, with what proof," the answer is signed evidence rather than assurances. That is the difference between human-gated automation and hoping your prompt was stern enough.

The takeaway

You do not have to choose between being the approval bottleneck and handing irreversible decisions to an uncontrolled agent. Grade work items by the rigor they owe (R0-R3), grade actions by blast radius (tiers 1-4), encode permission logic as versioned, testable, fail-closed policy rather than prompt text, and make every tier promotion earn itself against recorded operating history. That is the model Section 5 of the Koinessa brain white paper lays out, with the AAV-001 and EGA-001 machinery behind it. For why an AI operating system needs this discipline at every layer, not just at the permission gate, start with the series overview and the full white paper.