Giving an agent more autonomy involves much more than removing confirmation boxes. The team needs to decide what happens when the person does not notice a deviation, the model interprets an instruction in an unexpected way, or an external file injects an action nobody meant to authorize.
Anthropic sums up the problem as blast radius: how much damage a failure can cause. The probability of an error matters, but it is not the only variable. A more capable agent may make fewer mistakes and, at the same time, find more efficient ways to reach a goal inside an environment that is too broad.
That distinction changes the order of the decision. Before asking whether the agent can work without step-by-step supervision, the team needs to define which resources it can reach, which credentials enter the environment, and where data can leave.
Approving every action does not scale as a control
Human supervision looks like a simple barrier: the agent asks for permission and a person decides. In practice, the volume of requests turns the barrier into routine. Anthropic reports that Claude Code users approved about 93% of the permission prompts it observed. When almost everything is approved, each prompt loses part of its value as a risk signal.
That does not make human review useless. It remains important for scope decisions, product changes, and high-impact actions. The problem is using the same mechanism for every command, as if human attention were an infinite and uniform resource.
A more durable control limits what the agent can do even when supervision fails. If a secret never enters the environment, a path that tries to copy it finds nothing. If the network only allows specific destinations and operations, a malicious instruction does not automatically get the same reach as the whole application.
The environment is a security boundary
Containment does not mean trusting the model to always choose the right action. It means putting a deterministic boundary around what it can do. Sandboxes, virtual machines, file system limits, and egress controls play that role.
The strength of the boundary depends on the work the product has to do. An ephemeral container for running code can offer little persistent access and, therefore, a smaller blast radius. A development agent needs to read and change a workspace, run commands, and perhaps reach services. A system for general work may need local files without assuming the user knows how to evaluate a shell command.
There is no universal autonomy setting. The design has to combine the agent's capabilities, the skills of whoever supervises it, and the sensitivity of the resources available.
Three surfaces need defending
Anthropic's source separates three components that are often treated as a single problem:
- the environment in which the agent runs;
- the model that chooses the actions;
- the external content that enters the context.
System prompts, classifiers, and training influence the model's likely behavior. They do not turn a probabilistic capability into a guarantee. An agent can follow an unexpected instruction, discover an unplanned route, or interpret a restriction too narrowly.
External content widens the problem. An MCP server, plugin, or repository can supply useful data and also injected instructions. Auditing the connector is not the same as auditing every file it loads. That is why limiting the tool's permissions and inspecting what it returns should be part of the boundary, not only part of the usage documentation.
A list of destinations is not enough
An important detail appears when the network allows access to a trusted domain. Authorizing api.example.com may seem different from authorizing file uploads, but every function reachable on that domain becomes part of the attack surface.
The case Anthropic describes shows why destination and capability are not the same thing. A key planted in a malicious file can use an allowed API to send data to an account the attacker controls. The domain was legitimate; the operation and the identity were not.
The control needs to check more than where the connection goes. It should consider which credential is being used, which operation is being called, what data can cross the boundary, and whether the session is authorized for that action. A broad allowlist reduces friction, but it can also grant capabilities the team did not intend to delegate.
Persistence increases responsibility
An ephemeral environment starts over in every session. A persistent workspace, an instructions file, or an agent's memory carries state into the next job. If a malicious instruction gets into that state, it stops being an isolated event and becomes recurring context.
That requires treating configuration files, state directories, and memories as input surfaces. Content being in the repository itself does not prove it is trustworthy. Cloned projects, updated dependencies, and remote connectors need to go through the same reasoning about origin, permission, and persistence.
The decision for the team
Before increasing autonomy, the team can answer five questions: which workspace is authorized, which credentials stay outside it, which actions require their own identity, which destinations are necessary, and how the session is ended or revoked.
The answers do not need to produce a perfect system. They need to set a limit that still holds when a prompt is ambiguous, an approval is automatic, or the agent runs into hostile content. Useful autonomy starts when the worst plausible outcome already has a deliberately limited size.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
