Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels

Feng Xiao; Haining Zheng; Jonathan D. Bhatia; Peng Xu; Qian Dong; Rodolfo K. Depena

REVIEW 3 major objections 6 minor 10 references

Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels

T0 review · 3 major / 6 minor · reviewed 2026-07-30 · grok-4.5

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Agentic AI governance works only when what a system can do is separated from what it is allowed to do.

desk verdict Useful dual-axis split (capability vs permission) with two real deployments; the idea is clear and operational, the validation is thin and self-scored. read the letter →

arxiv 2607.23438 v1 pith:75G3S6E7 submitted 2026-07-26 cs.AI cs.CYcs.MA

Haining Zheng , Qian Dong , Rodolfo K. Depena , Jonathan D. Bhatia , Feng Xiao , Peng Xu This is my paper

classification cs.AIcs.CYcs.MA

keywords agenticAIautonomylevelsAllowedAutonomousCapabilitygovernancerisk-awaredeploymenthumanoversightenterprise

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that talks about AI autonomy usually mix two different things: technical ability and permission to act. It offers a practical governance split—Autonomous Capability Levels (what an agent can do) versus Allowed Autonomy Levels (what an organization authorizes it to do given risk, oversight, and accountability). Five paired ladders run from reactive tools and hands-on human control up to independent operations and delegated authority, and a risk-aware decision process picks the allowed level only after capability is assessed. Two deployed enterprise multi-agent systems show the point in practice: high-capability agents were deliberately held one step below their technical ceiling because of reversibility, safety, and organizational readiness. The claim is that this separation lets organizations move faster and safer without treating every capable agent as automatically free to act.

What carries the argument

The AAL/ACL separation plus a two-step decision process: first assess ACL from observable behaviors, then assign AAL only if risk is acceptable under existing responsible-AI controls, with A1 as the floor and redesign required if even A1 is unacceptable.

What would settle it

Have independent governance teams rate the same multi-agent systems on ACL and AAL; if ratings diverge widely, or if systems deployed under the framework still escalate beyond approved autonomy or fail risk controls no better than mixed single-scale taxonomies, the separation does not operationalize as claimed.

Watch

Extended reading notes

Core claim

The central claim is that Allowed Autonomy Levels (AAL)—authorization under risk, oversight, and accountability—must be decided separately from Autonomous Capability Levels (ACL)—inherent technical abilities in perception, reasoning, planning, tool use, and adaptation. Capability sets an upper bound; risk, reversibility, and organizational readiness choose the permitted level, so a high-ACL system can and often should run at a lower AAL.

Load-bearing premise

That a composed multi-agent system’s technical capability can be scored as a stable, policy-independent upper bound that different reviewers will assign consistently enough to govern real deployments.

Editorial extensions

If this is right

Enterprise reviews can approve capable agents at deliberately lower autonomy without re-scoring technical ability when policy tightens or loosens.
Autonomy can be raised or lowered incrementally as reversibility, audit trails, and organizational readiness improve, without reinterpreting capability.
Most production agentic apps are expected to sit at A1–A3; A4–A5 require stronger upfront justification and safeguards.
Multi-agent systems must be capability-rated as composed systems, not as isolated sub-agents, because autonomy emerges from orchestration.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Regulators and insurers could map liability and audit requirements to AAL rather than to model size or benchmark scores, treating capability as evidence of possible harm only.
Product teams may need explicit ‘autonomy dials’ in architecture—approval gates, reversible actions, kill switches—so the same ACL stack can be shipped at multiple AAL settings.
If ACL scoring proves inconsistent across raters, the framework’s next empirical test is inter-rater reliability and calibration guides, not more level labels.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The one thing worth knowing is the clean separation: ACL (what the system can do) as an upper bound, AAL (what you authorize) chosen by risk, reversibility, and accountability. That decoupling is the contribution. Prior ladders (SAE, Sheridan–Verplank, Feng et al. human-involvement levels, liability taxonomies) mostly collapse capability and permission into one scale. This paper names both axes, gives a two-step flowchart, and shows two production multi-agent systems deliberately run below capability (C4→A3 data engineering; C3→A2 energy copilot).

