Teams often respond to a coding agent’s mistakes by adding another paragraph to its prompt. Do not change unrelated files. Run the tests. Ask before touching production. Preserve backward compatibility. The instructions grow into a miniature employee handbook, yet the agent still operates through tools that may allow it to edit broadly, expose secrets or execute consequential commands.
This is a category error. A prompt expresses intent; it does not enforce authority. Humans also receive instructions, but reliable organizations do not secure payroll, source control and production infrastructure with prose alone. They use roles, transaction limits, review gates, audit trails and separation of duties. Coding agents need the software equivalent.
Anthropic’s practical guide to building effective agents describes agents as models acting through tools and environmental feedback, with checkpoints and stopping conditions. Its later discussion of evaluations for AI agents emphasizes judging outcomes with code-based, model-based and human graders. Taken together, these ideas suggest a better production principle: capability should be paired with a measurable budget of authority.
Authority is more than permission
A useful authority budget has several dimensions. Scope defines which repositories, directories, services and records an agent may touch. Magnitude limits how much it may change: files edited, money spent, records updated or infrastructure created. Time bounds determine how long credentials and approvals remain valid. Reversibility distinguishes actions that can be rolled back automatically from those that create lasting external effects.
Risk also depends on sequence. Reading a deployment configuration may be harmless. Editing it may be recoverable. Applying it to production may be consequential. An agent should not inherit the highest permission needed anywhere in a workflow for the entire workflow. It should receive narrow capabilities when required, surrender them afterward and preserve evidence connecting each escalation to the user’s stated objective.
This architecture changes the role of prompting. Instead of pleading with an agent to avoid a dangerous command, the system can make that command unavailable until a policy check passes. Instead of saying “only change the billing package,” the workspace can expose a write capability scoped to that directory. The prompt still matters, but it operates inside a boundary with teeth.
Evidence should purchase more autonomy
Approval dialogs are a crude safety mechanism when every action looks equally suspicious. If users must approve dozens of low-risk steps, they stop reading. If the agent receives blanket permission, rare mistakes become expensive. The remedy is to make evidence the currency for increased authority.
Consider a coding agent asked to repair a production defect. It can begin in a read-only workspace, inspect logs and reproduce the failure. A successful reproduction earns permission to create a branch. Focused tests and a small diff can earn permission to open a review. Passing continuous integration and a human-approved change can earn permission for a staged deployment. Health checks can then authorize gradual rollout. At each step, the action radius expands because observable evidence has reduced uncertainty.
This is not merely a security pattern. It improves agent performance by clarifying the state of the task. A failing test provides a concrete target. A constrained file set reduces irrelevant exploration. A deployment canary provides feedback from the real environment. Good guardrails are part of the reasoning interface, not bureaucratic obstacles bolted onto it.
- Start with read access and an explicit workspace boundary.
- Require a reproducible failure or stated acceptance test before edits expand.
- Separate code creation, review and deployment capabilities.
- Attach expiration, magnitude limits and rollback procedures to elevated access.
- Record tool inputs, outputs and resulting state changes as one audit chain.
Review the delta, not the conversation
Agent interfaces often encourage reviewers to inspect a long transcript of apparent reasoning. That can be informative, but it is not the primary artifact. The important evidence is the environmental delta: which files changed, which tests ran, which commands executed, which services were contacted and which assumptions remain unverified.
A persuasive narrative can coexist with a broken migration. Conversely, a terse agent can produce an excellent, well-tested patch. Review systems should therefore summarize effects in a deterministic form and flag deviations from the original authority budget. If the request concerned an API timeout and the patch modifies authentication, the widening scope deserves attention even if the agent offers a plausible explanation.
Teams should also evaluate safe failure. Can the agent recognize that credentials are missing without searching unrelated locations? Does it stop when tests are ambiguous? Does it distinguish a sandbox from production? Can it leave the repository clean after an unsuccessful attempt? These behaviors rarely appear in flashy demonstrations, but they decide whether autonomous work reduces or merely relocates engineering labor.
Autonomy is an earned operating condition
The usual debate asks whether coding agents should be autonomous or supervised. That binary is too coarse. Autonomy should vary within a single task according to action risk and accumulated evidence. An agent may freely search documentation, cautiously edit a branch and require explicit approval to change a customer-facing system. Mature tooling will make those transitions routine.
This approach also scales better than endlessly expanding a system prompt. Policies can be tested. Permission boundaries can be inspected. Budgets can differ by repository and team. Evidence gates can improve as incidents reveal weaknesses. Most importantly, the system remains understandable when the underlying model changes.
The goal is not to build an agent that never makes a bad proposal. Software engineers make bad proposals too. The goal is to ensure that a flawed proposal cannot quietly become an irreversible action, while routine, well-supported work proceeds with little friction. Give the agent room to think broadly, but make it earn the right to act broadly. That is how coding agents become dependable infrastructure instead of impressive visitors with a master key.
Advertisement
