Telling an AI Agent “No” Is Not a Control
Consider a familiar situation. Parents tell their teenager:
“Do not take the family car without permission.”
The instruction establishes a rule and communicates the limits of the teenager’s authority. However, if the vehicle is outside and the key fob remains on the kitchen counter, the teenager still possesses the practical capability to take the car.
The instruction defines what is permitted. Access to the fob determines what is possible.
Locking away the fob changes the situation. The parents have moved from telling the teenager what not to do to controlling access to the capability required to do it.
Instructions and Controls Are Not the Same
Could the teenager still bypass the control by hot-wiring the car, finding another key, or obtaining assistance? Possibly. No individual control eliminates every conceivable path.
However, securing the fob removes the easiest and most probable means of unauthorized use. An immobilizer, locked garage, alarm, location tracker, and parental notification provide additional layers of protection.
This is defense in depth. Each control makes an unauthorized action more difficult, more detectable, or easier to stop.
The same distinction applies to AI agents.
An organization might instruct an agent not to:
Access restricted information
Transfer funds
Modify production systems
Deploy software
Contact outside parties
Make binding commitments
Share sensitive information
Create or delegate work to another agent
Those instructions may communicate organizational expectations, but they do not prevent the actions if the agent retains the credentials, permissions, tools, connections, and execution pathways needed to perform them.
The Authority-Control Gap
Approved authority describes what the agent is permitted to do.
Effective authority describes what the agent can actually do within its operational environment.
When effective authority exceeds approved authority, an authority-control gap exists.
This gap may arise from excessive permissions, shared credentials, poorly constrained tools, unrestricted network access, delegated authority, inadequate approval gates, or capabilities created through interactions among multiple agents and systems.
The agent might remain within its written instructions during testing but exceed them when conditions change. It might also discover an unintended sequence of individually permitted actions that produces a prohibited result.
For this reason, evaluating authority requires more than reviewing prompts and policies. Engineers must examine the complete sociotechnical system: people, agents, software, credentials, tools, networks, data, approval processes, monitoring, and organizational incentives.
Engineering from Loss to Authority
A Loss-to-Authority Engineering Process begins by identifying unacceptable losses. Examples might include an unauthorized financial transaction, disclosure of protected information, interruption of an operational system, creation of a binding obligation, or an action that threatens human safety.
The engineering process can then:
Identify agent actions or conditions that could contribute to each loss.
Determine the authority necessary for the assigned mission.
Define the difference between required, approved, and effective authority.
Establish constraints governing actions, resources, conditions, approvals, and effects.
Record those constraints in an Authority Constraint Specification.
Implement an authority control structure that enforces the constraints.
Verify that prohibited actions are prevented or contained.
Monitor for authority drift throughout the system lifecycle.
The Authority Constraint Specification should define more than a list of prohibited commands. It should address accessible resources, credential scope, transaction limits, operating conditions, approval requirements, delegation, monitoring, stop mechanisms, containment, and recovery.
Control Capability, Not Merely Behavior
An agent that does not attempt a prohibited action during testing has demonstrated behavior under the tested conditions. It has not necessarily demonstrated that the action is impossible.
A stronger approach limits the capability itself. Credentials can be withheld until needed. Permissions can be restricted. Transactions can require independent approval. Network destinations can be limited. Spending, duration, frequency, and scope can be bounded. Monitoring systems can detect deviations and suspend execution.
These controls should operate independently of the agent whenever practical. An agent should not be solely responsible for deciding whether its own proposed action exceeds its authority.
The Systems-Engineering Principle
Prompts, policies, and instructions remain important. They communicate mission, expectations, and approved authority. But they should not be mistaken for enforced constraints.
The central principle is:
Safety-critical constraints must be enforced at the point of capability, not merely expressed at the point of instruction.
If an AI agent can take the car, telling it not to take the car is not enough.
