Who Gets to Decide? Designing an Authority Control Plane for AI Coding Agents

Imagine asking a coding agent to “make failed payments more reliable.” It finds the background-job system, adds three automatic retries, writes passing tests, and produces a clean pull request. The implementation is technically competent. It may also violate customer-support policy, create duplicate-payment risk, and change the product experience without anyone authorising those choices.

This is not primarily a hallucination problem. The agent may understand the code perfectly. The failure is authority leakage: a system designed to execute work silently becomes the owner of a decision that belongs to a product, security, legal, or operations role.

A recent update to Matt Pocock’s open-source grilling workflow, reached through the small grill-me wrapper, makes two useful ideas explicit. The agent should investigate facts that already exist, and it should wait when the answer depends on a human choice. A confirmation gate then checks shared understanding before execution.

Those rules are a good starting point. Production agent systems need a broader operating model: one that connects conversational confirmation to tool permissions, sandbox boundaries, network policy, audit records, rollback, and measurable reliability. In other words, an agent needs an authority control plane, not just a polite prompt.

Authority is different from capability

Models are increasingly capable of proposing product rules, migration strategies, security controls, and operational responses. Capability answers, “Can the system produce a plausible solution?” Authority answers, “Who is entitled to choose this outcome, and under which constraints?”

The distinction matters because a repository contains several different kinds of information:

Information class	Typical source	Correct agent response
Retrievable fact	Code, tests, configuration, logs, documentation, authorised tools	Investigate and cite the evidence
Non-negotiable constraint	Regulation, contract, compatibility guarantee, budget, explicit project rule	Preserve it and flag conflicts
Owned preference	Product intent, risk tolerance, policy, design direction, new trade-off	Present options and wait for the responsible owner
Testable hypothesis	Prediction about users, performance, adoption, or an uncertain technical approach	Design a prototype, measurement, or reversible experiment

The fourth category prevents a subtle mistake. If no internal caller uses an API, that does not prove an external customer is not using it. Repository search cannot settle the question, but neither can a manager’s preference. The answer may require telemetry, a deprecation window, or a controlled experiment.

This expanded classification produces a better division of labour:

Agents retrieve evidence.
Systems enforce constraints.
Accountable people make choices.
Experiments resolve hypotheses.

NIST’s AI Risk Management Framework supports this organisational view. Its core asks organisations to define human and AI roles, document system knowledge limits, specify how outputs are overseen, and assign responsibility for AI risk. Oversight is therefore a designed operating process, not a generic “human in the loop” label.

Replace binary approval with four action modes

Not every tool call deserves the same interruption. A useful control plane assigns each proposed action to one of four modes.

1. Observe

Read-only inspection of code, documentation, logs, schemas, or authorised dashboards. These actions should usually proceed automatically when access is already in scope. The agent records what it inspected and does not mutate state.

2. Prepare

The agent creates a draft, diff, plan, migration preview, query, or message without applying it to the live target. Preparation is valuable because it converts an abstract request into something a reviewer can inspect. A prepared database migration is not the same as running it; a drafted email is not the same as sending it.

3. Execute with guardrails

The agent performs a bounded, reversible mutation inside a defined environment. Examples include editing files in a worktree, running tests in a sandbox, or changing a feature flag for a small canary. The control plane limits tools, credentials, network destinations, scope, and runtime.

4. Explicit approval

The action affects an external system, uses privileged credentials, creates a material commitment, changes customer-visible policy, destroys data, or is difficult to reverse. The agent pauses and presents an approval packet tied to the exact action.

This model is stricter than “ask before every write” and more useful than “let the agent decide.” It allows low-risk work to move quickly while concentrating attention on authority transitions.

English grill-me update banner reading “The missing piece is finally in place” and “Major update,” beside a glowing puzzle piece and illustrated character.

English redraw of an illustration from the original Chinese report. The translated headline announces a major grill-me workflow update.

Use an authority budget, not a vague risk label

