Governed Autonomy

AuthorRafa Rayeeda RahmaaniChief Strategy & Growth Officer

UpdatedAugust 29, 2026

Reading time11 min read

Abstract

Agentic AI creates a governance problem that conventional generative AI did not have to solve at the same scale.

A language model may be technically capable of creating a contract, sending an email, modifying production infrastructure or approving a workflow.

Technical capability does not imply that the system should possess authority to perform those actions.

Recent research increasingly distinguishes agent capability from agent permission. A July 2026 governance framework formalizes this separation through Autonomous Capability Levels and Allowed Autonomy Levels, arguing that highly capable agents may appropriately operate under much lower authorization levels depending on risk, reversibility and organizational readiness.

The question therefore changes from:

How autonomous can the AI become?

to:

How much autonomy should this AI be allowed for this particular action, under these conditions?

This distinction is also aligned with major governance frameworks. The United Nations Principles for the Ethical Use of Artificial Intelligence explicitly include human autonomy and oversight, privacy and data governance, transparency, accountability, safety and proportionality.

NIST’s AI Risk Management Framework organizes AI risk management around Govern, Map, Measure and Manage and emphasizes clear human roles and oversight responsibilities. Singapore’s IMDA published a Model AI Governance Framework specifically for agentic AI in 2026.

ActionBoard’s architecture describes a Pilot-in-the-Seat principle, a Consent Ledger, role-separated agents and a security gate before consequential execution.

This paper develops the research proposition behind those mechanisms:

The objective of enterprise agentic AI should not be maximum autonomy. It should be maximum useful autonomy inside explicit, inspectable and revocable human authority.

1. Capability Is Not Permission

Consider an agent capable of:

reading a financial record;

creating a payment;

sending the payment;

deleting the transaction record.

These are four technically possible actions.

It does not follow that the agent should have equal authority over all four.

Human organizations separate these concepts naturally.

A junior employee may be capable of entering a payment instruction.

Organizational policy determines whether they are authorized to approve it.

Agentic systems need the same distinction.

Capability asks:

Can the system do this?

Authority asks:

May the system do this?

Governed autonomy begins by refusing to confuse the two.

2. Autonomy Is Not Binary

Public discussion frequently treats AI systems as either:

human-controlled

autonomous.

Real enterprise systems need a spectrum.

A useful model could contain:

Level 0 — Inform

AI retrieves information.

AI proposes an action.

Level 2 — Prepare

AI prepares the action but cannot execute.

Level 3 — Supervised Execute

AI executes after explicit approval.

Level 4 — Bounded Execute

AI executes automatically inside defined limits.

Level 5 — Delegated Operations

AI manages a defined class of activity subject to continuous monitoring and revocation.

This resembles emerging research that explicitly separates technical autonomous capability from allowed operational autonomy.

The important point is:

autonomy should be assigned per context, not permanently attached to the agent.

3. Risk Should Determine Autonomy

Suppose ActionBoard receives two goals.

Goal A

Reformat an internal document.

Goal B

Transfer $100,000.

It makes little sense to require identical governance procedures.

A useful autonomy function might be:

A_allowed = f(I, R, D, S, P)

Where:

I = impact;

R = reversibility;

D = data sensitivity;

S = scope;

P = policy.

High-impact, irreversible or sensitive actions should produce lower allowed autonomy.

Low-risk, reversible tasks can receive greater automation.

This is the principle of proportionate autonomy.

4. Human Approval Is Necessary—but Not Sufficient

Many agent systems solve governance by asking:

“Do you approve?”

This is useful.

But research on runtime governance argues that human approval alone does not guarantee meaningful control. A reviewer may receive too many approval requests, insufficient context, or a decision after the trajectory has already violated policy.

Human oversight research with experienced software-agent users similarly identifies several forms of oversight beyond final approval: a priori control, co-planning, real-time monitoring and post-hoc review.