What it does well: the tables are usable, the informal labels (hands on / eyes on / mind on) travel in mixed rooms, and the cases are not toy demos. They actually exercise the claimed move—high technical reach, constrained authorization—for reasons that match the framework (irreversibility, downstream corruption risk, need for domain judgment). Integration with an existing NIST/EU-aligned RAI intake is practical rather than rhetorical. Circularity is low; they stipulate taxonomies and apply them.

Soft spots, in proportion. The load-bearing claim is that ACL is a stable, policy-independent technical property different reviewers can score consistently. The only evidence is author self-assessment, and the C3/C4 call turns on a fine architectural distinction (intent routing vs chaining toward a compound goal) that independent raters could easily disagree on—especially since the paper already admits blurred boundaries lower down. Table 2’s “Highest AAL” column reads like a hard ceiling while the prose allows a less capable system more freedom in a tight scope; that tension is minor but unresolved. No multi-rater study, no external site, no outcome metrics on whether the gates change incidents or approval time. Free parameters (five levels, risk thresholds) are organization-specific by design.

This is for people building or reviewing enterprise agent governance, not for theory or benchmarks. Serious enough for peer review: clear thinking, honest about scope, real deployments. I would engage, reuse the AAL/ACL language, and push for reliability checks if it lands in a venue. Not a foundational result; solid applied framework work.

Referee Report

3 major / 6 minor

Summary. The paper proposes a governance framework for agentic AI that separates two axes: Allowed Autonomy Levels (AAL A1–A5), the autonomy a system is authorized to exercise given risk, oversight, and accountability; and Autonomous Capability Levels (ACL C1–C5), its inherent technical abilities assessed from observable perception/reasoning/planning/tool-use/adaptation behaviors. A two-step decision process (Figure 1) first assesses ACL as an upper bound on feasible AAL, then selects AAL via an existing enterprise risk-assessment process, defaulting to A1. Tables 1–2 define the levels with human-role descriptors, accountability implications, and examples. Two deployed enterprise systems are presented as illustrations: a data-engineering multi-agent system rated C4 but deployed at A3, and an energy-operations copilot rated C3 but deployed at A2. The framework is positioned as an extension of the authors' NIST-aligned enterprise Responsible AI program.

Significance. If the framework holds up, the capability/permission separation is a genuinely useful conceptual contribution to a literature that mostly collapses the two (e.g., SAE-style ladders, human-in-the-loop taxonomies). The paper's strengths are practical rather than formal: it ships two detailed, real deployed-system assessments (Appendices A–B) that actually exercise the claimed separation in both directions of the delta (C4/A3 and C3/A2), the AAL progression is tied cleanly to an accountability narrative (errors-bounded → advice → actions → design errors → governance failures), and the decision process terminates at a well-defined floor (A1) with an explicit no-deploy condition. There are no fitted parameters or circular derivations; the taxonomy is stipulated and applied interpretively, which is normal for framework papers. The main limitation on significance is evidentiary: the entire empirical content is two self-assessments by the framework's own designers.

major comments (3)

[Design Principles / Figure 1 / Appendices A.2, B.2] §Design Principles ('Rigor') vs. Appendices A.2/B.2: the framework's consistency claim — that ACL criteria 'allow different reviewers, teams, and organizations to arrive at consistent conclusions' — is load-bearing, because ACL functions in Figure 1 (step 1) as the constraint on feasible AAL, i.e., as governance infrastructure. Yet the only two ACL assessments in the paper are by the authors themselves, and they turn on exactly the delicate C3/C4 boundary. A.1 describes the C4-rated system's supervisor as one that 'classifies user intent and delegates tasks to four specialized sub-agents,' while B.2 rates the copilot C3 in part because its supervisor 'follows an established workflow and performs intent-based routing.' The operative distinction (chaining gap-detection → diagnosis → remediation toward a compound goal vs. dispatching each query to a single specialist) is a fine architectura
[Example Applications (final paragraph)] The claim that the cases 'demonstrate the framework's effectiveness in managing risk' (§Example Applications) overstates what two self-assessed deployments can show. What the cases actually demonstrate is interpretability — that the AAL/ACL vocabulary can be applied coherently to real systems and that a capability–authorization gap is a deliberate, articulable governance choice. Nothing in the paper shows that the separation changed an outcome relative to the counterfactual (e.g., that without the framework these systems would have been deployed at A4/A3), nor that the AAL selections were correct. Please temper the effectiveness language or provide the counterfactual/governance-decision evidence (e.g., intake records showing the AAL assignment altered deployment controls).
[Table 2] Table 2, 'Highest AAL' column: as written, this column hard-codes a 1:1 mapping (C1→A1, ..., C5→A5), which is in tension with the paper's central thesis that capability 'constrains... but does not determine' authorization and that 'a less capable system may be granted greater freedom within a tightly constrained scope.' The column is presumably meant as 'AAL may not exceed the AAL corresponding to ACL,' but it reads as a lookup table that re-couples the axes. Please clarify whether the mapping is a strict feasibility ceiling, and if so, state the rule explicitly (AAL ≤ f(ACL)) and reconcile it with the 'less capable system granted greater freedom' sentence in §Autonomy Level Decision Framework.