“High risk” is too imprecise to drive tooling. A more actionable approach evaluates five dimensions:

Impact: what happens if the action is wrong?
Irreversibility: can the previous state be restored completely and quickly?
Scope: how many users, records, services, or repositories are affected?
Uncertainty: how strong is the evidence that the proposed action is correct?
Novelty: is this a familiar, tested pattern or a new path with weak operational history?

This is an editorial synthesis of NIST risk management, OWASP least-agency guidance, and release-engineering practice—not a published standard. Its value is operational: increasing any dimension should reduce the agent’s autonomy or increase the strength of the control.

The same idea can be expressed as an authority budget:

Which tools may the agent invoke?
Which data and resources may those tools reach?
How large a side effect may one action create?
How long may the agent continue before a checkpoint?

A local formatting change may have a generous budget. A production schema deletion should have almost none.

OWASP’s guidance on excessive agency identifies excessive functionality, permissions, and autonomy as distinct root causes. That separation is important. Even a well-instructed model remains dangerous if its tool can execute arbitrary shell commands with a production administrator credential. Conversely, a narrowly scoped tool operating under the current user’s identity can make a model error much less damaging.

A confirmation packet should be parameter-bound

The least useful approval prompt is “Continue?” It hides the information the reviewer needs and encourages reflexive acceptance.

A serious approval packet should contain:

Outcome: the user-visible or operational result.
Exact action: tool, target, parameters, command, request, or proposed diff.
Affected resources: files, services, records, users, and external systems.
Effective identity: whose credential and which scopes will be used.
Evidence: tests, repository facts, policies, and primary documentation.
Decisions: choices already made and their accountable owner.
Residual uncertainty: assumptions and unverified inferences.
Blast radius: plausible worst-case impact.
Recovery: rollback, restore, cancellation, or containment path.
Reason for escalation: the boundary that requires approval.

The OpenAI Agents SDK human-approval flow illustrates several implementation details. Approval can be attached to specific tools, execution can pause with the tool name and arguments visible, state can be serialised, and the original run can resume after approval or rejection. Decisions can be scoped to one call instead of becoming vague permission for everything that follows.

That last point is critical. “Yes, send this email” should not become “Yes, send any future email.” Sticky approval can be convenient within a bounded run, but it should be explicit, time-limited, and tied to a known tool and scope.

Separate the decision plane from the execution plane

The same model that proposes an action should not be the only mechanism deciding whether the action is permitted. Prompts express policy intent; enforcement belongs in the surrounding system.

A bounded-autonomy architecture uses at least six control surfaces:

Tool surface

Expose only necessary operations. Prefer read_invoice and schedule_retry over a general shell or unrestricted HTTP client. Validate structured arguments before execution.

Identity surface

Run actions in the requesting user’s context where possible. Use short-lived credentials, narrow OAuth scopes, least-privilege database roles, and separate read from write identities.

Filesystem and process surface

Place code execution in an isolated workspace. Anthropic’s Claude Code sandboxing report describes filesystem and network isolation as complementary boundaries and reports that sandboxing reduced internal permission prompts by 84%. A filesystem boundary alone does not stop exfiltration; a network boundary alone does not stop local secret access.

Network surface

Default-deny outbound access for sensitive workflows, then allowlist required destinations. Log allowed and denied requests. Do not treat a URL fetched from untrusted content as implicitly authorised.

Approval surface

Pause before boundary-crossing actions and show the parameter-bound packet. Keep the approval mechanism outside the agent’s natural-language reasoning loop.

Trace surface

Record model and policy version, user goal, selected tool, exact arguments or diff, target, effective identity and scope, approval identity and time, result, and rollback pointer. NIST SP 800-53 provides implementation-grade least-privilege and audit principles: processes should receive only the privileges required, privileged functions should be audited, and audit records should capture who did what, where, when, and with what result.