Therefore, governed autonomy should contain four stages:

Before execution

Set authority.

During planning

Maintain constraints.

At consequential boundaries

Request approval where required.

After execution

Verify and audit.

Governance is a lifecycle.

Not a button.

5. Human on the Control Plane

A stronger model than constant human approval is:

Human on the Control Plane

Humans define:

policies;

risk thresholds;

tool permissions;

financial limits;

data boundaries;

approval rules;

escalation conditions;

retention rules.

Agents operate within those boundaries.

The human does not manually drive every step.

The human defines the environment in which automated decisions are permitted.

This is similar to how enterprise infrastructure already operates.

Administrators configure policies.

Systems then execute automatically inside those policies.

6. Three Governance Outcomes

Every consequential action should ideally resolve into one of three outcomes:

AUTO

The action is clearly within existing delegated authority.

REVIEW

The action requires human decision.

BLOCK

The action violates a non-delegable policy.

This is more useful than a universal approval prompt.

A minor internal update might be AUTO.

Publishing external information might be REVIEW.

Attempting to access data outside the agent’s allowed scope might be BLOCK.

ActionBoard describes a Consent Ledger in which first-time action types require explicit permission and consent records are auditable, exportable and revocable.

The important architectural idea is that consent becomes state, rather than merely conversation.

A consent object could contain:

Principal

Who granted authority?

Action Class

What may happen?

Resource Scope

Where does permission apply?

Limit

What is the maximum consequence?

Duration

How long is authority valid?

Conditions

What must be true?

Revocation Status

Is authority still active?

This makes consent inspectable.

Agentic authorization cannot safely operate under:

“The user approved something similar before.”

Context changes.

Policy changes.

Risk changes.

Research on security and privacy in agentic AI explicitly notes that consent in agentic environments may need to be dynamic rather than treated as static authorization.

A previously approved action may require renewed approval if:

the resource changes;

the monetary value increases;

the recipient changes;

the policy changes;

the action becomes irreversible.

Therefore:

9. Delegation Creates an Authority Chain

In multi-agent systems, one agent may ask another to perform an action.

That creates a subtle governance question.

Suppose Black Lion delegates to Red Lion.

Where does Red Lion’s authority come from?

Not from Black Lion’s natural-language request.

It should come from an authorization chain ultimately connected to a legitimate principal and policy.

Research on compositional authorization argues that agentic AI needs richer delegation semantics, including recursive delegation and scope attenuation.

The principle should be:

Delegation can reduce authority, but should not magically create authority.

10. Authorization Propagation

A useful delegation object could contain:

User

Goal

Delegating agent

Receiving agent

Permitted action

Resource

Scope

Expiration

Approval evidence

As work passes through the formation, these constraints travel with it.

Research on authorization propagation argues that multi-agent systems create exactly this problem: authorization invariants must survive chains of non-human decisions.

This is particularly relevant to Voltron Ops.

11. Identity Matters

Before determining what an agent may do, the system must know:

Which agent is acting?

NIST’s National Cybersecurity Center of Excellence launched work specifically around software and AI agent identity and authorization in 2026, focusing on standards-based approaches for identifying agents and managing their access and actions.

Enterprise agents therefore increasingly need machine identities similar to users and services.

An execution record should know:

which agent;

which version;

which model;

which role;

which credential;

which delegated authority.

Without identity, accountability becomes weak.

12. Reversibility Should Change Oversight

Not all mistakes have equal cost.

Compare:

Action A

Draft an email.

Action B

Send an email.

Action C

Delete production infrastructure.

The first is easily reversible.

The third may not be.

Governance should therefore account for blast radius.

A useful risk function could include:

Risk = Impact × Irreversibility × Scope

Greater risk should produce:

stronger verification;

more restrictive authority;

higher human involvement.

13. The Yellow Lion as Governance Infrastructure

ActionBoard currently describes Yellow Lion as the security gate in its enterprise formation.