minor comments (6)

[References] Reference verification: Wang et al. 2026, 'OpenClaw-RL: Train Any Agent Simply by Talking,' arXiv:2603.1016, could not be verified as a real arXiv identifier (the ID format is also malformed), and the AI Index 2026 citation is forward-dated. Please check all references for accuracy.
[Allowed Autonomy Level] §Allowed Autonomy Level, opening paragraph: 'AAL concerns the level of accountability that an organization is willing to assume' conflates the definiens — AAL is elsewhere defined as authorized autonomy of action, with accountability as a consequence. Consider rephrasing so the level is defined by authorized action scope, with the accountability implication kept in Table 1's final column.
[Allowed Autonomy Level, A3] A3 definition bundles three disjunctive conditions ('require human approval, must be reversible... or must be accompanied by mitigation mechanisms'). The or-structure makes A3 assignment under-determined; a sentence on which condition is primary would help reviewers apply it.
[Appendix, Figures A1–A2] Figures A1/A2 are referenced as architecture diagrams but are central to the C3/C4 boundary argument; please ensure the routing-vs-planning distinction is visible in the figures themselves, not only in the prose.
[References] Cohen et al. 2025 (Science) is cited in the reference list but does not appear to be cited in the body; either cite it in the related-work discussion or remove it.
[Autonomy Level Decision Framework] Typo: 'risk assessment questionaries' → 'questionnaires' (§Autonomy Level Decision Framework).

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: AAL/ACL are stipulated governance taxonomies applied interpretively, not predictions forced by fit or self-citation.

full rationale

This is a conceptual governance-framework paper, not a predictive or first-principles derivation. Allowed Autonomy Levels (A1–A5) and Autonomous Capability Levels (C1–C5) are author-stipulated taxonomies motivated by NIST/EU risk practice, SAE-style level analogies, and human-in-the-loop role taxonomies (Feng et al., Sheridan & Verplank). The decision flowchart (Figure 1) is a policy process—assess ACL as an upper bound, then choose AAL via existing risk questionnaires—not an equation that recovers its inputs. The two enterprise cases (data-engineering multi-agent at C4/A3; energy-operations copilot at C3/A2) are interpretive applications of those definitions to systems the authors built; labeling a system under one’s own rubric is normal framework exposition and does not reduce a claimed external prediction to a fitted parameter or a load-bearing self-citation. Table 2’s “Highest AAL” column is an explicit feasibility mapping by construction of the framework, not a disguised empirical forecast. References are predominantly external (NIST, EU AI Act, SAE, Russell & Norvig, Feng et al.); there is no uniqueness theorem, ansatz, or fitted scale imported from overlapping-author prior work that forces the central claim. Concerns about inter-rater reliability of the C3/C4 boundary are validity/consistency issues, not circularity. No step exhibits Eq. X = input by construction.

Assumptions & free parameters 3 free parameters · 5 assumptions · 3 invented entities

The central claim is definitional and procedural: governance should treat permission and capability as separate axes and assign AAL via risk after ACL assessment. Load-bearing inputs are design choices (five levels each), enterprise RAI/risk process inheritance, and the premise that composed-system behavior can be scored as an inherent ACL upper bound. No fitted physical constants; free parameters are discrete design knobs. Invented entities are the named level systems and the decision split itself.

free parameters (3)