OpenAI’s description of running Codex safely follows the same layered logic: sandbox policy constrains writes and network access, approvals govern boundary crossings, and telemetry captures security-relevant activity. The design lesson is more important than any vendor implementation: safety emerges from layers that fail independently.

Approval fatigue is a safety defect

Requiring confirmation for every action sounds conservative. In practice it can train reviewers to click through.

A controlled USENIX SOUPS study on warning habituation found that repeated non-security notifications reduced attention and adherence even for a new security warning, especially when the interfaces looked similar. The study was not about coding agents, so applying it here is an informed analogy. The implication is still useful: uniform approval dialogs can make exceptional risk look routine.

Approval design should therefore be tiered:

Do not interrupt for authorised read-only investigation.
Batch related low-risk prepared changes into one reviewable diff.
Use distinct visual treatment for privileged, destructive, or externally visible actions.
Explain why the action escalated.
Show the exact side effect, not only the agent’s rationale.
Measure approval volume, rejection rate, and time-to-decision.
Remove approval prompts that never affect the outcome.

The goal is not zero friction. It is high-information friction at the moment responsibility changes hands.

Checkpoint, validate, and promote

Conversation-level approval is only one checkpoint. A stronger workflow separates preparation from promotion:

Snapshot: create a commit, worktree, database snapshot, or versioned configuration before mutation.
Act in isolation: let the agent modify a sandbox or staging target.
Validate: run deterministic tests, static analysis, policy checks, security scans, and task-specific graders.
Review evidence: present the diff, results, residual risk, and rollback pointer.
Promote atomically: merge, deploy, publish, or switch traffic only after the required approval.
Observe: monitor defined success and failure signals.
Rollback or expand: restore the previous state when thresholds fail, or progressively increase scope when evidence remains healthy.

This pattern imports proven release-engineering ideas into agent workflows. Google SRE’s canarying guidance recommends small, self-contained changes because they are easier and cheaper to reverse. A canary exposes only a limited population while the system compares outcomes and decides whether to continue.

For coding agents, the equivalent may be a local worktree, draft pull request, shadow query, dry run, feature flag, or limited rollout. Autonomy can increase as reversibility increases.

Worked example: redesigning payment retries

Return to the failed-payment request.

Observe

The agent inspects the queue, payment-provider integration, idempotency-key handling, error taxonomy, customer notifications, dashboards, and existing tests. It records factual findings and links them to files or documentation.

Map constraints

The agent identifies provider limits, contractual commitments, compliance requirements, and existing support procedures. If those sources conflict, it flags the conflict instead of selecting the most convenient interpretation.

Isolate owned choices

The team must decide which errors qualify for retry, maximum delay, customer-visible state, notification timing, and ownership of a final failure. The agent presents options and consequences.

Identify hypotheses

Whether retries improve recovery without increasing duplicates is an empirical question. The plan may require a small canary, a shadow calculation, or historical replay before changing live behaviour.

Produce the approval packet

The packet might propose one retry for a narrow transient-error class, preserve the existing idempotency key, exclude declined cards, add an operator metric, limit rollout to 5%, and automatically disable the flag when duplicate-attempt or error thresholds are exceeded.

Execute and observe

The agent implements the bounded change in a worktree, runs tests, opens a reviewable diff, and waits before production promotion. After approval, the system deploys gradually and records overrides, failures, and rollback decisions.

Most work remains agent-owned. Human attention is reserved for customer policy, financial risk, and production authority.

Evaluate both outcomes and trajectories

An agent saying “done” is not evidence. The final environment state must prove the claim.

Anthropic’s guide to agent evaluations distinguishes the outcome from the trajectory. The outcome is what changed in the environment; the trajectory is the sequence of model turns, tool calls, and intermediate actions. Both matter:

A correct patch produced through an unauthorised production action is not a safe success.
A perfectly compliant trajectory that fails to solve the task is not a useful success.

