A robot arm is working beside a person on an open factory floor.
Before every movement, a dialog asks the operator to approve the next five centimeters. The operator reads the first few requests carefully. Then the motions become repetitive. Approve. Approve. Approve. By the hundredth prompt, the operator is clicking from rhythm rather than judgment.
There is no physical cage around the arm. No torque limit. No protected zone. No emergency stop. If a control signal goes wrong, the robot can still reach the person standing beside it.
The approval log is immaculate. The system is not controlled.
Software agents are drifting toward the same mistake. We put a person in front of a stream of tool calls and describe the resulting friction as safety. The agent asks to run a command, open a file, call a host, or update a record. A human presses Allow. The interface records consent to the next step, but the architecture may still leave credentials exposed, side effects unbounded, execution opaque, cancellation unreliable, and recovery improvised.
Permission can communicate intent. It cannot carry the full burden of control.
Real control comes from determining what an agent is capable of reaching, which authority it receives, how its behavior becomes visible, whether execution can be interrupted, and how consequential effects can be reversed. Human approval belongs where those conditions change, not in front of every ordinary movement inside them.
The prompt is carrying more risk than the person can see
An approval dialog compresses a system into a sentence.
Allow npm test?
That looks like a question about a command. It is also a question about everything the command can cause. Which package scripts will run? Which subprocesses can they spawn? Which files can they read? Can they reach the network? Are cloud credentials present in the environment? Can a dependency send data elsewhere? Does approval cover only this process, or the tree it creates?
The person is not merely evaluating text. They are being asked to predict execution through a stack of tools, dependencies, credentials, and environmental state. Repeating the question does not improve their model of that stack.
This is why approval density is a poor proxy for control strength. A system can interrupt the user constantly while preserving an enormous blast radius behind every click. Another system can ask rarely because the agent is confined to an environment where most ordinary actions have limited consequences.
Anthropic's May 2026 containment analysis gives the tradeoff unusually concrete numbers. Its telemetry showed users approving roughly 93 percent of permission prompts. Anthropic also reported that an operating-system sandbox reduced prompts by 84 percent while limiting filesystem writes to the workspace and denying network access by default. Those figures describe Anthropic's products, not a universal law, but the mechanism generalizes: repeated approval consumes attention, while a hard environmental boundary continues enforcing policy after attention fades.
The improvement was not simply fewer dialogs. The agent gained more freedom inside a smaller space.
Four controls that should not share one name
In ordinary conversation, permission and authorization are often interchangeable. In an agent system, the distinction matters. Here I use permission to mean an interactive human approval, not filesystem permission bits or an access-control entry.
| Control | Question it answers | What it can establish | What it does not establish |
|---|---|---|---|
| Permission | Does this person agree to the proposed action now? | Intent, consent, or acknowledgment at a moment | Whether the action is actually bounded, observable, or recoverable |
| Authorization | May this authenticated actor perform this action on this resource under these conditions? | Enforced authority and delegation policy | Whether authorized behavior will remain sensible or low impact |
| Supervision | Can someone understand the execution and intervene while it is happening? | Visibility, redirection, escalation, and interruption | A hard ceiling on what happens before intervention succeeds |
| Containment | What remains unreachable or impossible even if the user, model, or input is wrong? | A deterministic limit on reach and blast radius | Whether an allowed action is desirable or ethically acceptable |
These controls overlap in implementation, but they are not substitutes.
Authorization without containment can give an agent a valid token that reaches too much. Containment without authorization can isolate a process while still letting the wrong actor use it. Supervision without interruption produces a live view of damage. Permission without enough context turns a person into a confirmation endpoint.
Control is the composition: a known actor receives bounded authority inside a constrained environment, its behavior is visible, it can be stopped, and its material effects have a recovery path.
Human behavior is already moving away from per-action approval
The strongest argument against constant approval is not that people are careless. It is that sustained work changes the form of attention that is useful.
In Anthropic's February 2026 study of millions of human-agent interactions, experienced Claude Code users enabled full auto-approval more often than new users, but also interrupted the agent more frequently. The longest sessions were becoming longer, and step-by-step approval became less practical as task complexity increased. Anthropic's conclusion was careful: effective oversight requires more than placing a human in every approval chain. Users need trustworthy visibility and simple ways to intervene.
That pattern resembles other skilled supervision. A pilot does not approve every adjustment made by an autopilot. A database operator does not confirm every disk write. A security engineer does not manually authorize each packet. They define operating limits, observe signals at the correct level, and intervene when the system departs from expected behavior or approaches a consequential boundary.
Agents still need to ask questions. A request for missing intent is different from a request to approve another predictable mechanical step. Anthropic found that its agent initiated clarification more often as tasks became complex. That is useful because ambiguity belongs with the person who can resolve it. It does not follow that the same person should evaluate every syscall, file write, or package script produced after the intent is clear.
The right human role is not permanent command parser. It is authority holder, context provider, and exception handler.
Compare two agents doing the same work
Consider a coding agent asked to patch a vulnerable dependency, run the relevant tests, and prepare a pull request.
In the permission-heavy design, the agent runs on a developer's laptop. The home directory contains SSH keys, cloud credentials, browser state, and unrelated repositories. A long-lived GitHub token is available to the process. The agent asks before shell commands and network calls. The developer approves package installation, test execution, repository writes, and a push because each request looks consistent with the assignment.
Every approval may be reasonable. The control model is still fragile. A poisoned package script could read material outside the repository. An indirect prompt injection in an issue or README could redirect the agent. A mistaken command could alter an unrelated checkout. A valid token could permit pushes far beyond the task. The human would have to infer these paths quickly from individual prompts.
Now place the same work in a contained design.
The agent starts in an ephemeral environment with a clean repository checkout. Only that workspace is writable. The developer's home directory and credentials never enter it. Network traffic can reach the package registry and a repository proxy, not the open internet. A short-lived workload credential permits a push only to a task branch and cannot merge, change repository settings, read other private repositories, or deploy. Process, time, network, and spend limits exist outside the model. The operator can see the active objective, changes, commands, test results, blocked requests, and remaining authority in one execution trace. Canceling the task revokes its credential, terminates descendants, and preserves the diff for inspection.
The contained agent may issue fewer prompts and still be under stronger control. If the model misunderstands the task, if a package is malicious, or if the operator clicks too quickly, the environment continues to enforce the same ceiling.
This is not a claim that the contained design is invulnerable. The package registry, repository proxy, sandbox runtime, kernel, orchestration service, and logging path all remain part of the attack surface. An egress allowlist can permit exfiltration through an approved domain. Isolation can also make host security tooling less able to inspect activity inside a guest. Anthropic reports encountering both problems in its own containment work.
The point is narrower and more useful: the architecture converts an open-ended judgment problem into a bounded engineering problem that can be attacked, tested, and improved.
Identity answers who. Containment answers how far.
An agent acting on behalf of a person should not simply inherit that person's ambient credentials. The agent is a separate actor with a narrower purpose, shorter lifetime, and different failure modes.
The February 2026 draft NIST National Cybersecurity Center of Excellence concept paper on agent identity and authorization frames the emerging problem around identification, authentication, authorization, delegated authority, logging, non-repudiation, and mitigation after prompt injection. It explores applying existing mechanisms such as OAuth, OpenID Connect, SPIFFE and SPIRE, policy-based access control, and zero trust guidance rather than inventing an entirely separate identity universe for agents.
That is the mature move. Give the runtime a verifiable workload identity. Bind its authority to the delegating person and the current task. Exchange broad credentials for narrower, short-lived ones. Keep the policy decision and enforcement point outside the model. Revoke the authority when the task ends or its context changes.
NIST's May 2026 analysis of responses on AI agent security reports broad agreement that foundational security principles still apply, with adaptation for agent-specific threats. That finding supports carrying forward controls such as workload isolation, least privilege, credential lifecycle, logging, and defense in depth.
Those authorization controls are necessary, but they do not answer every control question. A properly authorized agent can still make a disastrous authorized change, such as using an allowed database write in the wrong sequence or consuming an allowed budget through an accidental loop. Containment adds a second statement: even within its valid identity and authority, this workload cannot cross these environmental and operational limits.
Observe behavior at the level where intervention is possible
Containment limits worst-case reach. It does not tell an operator whether the agent is making useful progress inside that limit.
For supervision, a raw command log is simultaneously too much and not enough. It is too much because a person cannot reconstruct intent from a high-volume stream indefinitely. It is not enough because commands omit the relationship between the objective, the current plan, retrieved context, authority used, state changed, and uncertainty encountered.
An operational view should make drift visible before the final artifact arrives. The operator needs to know what outcome the agent is pursuing, which consequential effects have occurred, what it is waiting on, what boundary it tried to cross, what budget remains, and whether its children are still active. Evidence after the incident supports audit. Evidence during execution supports control.
This is a real systems problem, not a request to produce more dashboards. NIST AI 800-4 describes post-deployment monitoring across functionality, operations, human factors, security, compliance, and large-scale impacts. It also identifies fragmented logging and the difficulty of scaling human monitoring as active barriers. An agent trace that cannot connect behavior across tools and subprocesses reproduces that fragmentation at machine speed.
Visibility also has to survive the containment boundary. If logs exist only inside the environment the agent can alter, they are weak evidence. If isolation prevents the monitoring system from observing meaningful events, the operator receives a sealed box. The execution environment and observation path need separate trust and failure assumptions.
A stop button has to stop the system, not the screen
An interface can show Cancel while the underlying work continues.
The agent may have launched child processes, queued remote jobs, issued credentials, scheduled retries, opened transactions, or delegated work to another agent. Terminating the visible conversation does not necessarily terminate any of them. Interruption is reliable only when cancellation propagates through the execution tree and removes the authority required to keep acting.
This changes the architecture of supervision. A stop mechanism needs an identity for the task, ownership of its descendants, revocable credentials, cancellable operations where possible, and reconciliation for effects already committed. The operator should be able to distinguish stopping new work from undoing completed work. They are different guarantees.
Anthropic's autonomy research found that experienced users shifted toward monitoring and interruption. That strategy works only if intervention is prompt, legible, and technically real. Otherwise the human is watching rather than supervising.
Reversibility determines where permission earns its cost
Not all consequential actions can be contained to a harmless space. A sent email can be corrected but not unsent from another person's mind. A financial transfer may have a reversal process without being instantly reversible. A deleted encryption key, disclosed secret, public statement, or physical command can cross a boundary that no rollback fully restores.
This is where permission remains essential.
The useful approval prompt appears when the nature of the consequence changes: a draft becomes an external commitment, read access becomes write access, a task-scoped identity requests broader authority, staged work moves into production, contained data leaves its environment, or a recoverable operation becomes difficult to reverse. At that point, the system can present the objective, proposed effect, affected resources, evidence, recovery limits, and alternatives as one decision.
That is a much better use of human attention than asking whether the agent may run another search command.
Reversibility should be designed before autonomy is granted. Branches, snapshots, staging environments, transactional writes, versioned records, delayed execution, bounded batches, and compensating actions are mature ways to keep effects recoverable. None makes every action safe. They make the recovery claim explicit enough to test.
There is also a legitimate class of decisions where the missing ingredient is not technical confidence but human authority. Consent, legal attestation, public representation, employment decisions, and other value-laden commitments should not be automated merely because the system can bound their technical blast radius. Containment can answer what the agent is able to do. It cannot decide what a person or institution ought to delegate.
Permission is not obsolete. It is scarce attention that should be spent at the consequence boundary.
Control is what remains when approval fails
The practical test for an agent system is not how many times it asks for permission.
Assume the user approves a plausible but dangerous request. Assume external content successfully steers the model. Assume the model takes a creative path its designers did not anticipate. Then ask what the agent can read, where it can send data, which resources it can change, how long its authority lasts, whether its behavior becomes visible, whether cancellation propagates, and which effects can be recovered.
The answers reveal the control system.
This is why mature security primitives matter so much in a field obsessed with model behavior. Agents still open sockets, read files, spawn processes, present credentials, and change state. Sandboxes, virtual machines, syscall restrictions, workload identity, scoped tokens, policy enforcement, resource limits, event logs, transactional boundaries, and revocation do not make the model correct. They make correctness less responsible for containing every failure.
The goal is not maximum restriction. An agent that cannot reach the material it needs cannot be useful. The goal is deliberate freedom inside a boundary whose failure modes are understood, observable, interruptible, and recoverable.
Permission asks, “May the agent take this step?”
Control asks the harder question: “If every participant is wrong about this step, how far can the failure travel?”