Risk-Tiered Autonomy: How Koinessa Defines Agent Permissions
Most AI agent failures don’t come from poor logic. They come from ambiguous permissions. An agent writes the code, but does it have the right to deploy it? Does it get to rotate the secret? Does it have permission to contact the customer about the incident?
When permissions are binary (on/off) or vaguely defined ("best effort"), you create a system that is either too slow to be useful or too loose to be safe. The core thesis of the Koinessa whitepaper argues that you need granular, automated control over what an agent can do, based on the blast radius of that action.
This is the concept of risk-tiered autonomy.
Defining the R0-R3 Tiers
Koinessa structures agent autonomy into four distinct tiers, labeled R0 through R3. Each tier defines specific permissions and corresponding verification requirements. The higher the tier, the greater the autonomy, but also the stricter the gates before an action is permitted.
R0: Read-Only and Local Analysis
At the base tier, agents can read code, logs, and documentation. They can perform local analysis, generate suggestions, or draft code in a sandboxed environment. No state is changed. No external calls are made. This is where "retrieval before repetition" happens; the agent pulls context from the shared brain to ensure it isn't repeating old mistakes.
R1: Reversible Local Changes
Tier R1 permits changes that are strictly local and reversible. An agent in R1 might refactor a function, fix a type error, or update a local test file. The key constraint is reversibility. If the CI pipeline fails, the change is discarded without human intervention. This tier automates the tedious, low-risk maintenance work that often clogs engineering backlogs.
R2: State-Modifying with Human Gates
This is where the rubber meets the road. R2 agents can modify state in the development environment, push to feature branches, or trigger integration tests. However, these actions are not fully autonomous. They are gated by deterministic verification. If the agent attempts to merge a branch, the verification layer runs a full suite of checks: security scans, performance benchmarks, and contract validations. If the evidence packet fails, the action is blocked. This is human-gated automation; the system requires a "verified green pipeline" before proceeding.
R3: Production and External Actions
R3 is the highest tier of autonomy. It covers actions that affect production systems or external stakeholders: deploying to staging, rotating production secrets, or sending incident notifications. These actions are rarely, if ever, fully automated. They typically require explicit human approval or are restricted to a narrow set of predefined, low-risk scenarios (like a self-healing restart of a failed service) that have been explicitly whitelisted.
How the Tier Gate Is Automated
The value of these tiers lies not in the definitions, but in the automation of the gate itself. In traditional DevOps, you might have a policy as code check that says "prohibit direct pushes to main." But that doesn't tell you why a change is safe.
Koinessa automates the tier gate through deterministic verification. When an agent attempts an action, the system evaluates the action against the current risk tier.
- Action Classification: The agent's intended action is classified. Is it a read? A local write? A remote write?
- Policy Match: The system checks the active policy for that component. Does this service allow R1 writes?
- Verification Trigger: If the action crosses a tier threshold (e.g., moving from R1 to R2), the verification engine kicks in. This isn't a simple linter. It runs the specific checks defined for that risk profile.
- Evidence Gating: The result is binary. Pass or fail. The output is an evidence packet containing the logs, scan results, and test outcomes.
This automation removes the "trust but verify" overhead. You don't need a human to read the diff to see if the agent made a risky change. The system proves it, or it blocks it.
Why This Beats Vague Permissions
A common mistake in agentic development is giving agents broad permissions and hoping for the best. "The agent can do what it needs to do." This is a liability. If the agent hallucinates a deletion command, you hope it works.
Risk-tiered autonomy flips this. You start with the assumption that the agent cannot do anything. It earns permissions by passing verification gates.
This approach also scales. As your team grows and your systems become more complex, the tiers remain consistent. A new microservice doesn't need a new permission model; it inherits the R0-R3 structure. This creates a consistent operational truth across the organization.
The Role of the Shared Brain
The tier gate doesn't operate in a vacuum. It relies on the persistent shared memory of the Koinessa brain. If an agent previously failed an R2 verification on a similar type of change, the brain retains that outcome. The next time a similar change is attempted, the verification layer can prioritize the specific checks that failed before. This is how the system improves over time. It doesn't just remember that something failed; it remembers why, and it tightens the gate accordingly.
This creates a feedback loop:
- Agent attempts action.
- Gate verifies.
- Outcome (pass/fail) is stored in the brain.
- Future gates are informed by past outcomes.
Implementing Tiers in Your Stack
You don't need a specific proprietary tool to implement this concept. You need:
- A clear definition of blast radius. What happens if this action fails?
- Deterministic checks. Tests and scans that produce binary results.
- A policy engine. Something that maps actions to tiers.
- Persistent state. A way to remember past failures and successes.
Koinessa provides these components as an integrated system. But the architecture is the key takeaway. If you are building agentic systems today, ask yourself: What is the R1 permission for this agent? What verification gate blocks an R2 action? If you can't answer those questions, you don't have autonomy. You have chaos with a chatbot interface.
Conclusion
Risk-tiered autonomy is not about restricting AI. It's about making AI reliable. By breaking autonomy into discrete, verifiable tiers, you can accelerate the safe, low-risk work (R0/R1) while maintaining strict control over high-impact actions (R2/R3).
This is how you get the speed of AI with the discipline of engineering. It’s how you move from "did it work?" to "prove it works."
For a deeper dive into the architectural details of the evidence-gated verification layer, read the full technical breakdown in the verified-delivery report or explore more engineering practices on the engineering blog.