Number of AAL levels (fixed at 5) = 5 (A1–A5)
Chosen for usability balance inside one enterprise; paper explicitly allows other organizations to pick different cardinalities.
Number of ACL levels (fixed at 5) = 5 (C1–C5)
Same hand-chosen granularity; boundaries between perception/reasoning and C3/C4/C5 are qualitative judgment calls.
Acceptable-risk threshold in RAI questionnaires
Final AAL gate is ‘Is the risk acceptable?’ via existing internal questionnaires not fully specified in the paper; threshold is organizational policy, not derived.

assumptions (5)

domain assumption Capability of a multi-agent system should be assessed at the composed-system level, not only per sub-agent.
Stated in ACL discussion and Appendix A; required for labeling the data platform C4.
domain assumption Higher AAL monotonically decreases direct human control and reversibility while shifting accountability toward upfront design and organizational delegation.
Table 1 progression and A3–A5 narrative; underpins why risk must rise with allowed autonomy.
domain assumption Existing enterprise Responsible AI intake/risk process (NIST AI RMF / EU AI Act aligned) is an adequate gate for the ‘risk acceptable?’ decision node.
Figure 1 and Basic Concepts section; framework does not redefine risk scoring, only plugs autonomy into it.
domain assumption An agent must not operate above the accountability the human organization will accept.
Opening of Allowed Autonomy Level section; normative governance premise, not empirically derived.
ad hoc to paper Five-level discrete ladders are stable enough for governance despite rapid model change if defined by observable authority/behavior rather than benchmarks.
Design principles (stability/usability) and discussion; justifies not tying levels to specific model releases.

invented entities (3)

Allowed Autonomy Levels (AAL A1–A5)
purpose: Name and stratify authorized operational autonomy and accountability transfer.
Core permission ladder; mnemonics hands-on through mind-off. Independent evidence is only internal case application, not external standard.
Autonomous Capability Levels (ACL C1–C5)
purpose: Name technical ability ladder independent of policy authorization.
Core capability ladder from tools/models to plant-manager-like agents. Boundaries are author-defined.
Two-step ACL-then-AAL decision framework (Figure 1)
purpose: Operationalize assignment so capability bounds but does not determine permission.
Procedural invention integrating risk questionnaires; validated only by narrative application to two systems.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels." pith.science (2026). https://pith.science/paper/75G3S6E7

@misc{pith2026260723438,
  author       = {Pith},
  title        = {Pith review of: Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/75G3S6E7}},
  note         = {Machine review of arXiv:2607.23438}
}

read the original abstract

As AI systems increasingly exhibit agentic behavior, discussions of autonomy often conflate what systems are technically capable of doing with what they should be permitted to do in practice. This paper introduces a governance framework that explicitly separates Allowed Autonomy Levels (AAL), which define the degree of autonomy an AI agent is authorized to exercise given risk, oversight, and accountability considerations, from Autonomous Capability Levels (ACL), which characterize an agent's inherent technical abilities. We present a structured set of autonomy levels spanning reactive execution, decision support, supervised action, goal-directed autonomy, and delegated operational authority, and describe how control, reversibility, and accountability change as autonomy increases. To operationalize this framework, we propose a risk-aware decision process for assigning allowed autonomy, analyze how risk and accountability evolve across autonomy levels, and demonstrate its application through a deployed enterprise data engineering agent, illustrating how a system assessed at a high capability level can be deliberately constrained to a lower allowed autonomy based on risk, reversibility, and organizational readiness. By distinguishing authorization from capability, this work provides practical guidance for the design, deployment, and governance of Agentic AI systems.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

10 extracted references · 2 canonical work pages

[1]

Depena1, Jonathan D

Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels Haining Zheng1, Qian Dong1, Rodolfo K. Depena1, Jonathan D. Bhatia1, Feng Xiao2, Peng Xu1 1ExxonMobil Technology and Engineering Company 2ExxonMobil Global Operations Company Abstract As AI systems increasingly exhibit agentic behavior, discus-sions of autonomy of...

2026
[5]

Stanford University Institute for Human-Centered AI

The 2026 AI Index Report. Stanford University Institute for Human-Centered AI. https://hai.stanford.edu/ai-index/2026-ai-index-report. Brustoloni, J. C

2026
[8]

arXiv:2506.12469

Levels of Auton-omy for AI Agents. arXiv:2506.12469. NIST

arXiv
[10]

find and fix data gaps

