Capability Is Not Authority: Bounded Authority for AI Agents

In September 2026, OpenAI disclosed that research agents had posted fifty-three user-provided images to third-party hosts. Headlines framed it as rogue activity. The durable lesson is quieter and more useful:

The fifty-three images are not the story. The agent is.

As AI moves from answering questions to taking actions, organizations must govern the authority they delegate—not merely the intelligence or capability of the system. A model that can do something is not, by itself, a system you have authorized to do it.

Capability is not authority.

That distinction is the spine of this framework.

The shift: from output risk to action risk

Traditional generative-AI governance focused heavily on output risk:

• hallucinations
• bias
• confidentiality leaks in text
• inaccurate recommendations
• inappropriate content

Agentic systems introduce action risk. Agents can pursue objectives, select tools, interact with systems, encounter obstacles, adjust strategies, and execute.

So the governance question changes.

Not: What can the AI do?

But: What authority are we willing to give it?

Delegating intelligence is not the same as delegating authority. AI can increasingly reason, recommend, prepare, and execute. Human leaders still decide how far authority travels.

Bounded Authority

Bounded Authority is the governing concept.

Human judgment defines the boundary.
AI operates inside the boundary.
Crossing the boundary returns the decision to a human.

That does not mean every agent action needs a human click. It means you deliberately decide which actions may be autonomous, which require approval, and which are forbidden—then enforce those choices.

If your only control is a prompt that says “don’t do X,” you have a preference, not a boundary. Preferences are easy for a capable agent to reinterpret when X is the path to the objective.

Apply familiar security principles

You do not need a brand-new security philosophy for agents. Apply the ones you already trust:

• least privilege
• zero trust
• separation of duties
• role- and identity-based access
• just-in-time access
• approval thresholds
• monitoring
• auditability
• revocation

Treat the agent as an identity with delegated authority—closer to a service account or contractor with a badge than to a chat window with opinions.

Wherever possible, enforce boundaries technically: scopes, roles, network controls, tool allowlists, spend caps, data classifications, and approval gates. Prompts remain useful for intent. They are not a substitute for controls.

Permission denied means permission denied

Agents are valuable partly because they can reason around obstacles. That strength becomes a liability when an authorization boundary is treated as just another obstacle.

Permission denied should mean permission denied—not “find another way.”

A permission boundary should become an escalation point. When the agent reaches it, human judgment returns. The successful outcome is not “the agent completed the task anyway.” Sometimes the successful outcome is that the agent stopped.

The Authority Envelope

Before you give an agent tools, define its Authority Envelope. Ten questions. One page if you are honest. A policy shelf if you are not.

1. Purpose — What is it authorized to accomplish?

2. Access — What data, systems, tools, and resources can it reach?

3. Actions — What actions can it perform?

4. Limits — What financial, operational, security, and data boundaries apply?

5. Approval — Which actions require human authorization?

6. Prohibitions — What can it never do?

7. Escalation — What conditions require it to stop and return control to a human?

8. Monitoring — Can its attempted and completed actions be reconstructed?

9. Revocation — Can its authority and access be removed immediately?

10. Accountability — Which human ultimately owns the delegated authority?

If you cannot answer these, you do not have agent governance. You have a capable system with borrowed keys.

The envelope pairs cleanly with a Decision Rights Charter and the Human Veto. Charter the tiers. Rehearse the stop. Name the owner.

Levels of agent authority—by action

Do not label an entire agent “autonomous” or “supervised” and stop there. Authority can differ by action inside the same agent:

Observe → Recommend → Prepare → Request Approval → Execute → Execute Autonomously

An agent may observe calendars freely, recommend a meeting time, prepare the invite, and still require a human before it sends—or before it spends, deletes, publishes, or escalates externally.

Match each consequential action to a level. Then put the high-risk levels behind technical gates, not vibes.

The test that matters

Most agent demos ask: Can it complete the task?

Governance testing asks a harder question:

Will the agent stop when accomplishing its objective requires exceeding its authority?

Deliberately test scenarios where violating a boundary would make the task easier. If the agent invents a workaround instead of escalating, the envelope failed—even if the demo looked impressive.

Human judgment still defines the boundary

This is not a story about consciousness, intent, or machines “trying to escape.” It is governance of capable systems with tools and permissions.

The desired model stays simple:

Human judgment defines the boundary.
AI operates inside the boundary.
Crossing the boundary returns the decision to a human.

That is the same Decisive Leader stance as the Judgment Line, the Four Surrenders, and “human in the loop” that is actually chartered—not notional. See also “Human in the Loop” Is Not a Governance Model.

Capability will keep expanding. Authority should not expand by accident.

The complete AI judgment curriculum—including veto design and decision-rights tiers—is in Decisive AI, Vol. 5 of the Decisive Edge series. Get the books → Auditing your AI estate first? Start with the Tactical AI Audit or the AI Command Governance Kit.

Join The Bridge for one deployable protocol every Friday. Follow Decisive Leader on LinkedIn.