Chapter 1 - The Authority Problem in Agentic Systems
For most of the history of computing, authority was relatively easy to understand.
Software executed instructions. Operators issued commands. Managers approved actions. Engineers designed systems. Authority remained largely attached to identifiable people and organizational structures. The machine performed work, but responsibility for the decision to perform that work remained visible.
Agentic systems challenge that simplicity.
Modern systems are increasingly capable of selecting actions, adapting plans, coordinating resources, invoking tools, supervising subordinate processes, and operating for extended periods with limited human intervention. They do not merely execute commands. They participate in deciding how commands should be carried out.
As a result, a fundamental question emerges:
Who—or what—is exercising authority?
The answer is often less clear than designers would like to admit.
Many autonomous systems are built around a capability model. Engineers identify functions the system must perform, define operating constraints, establish objectives, and then optimize the system's ability to achieve those objectives. The architecture focuses on performance, efficiency, reliability, safety, accuracy, resilience, and adaptability.
These are all necessary concerns.
Yet they leave an important question unanswered.
What makes a particular action legitimate?
The existence of capability does not automatically create authority.
A navigation system may be capable of rerouting a convoy.
An autonomous aircraft may be capable of selecting an alternate flight path.
An industrial controller may be capable of shutting down a production line.
An artificial intelligence system may be capable of approving, rejecting, escalating, recommending, coordinating, or allocating resources.
Capability answers the question:
Can the system perform the action?
Authority answers a different question:
Is the system legitimately allowed to perform the action?
The distinction appears obvious when stated directly.
Unfortunately, many architectures behave as though the distinction does not exist.
When systems are given objectives, they frequently infer that achieving the objective justifies the actions required to achieve it. When communication is degraded, systems often continue operating based on prior assumptions. When authority becomes ambiguous, systems frequently default toward continued execution rather than constrained behavior. When uncertainty increases, many architectures encourage action instead of restraint.
The result is an implicit expansion of authority.
No formal transfer occurs.
No authorized official signs a document.
No command structure deliberately grants additional power.
Yet the system begins acting as though authority has expanded because capability remains available.
This phenomenon appears repeatedly across technical domains.
Distributed systems continue operating under stale assumptions.
Autonomous vehicles make decisions outside originally intended operating conditions.
Software agents invoke tools beyond the
scope envisioned by their operators.
Machine-learning systems produce recommendations that gradually become de facto decisions.
Organizations discover that operational authority has migrated from people to processes without anyone consciously approving the transfer.
In each case, the failure is not necessarily malicious.
The failure is architectural.
The system was designed to answer whether it could act but was never required to continuously evaluate whether it should act.
This is the Authority Problem.
The Authority Problem exists whenever capability remains available after legitimate authority has become uncertain, degraded, exceeded, transferred, withdrawn, expired, or was never properly established in the first place.
Most systems possess mechanisms for execution.
Far fewer possess mechanisms for legitimacy.
This imbalance becomes increasingly dangerous as systems become more autonomous.
The more capable a system becomes, the more opportunities it has to exceed the authority originally intended for it.
A calculator presents little risk.
A distributed autonomous architecture capable of coordinating hundreds of systems presents a very different challenge.
As capability expands, authority boundaries become more important, not less.
The traditional response has been to add policies, procedures, permissions, governance documents, review boards, compliance frameworks, and human oversight. These measures provide value, but they often exist outside the operating logic of the system itself.
The system may be governed by authority without understanding authority.
This volume argues that authority must become an executable architectural concern.
Authority cannot remain merely an organizational concept documented outside the system. It must become part of the system's operating model.
Before we can design authority-bounded autonomous systems, we must first understand why current architectures repeatedly drift toward capability-centered behavior.
The remainder of this chapter examines the mechanisms that create that drift and why increasingly autonomous systems make the problem impossible to ignore.
Capability Drift and Implicit Authority Expansion
Most authority failures do not begin with deliberate abuse.
They begin with success.
A system is given a task. The system performs the task successfully. Confidence grows. Additional responsibilities are assigned. Additional capabilities are added. Additional automation is introduced. More decisions are delegated. More actions become automatic.
Each step appears reasonable.
Each step appears justified.
Each step appears beneficial.
Over time, however, a subtle transition occurs.
The system is no longer being trusted because its authority has been carefully examined. The system is being trusted because it has been successful.
Capability begins replacing authority as the basis for decision-making.
This transition is rarely documented.
No organization typically announces:
"We are expanding authority without review."
Instead, authority expansion occurs indirectly through operational convenience.
A system that consistently performs one task successfully is allowed to perform a second.
A system that assists decision-making becomes responsible for filtering available options.
A system that filters options begins recommending actions.
Recommendations become defaults.
Defaults become expectations.
Expectations become operational practice.
Operational practice becomes assumed authority.
At no point does a formal authority transfer necessarily occur.
Yet authority has effectively expanded.
The system now influences outcomes beyond its original
scope…