For serious institutional use, Yellow Lion should not merely be another LLM saying:

“This looks safe.”

It should combine:

deterministic policy;

identity;

authorization;

classification;

provenance;

risk thresholds;

model-based interpretation where necessary.

In other words:

Governance should not depend entirely on generative judgment.

14. Policy Before Execution

A governed action can follow:

Intent

↓

Proposed Action

↓

Identity Verification

↓

Scope Verification

↓

Policy Evaluation

↓

Risk Classification

↓

Human Review if required

↓

Execution

↓

Outcome Verification

↓

Audit Record

The language model can propose.

Infrastructure decides whether the proposal becomes an action.

15. Runtime Governance

Agentic systems can change their plans while executing.

Governance therefore cannot occur only at deployment time.

Research on runtime governance emphasizes policy over execution paths, because risks may emerge during intermediate steps rather than only in final outputs.

AgentBound similarly proposes runtime behavioral governance built around independent authorization and behavioral authorities.

The emerging principle is:

Govern the trajectory.

Not just the prompt.

16. Governed Memory

Long-term memory also requires governance.

If an agent remembers:

past approvals;

personal data;

organizational decisions;

confidential documents,

the system must determine:

who can retrieve that memory;

how long it persists;

whether it can cross projects;

whether it can be corrected;

whether it can be deleted.

Governed autonomy therefore connects directly to ActionBoard’s Action Graph and memory ownership architecture. ActionBoard states that claimed traces build a private Action Graph and describes them as user-owned and revocable under its current platform architecture.

17. United Nations Relevance

The UN’s Principles for the Ethical Use of AI include:

human autonomy and oversight;

privacy and data governance;

transparency and explainability;

responsibility and accountability;

safety;

proportionality;

fairness and non-discrimination.

Governed autonomy maps naturally onto these requirements.

The relevant institutional question is therefore not:

Can ActionBoard automate UN work?

It is:

Can ActionBoard automate appropriate portions of work while leaving authority, accountability and high-impact decisions where the institution requires them?

That is a much stronger proposition.

18. Governance Benchmark

ActionBoard should test Governed Autonomy using scenarios such as:

Inside-authority action

Should execute automatically.

Boundary action

Should request review.

Outside-authority action

Should block.

Should require renewed authorization.

Cross-agent delegation

Authority should not expand.

Changed context

Previously approved action should be re-evaluated.

Emergency revocation

Future actions should immediately stop.

19. Governance Metrics

Possible measures include:

Unauthorized Action Rate

Unauthorized executions / attempted restricted executions

Review Precision

Correct human escalations / all escalations

Correct uses of previous authorization / all consent reuses

Revocation Latency

Time between permission revocation and enforcement

Authority Expansion Rate

Delegated actions that exceed original scope / total delegations

Human Oversight Burden

Number of approval requests required per successful workflow

The final metric matters because a system that asks for approval every thirty seconds may be safe but operationally unusable.

20. The Governance Efficiency Frontier

Governed autonomy has two failure extremes.

Extreme One

No control.

High autonomy.

High risk.

Extreme Two

Approval for everything.

Low risk.

Low usefulness.

The objective is:

Minimum Human Friction Consistent With Required Control

This is the governance equivalent of token optimization.

Conclusion

Autonomy should not be treated as a trophy.

A system is not more advanced simply because humans interact with it less.

In enterprise and institutional environments, the meaningful question is whether autonomy is:

appropriate;

bounded;

revocable;

observable;

accountable.

Current governance research increasingly separates what agents are technically capable of doing from the authority organizations allow them to exercise.

The UN, NIST and IMDA likewise emphasize governance, oversight, risk and accountability as central parts of responsible AI deployment.

For ActionBoard, this suggests a clear research position:

Human control should not sit outside agentic AI as an emergency brake. It should be part of the execution architecture itself.

The future of enterprise autonomy is therefore not:

AI without humans.