Why companies must now govern their agents’ authority, not just their autonomy
Imagine a company that allows a sales agent to consult the CRM, identify at-risk customers, propose a discount, and send emails. Each permission seems reasonable.
Then the agent gains the ability to modify certain business terms in the ERP. At what point did the company decide that this agent could modify the economic conditions of a customer relationship?
Perhaps never.
Yet, technically, it has just given it that capability. That’s precisely the problem. An organization can delegate to an agent the power to act without having explicitly decided to entrust it with the corresponding authority. This authority can emerge gradually from the accumulation of access rights, tools, and technical permissions.
An agent’s authority should be an explicit decision by the organization, not the implicit consequence of its technical architecture.
After learning to govern models, data, and use cases, companies must now govern something more sensitive: the power to act on their behalf.
Capability, permission, autonomy, and authority are not synonymous
Four notions must be distinguished.
- Capability describes what an agent technically knows how to accomplish.
- Permission corresponds to what IT systems concretely allow it to do.
- Autonomy measures the extent to which it can accomplish these actions without requiring human intervention.
- Authority, finally, designates the power that the organization decides to grant it to make a decision or act on its behalf.
These dimensions are related, but they are not equivalent.
An agent may be technically capable of making a payment. An API may allow it to trigger it. It may even be autonomous enough to execute the operation without human assistance. That does not mean the organization has decided to delegate to it the right to commit that expense.
This distinction is beginning to appear in recent scientific work. In July 2026, Haining Zheng and his co-authors proposed differentiating Autonomous Capability Levels, which describe an agent’s technical capabilities, and Allowed Autonomy Levels, which determine the level of autonomy actually authorized given the risk, supervision, and ability to account. A system can therefore be highly capable while remaining deliberately limited in what it is authorized to accomplish.
This research does not define organizational authority exactly as I understand it here. Nevertheless, it establishes an essential principle:
Capability ≠ permission ≠ autonomy ≠ authority.
What a system can do does not determine what it should be authorized to do.
This distinction is obvious when it comes to humans. A CFO may have the skills necessary to carry out a multi-million euro operation without having the power to authorize it alone. A sales manager may know how to negotiate a contract without having the corresponding signing authority. An employee may access information without having the right to modify it. Organizations constantly separate competence, access, and decision-making power. The arrival of AI agents now requires extending this logic to artificial systems.
When does automation become a delegation of power?
Let’s take an agent in charge of the purchasing process. It can identify suppliers, request quotes, compare proposals, recommend an offer, negotiate certain terms, create an order, commit an expense, and then possibly trigger a payment. From an IT perspective, this sequence looks like an automated process. From a governance perspective, it tells a different story: at each stage, the nature of the power entrusted to the agent evolves.
Analyzing an offer is not equivalent to choosing a supplier. Choosing a supplier is not equivalent to committing an expense. Preparing a payment is not equivalent to executing it. This is also highlighted by Nenad Tomašev, Matija Franklin, and Simon Osindero in their work published in February 2026 on Intelligent AI Delegation. Their framework envisions delegation not only as a transfer of tasks, but also as a transfer of authority, responsibility, and accountability, within defined boundaries.
The managerial question then changes in nature. It is no longer simply:
What task can we automate?
It becomes:
What portion of the power necessary for its execution are we prepared to delegate?
Six levels for thinking about delegation
Autonomy should therefore not be thought of as a simple switch between human intervention and automation.
I propose here, as a managerial framework, six levels of authority delegation. They constitute neither a technical standard nor a regulatory classification.
Level 0: observe
The agent accesses information and analyzes it without recommending or acting.
Example: detecting abnormal variations in supplier expenses.
Level 1: recommend
The agent formulates a proposal without preparing or triggering an operational action.
Example: recommending the supplier offering the best compromise between price, quality, and delivery time.
Level 2: prepare
The agent prepares an action that remains subject to approval by an authorized person.
Example: generating a purchase order or preparing a draft contract.
Level 3: execute under conditions
The agent can act without ad hoc approval when a set of predefined rules is met.
Example: automatically placing an order below a defined threshold with a referenced supplier.
Level 4: decide and execute
The agent selects an option and carries out the corresponding action within its assigned scope, without prior human approval.
Level 5: delegate and orchestrate
The agent can distribute certain sub-objectives among other agents or orchestrate multiple systems, but only within the limits of the authority granted to it. This last condition is essential. An agent should not be able to create, through sub-delegation, authority greater than what the organization has granted it.
The objective is therefore not to reach the highest level. It is to determine the relevant level of authority for each process, each risk, and each value creation objective.
Authority is not a level, it’s an envelope
A scale is not enough, however. An agent’s authority is multidimensional. An agent can be highly autonomous while remaining heavily limited in its scope. A purchasing agent could, for example, be authorized to place certain orders without human validation, but only up to 500 euros, with referenced suppliers, in a given geographic scope, without contractual modification, without access to certain data categories, without sub-delegation, and with an obligation to escalate as soon as an anomaly is detected.
Simply saying it is “level 4” would therefore be insufficient. That’s why I propose a complementary notion: the authority envelope. It defines the scope within which an agent can exercise the autonomy granted to it.
This envelope should specify in particular authorized decisions, accessible data, usable tools, financial amounts, geographic scopes, irreversible operations, human validation conditions, sub-delegation possibilities, escalation rules, and suspension mechanisms.
The scale thus answers a first question:
What degree of autonomy do we grant?
The envelope answers a second:
Within what scope can this autonomy actually be exercised?
It is probably this second question that will become the most important.
This tension is already appearing in the field
During my interview with Anthony Levy, founder of Damn, this tension appeared very concretely. He emphasized the need to define what an agent can do, what it cannot do, and the scope within which it can act. His approach particularly emphasizes the agent’s identity, permissions, access rights, and traceability of its actions.
This field feedback reveals a question that goes beyond cybersecurity alone: when multiple permissions together allow an agent to act, has the company actually decided to entrust it with the corresponding power?
When permissions create authority that no one decided
Agentic architectures add a particular difficulty: actual authority can emerge from the combination of permissions.
Microsoft has emphasized since 2026 the application of the principle of least privilege to agents. Each should have its own identity, limited permissions, and traceable activity.
But several individually reasonable permissions can, when combined, produce much greater power to act.
Let’s return to the sales example. An agent may have access to the CRM, email, commercial documents, and certain ERP functions. Taken separately, each of these accesses seems legitimate. Together, they can allow the system to identify a vulnerable customer, analyze their history, determine a new pricing proposal, modify certain business terms, and then communicate directly with them.
The problem no longer lies in an isolated permission. It lies in what their combination makes possible.
An agent’s effective authority can become greater than what each of its permissions taken separately suggests.
I propose to call this phenomenon accidental authority: a power to act that has not been explicitly delegated by the organization, but that emerges from the combination of technical permissions granted to the agent. The company can thus de facto give power to the machine without ever having explicitly made the corresponding managerial decision.
The governance question is therefore no longer just:
What does this agent have access to?
It becomes:
What can it actually accomplish through the combination of all its access rights?
Governing the trajectory, not just the action
This question becomes even more important when agents perform long-duration tasks.
Classical control mechanisms often reason action by action: an operation is authorized or prohibited, a transaction exceeding a threshold requires validation, a sensitive modification triggers an alert.
But a succession of individually acceptable actions can collectively produce a result that is not.
OpenAI provided an example of this in July 2026 with models capable of executing tasks over longer horizons. Some failures had not been identified by prior evaluations. The company notably added trajectory-level monitoring to examine the system’s overall behavior rather than a succession of isolated actions.
The principle goes beyond this particular case: controlling actions does not necessarily equate to governing the trajectory.
The organization must therefore focus on what the agent can do at each stage, but also on what it becomes capable of accomplishing when these actions are chained around the same objective.
The issue becomes one of decision rights
AI governance has largely been built around data, risks, bias, compliance, transparency, cybersecurity, or intellectual property.
These dimensions remain essential.
But agents introduce a different question: who can act on behalf of the company?
An organization is precisely based on an architecture of decision rights. It defines who can recruit, commit an expense, modify a price, grant a discount, sign a contract, or access certain information. These rules prevent competence and institutional power from being confused.
AI agents are now entering this architecture. In its State of AI in the Enterprise 2026, Deloitte, based on a survey of 3,235 executives in 24 countries, highlights strong expected growth in agentic AI while 21% of organizations report having mature mechanisms to govern autonomous agents.
We can therefore find ourselves in a paradoxical situation: agents become operationally more powerful while the decision rights that correspond to them remain poorly defined.
Should we formalize a delegation of authority for AI agents?
The comparison with delegation of power must be handled with caution. It is not about considering an agent as a legal person or legally assimilating a delegation granted to an artificial system to one entrusted to a natural person. On the other hand, the organizational logic of delegation is particularly useful.
Companies already use scopes of authority, financial thresholds, RACI matrices, dual validations, separation of duties, and signing authorities.
A comparable discipline can be applied to agents. This logic can be translated into a governance tool: an AI Delegation of Authority Matrix.
Its objective is not simply to document an agent’s technical permissions. It is to make explicit the power that the organization agrees to delegate to it.
| Dimension | Governance question |
| Agent and mission | What system is acting and to achieve what objective? |
| Data | What information can it consult, cross-reference, or modify? |
| Tools | What systems, applications, and APIs can it use? |
| Delegation level | Does it observe, recommend, prepare, execute, decide, or orchestrate? |
| Authorized decisions | What can it decide without human intervention? |
| Thresholds | What financial, contractual, regulatory, or operational limits apply? |
| Irreversibility | What actions require mandatory confirmation? |
| Escalation | Under what circumstances must it interrupt its action? |
| Sub-delegation | Can it entrust certain operations to other agents? |
| Suspension | Who can immediately regain control? |
| Responsibility | What function bears responsibility for the delegation and its consequences? |
This matrix would not simply be an additional compliance tool.
It would force the organization to make visible a decision that otherwise risks remaining buried in the IT architecture:
What power are we actually prepared to delegate to this machine?
It also implies that each agent be identifiable and that its actions can be attributed. The National Cybersecurity Center of Excellence at NIST is precisely exploring in 2026 these questions of identity, authorization of software and AI agents, and traceability of actions.
Without clear identity, without traceability, and without explicit scope of authority, the chain of responsibility becomes difficult to reconstruct.
Being “in the loop” is not enough
The same level of precision must apply to human control. A human can intervene before each action, only above a certain threshold, when a decision becomes irreversible, when the agent goes outside its authority envelope, or after execution. These situations do not correspond to the same level of delegation.
Work published by Anthropic in February 2026 shows that observed autonomy depends not only on the model’s capabilities, but also on the latitude that users grant it and how they organize their supervision. Autonomy is therefore not only a technical property. It also results from an organizational choice.
The important question is no longer just whether a human remains in the loop, but at what point their authority must become superior to that of the agent again.
Five questions that executive committees should ask
The governance of authority can ultimately be reduced to five decisions.
- What capability do we actually want to use?
Not all available capabilities necessarily create value. - What authority do we want to delegate?
What decisions or actions can be executed without prior approval? - What authority envelope do we define?
What systems, data, amounts, decisions, territories, and actions fall within the scope? - How do we regain control?
Who can suspend the agent, interrupt a trajectory, or immediately reassign the decision? - Who is accountable for this delegation?
What function bears responsibility for the scope granted to the agent and its consequences?
An autonomous system should never create an organizational vacuum of responsibility.
Between capability and value, the organization must decide on authority
This reflection extends a conviction that structures my reading of artificial intelligence in business:
Artificial intelligence creates capability. Organizations create value.
The rise of agents now makes it possible to clarify what happens between these two terms:
CAPABILITY → AUTHORITY ENVELOPE → AUTONOMOUS ACTION → RESPONSIBILITY → VALUE
Capability defines what AI can do. The authority envelope determines what the organization allows it to do on its behalf. Autonomous action materializes this delegation. Responsibility makes it possible to attribute its consequences. Value ultimately justifies why this autonomy was granted.
Relevant governance therefore consists neither in systematically reducing autonomy nor in maximizing it because technology allows it. It consists in determining the right level of authority, in the right scope, for the right use.
Governing access to the power to act
For a long time, governing an information system consisted notably in deciding who could access what. With AI agents, this question is no longer sufficient. It is now necessary to determine who can act on what, how far, under what conditions, and on whose behalf.
This is a more profound change than a new generation of automation. When an organization gives an artificial intelligence the ability to observe, decide, and then act, it no longer simply entrusts it with a task. It delegates to it part of its power to act.
This delegation should never be accidental. It must become an explicit act of governance.