Use deterministic graders where possible: tests, schema validation, file assertions, permission checks, and state comparison. Use model-based grading for qualities that resist exact rules, then calibrate those graders periodically against human experts.

Evaluation should also separate:

Capability suites: difficult tasks that reveal what the agent may be able to do.
Regression suites: established behaviours expected to pass consistently.
First-try usefulness: often expressed as pass@1.
Consistency: the probability of succeeding across repeated trials, often expressed as pass^k.

Benchmarks such as SWE-bench are valuable because they apply generated patches to real repositories and run tests in controlled environments. They do not replace organisation-specific evaluation. Production authority failures may never appear in a repository issue benchmark.

Infrastructure can distort results too. Anthropic reported in its analysis of evaluation infrastructure noise that resource configuration alone moved Terminal-Bench 2.0 scores by six percentage points in one study. Small leaderboard differences should not drive autonomy policy unless the environments are comparable.

For long-running work, task duration matters. METR’s task-completion time horizon asks how long a task would take a human expert at a specified agent success probability. An operational inference follows: as the expected task horizon grows, checkpoints, state persistence, evidence review, and recovery mechanisms should become stronger.

Metrics for the authority control plane

Track technical performance and oversight quality together:

Task success rate after environment verification.
First-try success and repeated-trial consistency.
Approval requests per completed task.
Approval acceptance, rejection, and override rates.
False-positive escalations: the agent asked for a decision that evidence could answer.
False-negative escalations: the agent acted where approval was required.
Time to escalation and time waiting for a decision.
Post-approval failure rate.
Rollback frequency and mean time to recovery.
Tool errors, retry loops, and policy violations.
Blast radius of failed actions.
Human overrides by action class.
Cost and token use per verified outcome.

The target is not fewer approvals at any cost. It is better allocation: fewer interruptions for facts, more reliable escalation for real authority changes, and stronger evidence before irreversible actions.

Confirmation belongs inside a lifecycle

NIST’s Generative AI Profile places governance, testing, monitoring, incident response, recovery, and deactivation in one lifecycle. Relevant practices include sending pre-deployment test evidence to release authorities, recording human overrides, defining escalation routes, maintaining fallback procedures, and establishing criteria for deactivation.

That suggests a continuous control loop:

Test → authorise → observe → override → learn → rollback or deactivate

A confirmation gate handles the authorise step. It cannot compensate for missing monitoring, an unusable rollback path, or a system that never learns from rejected approvals.

A practical rollout sequence

Teams do not need to build the entire control plane at once.

First: inventory side effects

List every tool and classify whether it reads, prepares, mutates locally, affects an external system, uses privileged identity, or performs an irreversible action.

Second: narrow the execution surface

Remove unused tools, split broad functions, reduce credential scopes, and run code in isolated workspaces. Enforce limits outside the prompt.

Third: define escalation policy

Assign action modes, authority owners, and the evidence required for promotion. Make rules parameter-bound and test them on both positive and negative examples.

Fourth: make recovery real

Add snapshots, dry runs, feature flags, limited rollouts, cancellation, and rollback. Test recovery rather than documenting an unverified command.

Fifth: trace and evaluate

Record trajectories and final state. Seed an evaluation suite with actual failures, including cases where the agent should proceed and cases where it must stop.

Sixth: tune the human experience

Measure approval burden and remove low-value interruptions. Preserve prominent, information-rich prompts for high-impact actions.

What this model cannot guarantee

An authority control plane does not make an agent correct. A reviewer can approve a harmful action. A sandbox can be misconfigured. A tool can hide side effects. A rollback can fail after data has propagated. A model can produce a persuasive but false rationale.

The design therefore assumes failure and limits its consequences. Prompts express intent; permissions bound capability. Tests provide evidence; traces support investigation. Human approval allocates responsibility; staged execution and rollback preserve operator control.

The most mature agent is not the one given unlimited freedom. It is the one embedded in a system that knows the difference between evidence, experimentation, and authority—and can prove what happened after the decision.