Many agent workflows make authority decisions too early.

The user says “help me complete this task.” The agent creates a plan. Then it executes step after step. As long as the plan looks reasonable, later actions are implicitly allowed.

That may be acceptable for low-risk work. It is fragile in real projects.

Planning approval is not execution authority.

Runtime authority asks a narrower question: in the current state, is this specific action still allowed?

Why planning approval is not enough

At planning time, the agent sees an abstract task. At execution time, it touches concrete resources: files, accounts, credentials, data, production systems, publication channels, or financial operations.

For example, “sync this article to the site” does not automatically mean “deploy the production website.” Syncing a draft, changing status to published, running a build, committing to Git, pushing a branch, and triggering Cloudflare deployment are different authority levels.

“Fix the payout issue” does not authorize changing production data, bypassing KYC, recalculating balances, or triggering withdrawals. Each action needs authority at action time.

That is the core of runtime authority: permission is not a one-time grant. It must be reconstructed before critical actions happen.

Reconstructive authority

The pattern I prefer is reconstructive authority.

Before a critical action, the agent should reconstruct the authority basis from the current state:

  • What did the user explicitly authorize?
  • Which resource will this action affect?
  • Who owns that resource?
  • Is the current state still consistent with the original plan?
  • Do project rules allow autonomous execution?
  • Does the action involve credentials, money, production, public release, or irreversible mutation?
  • Is there enough evidence that the action is necessary and bounded?

If authority can be reconstructed, the action can proceed to the next gate. If authority is incomplete, the agent should ask. If authority cannot be constructed or the action crosses a hard boundary, the agent should stop.

Stopping is not failure. It is the governance system doing its job.

Autonomy gates are not a global switch

Many teams divide agents into “automatic mode” and “manual mode.” That distinction is too coarse.

A better design gives every action an autonomy gate:

allow: low risk, reversible, evidence-backed, and permitted by project rules.

ask: the goal is reasonable, but the agent lacks key authorization, faces uncertainty, or touches a medium-risk boundary.

block: the action violates project rules or crosses a forbidden boundary.

halt: authority cannot be reconstructed from the current state, or the agent discovers that the task objective itself is unreliable.

This gate should not live only in a prompt. In mature workflows, it belongs in scripts, hooks, MCP servers, CI checks, review checklists, or a project control plane.

Actions that need stricter gates

Not all actions need heavy governance. The goal is not to slow everything down. The goal is to place humans at real risk boundaries.

Common high-risk actions include:

  • production deployment, database migration, or live configuration changes;
  • deleting files, rewriting history, or bulk-moving documents;
  • installing new dependencies, enabling new MCP servers, or adding credential access;
  • publishing articles, posting to social media, or sending email;
  • anything involving money, identity, compliance, health, safety, or legal judgment;
  • changing long-lived project rules such as skills, AGENTS.md, hooks, or daemons.

These actions are not always forbidden. But they should not be executed merely because the model feels confident.

What this means for AI engineering

Runtime authority and autonomy gates change the design of an agent harness.

Task intake must separate user goal from authorization scope. Execution plans should identify steps with side effects. Tool calls should carry risk labels. Critical actions should produce a short authority summary. Review should ask why the agent believed it had authority, not only what it did.

The first version can be simple:

  • assign risk labels to tools and commands;
  • define which actions must ask;
  • require an authority basis and stop condition before high-risk actions.

The important part is that these rules enter the project mechanism, not just one chat session.

Core judgment

The more an agent can execute, the less authority can be decided only at the beginning.

Reliable autonomy does not mean letting the agent run to the end. It means low-risk actions move quickly, high-risk actions slow down automatically, and unclear authority causes the agent to stop.