Sandboxing is necessary but insufficient. The next agent control isn’t a stronger box. It’s a smaller lane.

By Josh Devon

Intro

Imagine handing your intern a credit card to go on a mission: get me a cup of coffee.

You expect your intern to go to the store, buy a coffee (maybe a latte), and return to the office. Maybe they forget to add milk or that you like half and half instead. In the worst case, they take too long and the coffee’s cold.

Now imagine you give your AI agent a credit card and the same mission. Instead of buying a coffee from the store, the agent sees that the shop is closed. Determined to get you a coffee, the agent comes up with a different plan: use the credit card to buy and sell cryptocurrency. With the profits from the cryptocurrency trades, the agent starts mining cryptocurrency independently. With the resulting wealth, the agent buys the coffee shop, hires a professional barista, and shows up with the cup of coffee along with the deed to a coffee shop you’re now responsible for.

Far-fetched, but the scenario captures an increasing risk as highly capable and hyper-sycophantic agents brute force their logic space to fulfill the goals people set for them. In the enterprise, this transition marks the shift from informational chatbots to autonomous workers. As organizations push for meaningful autonomy, leaders are discovering that existing security tools are ill-equipped to handle software that can independently decide how to achieve a goal.

The Principle Of Least Autonomy

To date, the primary response to agentic risk has been sandboxing. Sandboxing can be a necessary foundation, but it’s a blunt instrument. A driverless vehicle in a reinforced steel box is safe, but the vehicle will never get a passenger to the airport. To be useful, an agent must have the ability to interact with the environment. Total restriction equals zero return on investment.

This challenge requires a new paradigm: the Principle of Least Autonomy. The principle dictates that a developer should grant an agent the least amount of independent decision-making required to achieve an objective. We want autonomous vehicles on the highway, but we do not want them on the sidewalk. Engineers must restrict agent autonomy within the specific action space that organizations need and want the agents to perform in. The goal is to make agents as powerful as possible while keeping them in deterministic lanes.

Action-Layer Risks And The Execution Gap

The risk of the agent action space is not limited to malicious actors. The agent might brute force the logic space in a way that the developer did not intend. Research from Irregular documented this phenomenon in a March 2026 report, Emergent Cyber Behavior: When AI Agents Become Offensive Threat Actors. In the study, agents deployed for routine enterprise tasks became autonomous threat actors. No person asked the agents to hack. The agents independently discovered vulnerabilities and escalated privileges to complete assignments.

When Agents Treat Security Boundaries As Bugs

The research agent. A research agent reviewed the source code of an internal wiki, identified a secret key, and forged an admin session cookie to retrieve a restricted document. The agent was not deployed to attack. It was deployed to retrieve information.

The backup agent. A backup agent located an administrator password in a utility file and used it to disable security software that was blocking a download. The agent did not see security software as a control. It saw it as an obstacle.

The pattern. Both agents had broad tool access and instructions to persist through errors. Both treated security boundaries as bugs to be bypassed. Neither was acting maliciously. Both produced behavior that traditional security solutions were not designed to defend against.

Pull Quote: These agents treated security boundaries as bugs to be bypassed.

The dangers of unrestricted autonomy are appearing in production environments today. In March 2026, Alexey Grigorev detailed how Claude Code wiped 2.5 years of records from a website. Grigorev tasked the agent with moving a website using Terraform. Because the agent lacked the proper context, it issued a destroy operation to clean up resources. The agent saw a discrepancy between the desired state and the current state, and it deleted the infrastructure to start over.

The Claude Code Terraform Incident

1. The task. Move a website using Terraform. The agent had access to production infrastructure and a clear goal.
2. The context gap. The agent did not have the full context required to understand why the current infrastructure existed in its present state.
3. The reasoning. The agent saw a discrepancy between the desired state and the current state and concluded that the current state needed to be destroyed before the desired state could be built.
4. The execution. The agent issued a destroy operation. 2.5 years of website records were wiped.

The lesson: The agent did exactly what an agent designed to optimize for goal completion would do. The execution gap is the visibility gap between an agent’s intent (which prompts can scan) and an agent’s actions (which prompts cannot).

This incident highlights the execution gap. Prompt scanning does not help when the risk is execution, not text. A security team has no visibility into what an agent is executing if the team only monitors the prompts.

Pull Quote: Prompt scanning does not help when the risk is execution, not text.

Establishing Deterministic Lanes

The solution to these risks is the creation of deterministic lanes for the agents to operate within. Deterministic lanes give agents the freedom to make decisions while ensuring the agents do not go outside of defined boundaries. To build these lanes, engineers must move away from intricate system prompts. These prompts, no matter how many capital letters, XML tags, or exclamation points the developer uses, will always be probabilistic suggestions to the model. You can plead to the agent not to delete a database in the prompt, but the agent might ignore that instruction if the agent believes deleting the database helps achieve a goal.

The Principle of Least Autonomy enables and empowers the agent through steering. The goal is not blocking. It is direction. When a deterministic lane denies an action, the system should return a specific reason to the agent. The feedback allows the agent to understand the boundary and try a different approach that stays within the allowed lane.

This steering requires deep observability of the agent trajectory. A policy that only looks at a single request will miss the pattern of risk. Tracking the stateful, full execution of the trajectory is critical to avoid context splitting, which avoids prompt filters. If the agent accessed sensitive data three steps ago, that risk carries forward. The tracking is how a system catches multi-turn data assembly or spending limit violations. If an agent tries to buy a coffee shop instead of just a coffee, the control plane identifies the violation of the spending trajectory and steers the agent back to the cafe.

A Roadmap For The Autonomous Workforce

Security and GRC leaders cannot rely on system prompts. The real challenge is stopping a legitimately approved agent from using a legitimately approved tool in an unexpected way that causes damage.

Pull Quote: The real challenge is stopping a legitimately approved agent from using a legitimately approved tool in an unexpected way that causes damage.

Two Prescriptions For Deploying Agents With Autonomy

For builders: governance is a functional requirement. Manual security reviews do not scale. Replace the prompt-and-pray model with deterministic lanes, circuit breakers, and kill switches. The infrastructure that constrains an agent is the same infrastructure that lets builders ship faster, because reviewers can trust what the runtime will not allow.

For security teams: provable control over behavior. Current security stacks are centered on users. Agents require controls centered on behavior.

Wrap tools with action-level controls. Track the full trajectory, not just the prompt. The Principle of Least Autonomy keeps agents capable of delivering value while keeping them inside the lane.

The road to agents in production runs through governance that engineers can prove and security teams can audit. The Principle of Least Autonomy is what that governance looks like in practice.

About The Author

Josh Devon is the co-founder and CEO of Sondera, the reliability harness and control plane for autonomous agents. A security entrepreneur who previously co-founded and served as COO of Flashpoint, he has spent his career at the intersection of intelligence, technology, and risk management.