OpenClaw-RL: Train Any Agent Simply by Talking. arXiv:2603.1016. Appendix A. Data Engineering Multi-Agent System A.1 System Architecture The system is designed to detect and remediate data quality gaps within a large-scale enterprise data platform. It em-ploys a supervisor-routed multi-agent architecture: a central orchestrator receives user requests and ...

arXiv
[1991]

and (Russell and Norvig 2020). Agentic AI refers to an application in which one or more AI agents are composed and orchestrated to perform complex tasks or workflows through the coordi-nation of data, tools, and other systems, operating at varying levels of autonomy within defined constraints and oversight mechanisms. Such systems may consist of multiple ...

2020
[2021]

https://doi.org/10.4271/J3016_202104/

SAE Levels of Driving Automation. https://doi.org/10.4271/J3016_202104/. Sheridan T.B.; Verplank W.L

work page doi:10.4271/j3016_202104/
[2023]

It has been deployed for two years with an established intake process, risk question-naires, trained AI risk advisors, and a governance dashboard used to track AI projects

and complies with regulations such as the EU AI Act (EU 2024). It has been deployed for two years with an established intake process, risk question-naires, trained AI risk advisors, and a governance dashboard used to track AI projects. While the system has been work-ing well for traditional machine learning approaches and large foundation models based Gen...

2024
[2024]

Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence (Artificial Intelligence Act). (2024). Official Journal of the European Union, L 2024/1689, July

2024

Show all 10 references

[2025]

Science 384(6691):36–38

Regulating Advanced Artificial Agents. Science 384(6691):36–38. https://www.science.org/doi/10.1126/sci-ence.adl0625. EU

doi
[2026]

tools verify, humans decide

or sim-ilar Agentic AI systems to approach C5. Regardless, agents at this level are associated with high risk and potentially se-vere real-world consequences. In our experience, five capability levels provide sufficient granularity to distinguish meaningful differences in agen...

1978

Pith tools

Reviewed July 30, 2026 · model on record in the stance chip above.

[1] [1]

Depena1, Jonathan D

Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels Haining Zheng1, Qian Dong1, Rodolfo K. Depena1, Jonathan D. Bhatia1, Feng Xiao2, Peng Xu1 1ExxonMobil Technology and Engineering Company 2ExxonMobil Global Operations Company Abstract As AI systems increasingly exhibit agentic behavior, discus-sions of autonomy of...

2026

[2] [5]

Stanford University Institute for Human-Centered AI

The 2026 AI Index Report. Stanford University Institute for Human-Centered AI. https://hai.stanford.edu/ai-index/2026-ai-index-report. Brustoloni, J. C

2026

[3] [8]

arXiv:2506.12469

Levels of Auton-omy for AI Agents. arXiv:2506.12469. NIST

arXiv

[4] [10]

find and fix data gaps

OpenClaw-RL: Train Any Agent Simply by Talking. arXiv:2603.1016. Appendix A. Data Engineering Multi-Agent System A.1 System Architecture The system is designed to detect and remediate data quality gaps within a large-scale enterprise data platform. It em-ploys a supervisor-routed multi-agent architecture: a central orchestrator receives user requests and ...

arXiv

[5] [1991]

and (Russell and Norvig 2020). Agentic AI refers to an application in which one or more AI agents are composed and orchestrated to perform complex tasks or workflows through the coordi-nation of data, tools, and other systems, operating at varying levels of autonomy within defined constraints and oversight mechanisms. Such systems may consist of multiple ...

2020

[6] [2021]

https://doi.org/10.4271/J3016_202104/

SAE Levels of Driving Automation. https://doi.org/10.4271/J3016_202104/. Sheridan T.B.; Verplank W.L

work page doi:10.4271/j3016_202104/

[7] [2023]

It has been deployed for two years with an established intake process, risk question-naires, trained AI risk advisors, and a governance dashboard used to track AI projects

and complies with regulations such as the EU AI Act (EU 2024). It has been deployed for two years with an established intake process, risk question-naires, trained AI risk advisors, and a governance dashboard used to track AI projects. While the system has been work-ing well for traditional machine learning approaches and large foundation models based Gen...

2024

[8] [2024]

Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence (Artificial Intelligence Act). (2024). Official Journal of the European Union, L 2024/1689, July

2024