Earned Autonomy · Planned demonstration
Earned Autonomy for AI agents.
Evaluate broader authority against behavior and defined criteria. Keep each grant bounded by policy, customer scope, and human approval.
AvailabilityPlanned demonstration: A1 to A2 assessment in shadow mode. Recommendations leave the current grant unchanged.
Five things that are easy to blur, and must not be.
An agent's authority changes only when a person decides it should. Everything before that decision is evidence and advice. Behavry keeps each of these as a separate, recorded state.
- 01Current grant
The level an operator has assigned. It decides which action classes run without a human.
- 02Observed behavior
What the agent actually did, from its Decision Traces: sessions, denials, escalations, and drift from its baseline.
- 03Eligibility assessment
Behavry compares that evidence with criteria your tenant configures and produces a recommendation, with its reasons.
- 04Approval
A named operator, acting within authority the customer delegated, accepts or declines the recommendation.
- 05Applied change
The grant moves only after approval. The change is itself recorded, and every other control still applies.
A recommendation that changes nothing.
The first milestone runs in shadow mode. Behavry assesses whether an A1 agent meets the criteria to be considered for A2, and records the result. The agent keeps working at A1. Its permissions do not change, and no one is asked to do anything they did not choose to.
An operator reviews the evidence behind it. If they approve, the change goes through the change process you agree, not around it.
Nothing happens to the agent. Its grant stays where it is, and the next assessment starts from the same evidence rules.
Not offered. Behavry does not raise an agent's authority in production on its own, and this page does not describe a path where it would.
What each level actually means.
These are the product's own levels and the restriction profiles seeded for them, described as they are configured. A level describes which action classes run without a human. It is not a statement that an agent is safe, certified, or trusted in general.
| Level | Seeded profile, in summary | What it does not mean |
|---|---|---|
| A0 | Read, list, search, describe, and get run on their own. Writes and other side-effecting calls go to a human for approval. Sensitive resources are blocked. | The labels describe configured action classes, not authorization for a complete workflow. |
| A1 | Adds write and create. Delete, execute, run, and deploy stay constrained: they escalate to a human. Sensitive resources are blocked. | A1 is not simply read-only. Customer and resource boundaries still need their own policy. |
| A2 | Removes the autonomy profile's action allowlist, so calls are decided by policy without per-action approval. Sensitive-resource blocking remains. | OPA policy, DLP, zones, identity, restrictions, and tenant controls all still apply. |
| A3 | No autonomy-bound restriction profile. The agent is governed by policy alone. | A3 does not mean unrestricted, or outside governance. |
Described from the seeded autonomy profiles and the autonomy service in the Behavry codebase. That is the implemented foundation, not a released end-to-end promotion workflow.
What an assessment looks at.
Criteria belong to the tenant, and they are set by the people who carry the risk. The figures below are an example configuration, not a universal threshold and not a guarantee about any agent.
How far back the assessment reads. Example configuration: 14 days.
Enough sessions to judge from. Example configuration: at least 20.
The agent's behavioral baseline has been reviewed and approved, so "normal" is a known quantity.
Any escalation still waiting on a human blocks a recommendation outright.
Disqualifying outcomes. An unresolved escalation or a guardrail violation in scope should stop a recommendation. The planned demonstration will state exactly which outcomes disqualify a session. We will not claim that every relevant violation was excluded until the assessment logic supports that claim.
Scope. An assessment is about one agent, one customer, and named workflows. An agent's history in one customer's environment does not authorize work in another.
An MSP agent at A1, assessed for A2.
A future-state illustration of the planned demonstration, drawn by hand from example data. It is not a screenshot, a replay, or a live run, and nothing on it executes.
SHADOW ASSESSMENT · A1 → A2- Agent
- helpdesk-agent-01
- Customer · workflow scope
- Example Customer A · password reset, group membership tickets
- Current level
- A1
- Recommended level
- A2
- Evidence window
- 14 days · example configuration
- Configured criteria
- ≥ 20 sessions · approved baseline · 0 unresolved escalations
- Disqualifying outcomes
- Unresolved escalation · guardrail violation
- Recommendation time
- 2026-10-01 14:00 UTC · example
Verifying a recommendation. An autonomy-specific evidence export and verifier are planned, and will be offered only once they work. Today you can see how verification works on a sample Decision Trace: it checks that a package is intact and was signed by the key in the trust anchor you choose. It does not, on its own, establish that a set of promotion criteria was sufficient.
Authority is delegated. It is never assumed.
Defines the authority it delegates, and to whom. Approval rights and evidence access stay with the customer.
Approve or decline recommendations, within that delegation and nowhere outside it.
Where a provider runs the service, it owns delivery and the relationship, and brings the agent and the workflow expertise.
Enforces the configured boundaries on supported execution paths, produces the evidence, and makes the recommendation. It does not approve its own advice.
Where this stands today.
Governance and protection do not depend on any of this. You can run Behavry's enforcement and evidence without ever adopting a change in autonomy level.
| Capability | Status |
|---|---|
| Policy enforcement and signed Decision Traces on supported paths | Available within verified product and integration scope |
| Autonomy levels, seeded restriction profiles, and an eligibility assessment | Foundation implemented in the product codebase; level enforcement is opt-in per tenant |
| A1 to A2 assessment in shadow mode, with a published demonstration | Planned |
| Autonomy-specific evidence export and verification | Planned |
| Automatic promotion in production | Not offered |
Questions operators ask.
Who approves a change in an agent's level?
A named operator with authority the customer has delegated. Behavry recommends; it does not approve its own recommendation. Where an MSP runs the service, the customer still decides what authority it delegates.
What does shadow mode change?
Nothing about the agent's permissions. The assessment runs and the recommendation is recorded, while the agent keeps working at its current level under the same policy.
Does a higher level bypass policy?
No. A level binds a restriction profile. OPA policy, DLP, zones, identity, incident restrictions, and tenant controls still apply, and the tighter rule wins. A3 means policy alone, not no policy.
Does good behavior with one customer count for another?
No. Assessments are scoped to a customer and its named workflows. History in one environment does not authorize work in another.
What does verification prove?
That an evidence package is intact and signed by the key in the trust anchor you supply. It does not prove that events outside the governed path did not happen, or that a set of promotion criteria was sufficient. That judgment stays with the people approving the change.
Do I need Earned Autonomy to use Behavry?
No. Governance, enforcement, and evidence stand on their own. Earned Autonomy is an additional review you can choose to run on top of them.
- THE DECISION TRACE
The evidence an assessment reads, and how to verify a sample yourself.
- MSPS & MSSPS
Autonomy Review as a proposed partner service, next to Discover, Assess, Protect, and Command.
- ARCHITECTURE
Where enforcement happens, and how the assessment loop sits on top of it.
More authority, on evidence. Never by default.
DISCUSS AN EARNED AUTONOMY PILOT →MSP or MSSP? Discuss a pilot →