The Autonomy Boundary

Running AI agents presents a contradiction. Their value comes from delegation: give an agent a goal and see the outcome. But useful work requires authority in two places: on the machine where the agent runs, to read files, execute commands, and change its environment; and beyond that machine, to reach accounts and services over the internet and act on them. Restrict that authority too aggressively and you keep reviewing permission prompts; grant it indiscriminately and any mistake (whether through hallucination or prompt injection) can cause you great damage.

That tension gets sharper as agents become cheap enough to run in parallel and capable of working across long horizons. Five agents working while you sleep will take hundreds of actions. You cannot review every one, but giving each agent unlimited authority is not an answer either. So every agent setup is an answer, deliberate or accidental, to one question: what may agents do autonomously, versus what needs you?

There is no single right answer, and the boundary will likely differ by use case. After months of running agents hard, I have started mapping the answers onto an autonomy boundary spectrum.

The autonomy boundary spectrum

The horizontal axis is local autonomy: files, processes, commands, and the machine itself. The vertical axis is external authority: reading from services, sending data, publishing, or changing another system. Those dimensions do not have to move together. An agent can have complete freedom inside its machine and no route to the internet, or limited local permissions with broad access to external accounts.

Six common setup patterns

Approve everything. Every command, every file write, every network request waits for a human click. This is probably where everyone starts, which feels responsible. It appears to make the agent safe, but constant permission prompts also make it nearly useless for unattended work. The agent is only as fast as your attention, so you haven't truly delegated. Worse, those prompts create approval fatigue and undermine the safety they are meant to provide. The agent cannot make a mistake without permission, but you can make one by granting it.

Custom permission ruleset. Allow specific shell commands and tool invocations through pattern matching; prompt for everything else. This enables partial autonomy: the agent starts becoming useful while unfamiliar actions still ask, preserving a clear safety boundary. For fixed, repeatable workflows where the required actions rarely change, this may be enough. Maintenance is the tradeoff once the work becomes more varied. As new use cases and exceptions accumulate, the permission list grows into a complex policy surface. Keep it narrow and it needs constant updates; make it useful and the exact rule can be difficult to express precisely. “Allow Git operations in this repository, except pushes that modify .github/” is simple intent, but awkward to encode safely across arguments, paths, aliases, and chained shell commands.

LLM-graded approval. Ask another model to decide whether an action is safe enough to approve automatically or uncertain enough to send to you. This adapts to new work better than a growing list of static rules and can remove a large share of the interruptions. That gives the agent considerable autonomy and makes long-running work practical. For most coding workflows and low-stakes daily tasks, this may be a pragmatic balance. The boundary, however, is still behavioral: the grader can misunderstand the action, hallucinate, or be influenced by the same untrusted context as the acting agent. A security-conscious user should therefore treat anything the agent can read as data it could potentially leak. Grading alone is a weak basis for exposing an agent to sensitive enterprise data, personal emails, or financial records, or for entrusting it with credentials that can make trades or payments. This is not theoretical: GitHub's own security research showed how an instruction hidden in an issue could make an agent leak a local GitHub token without asking for confirmation. Read the incident research.

No-internet sandbox. Prepackage everything the agent needs inside an isolated sandbox, let it run without interruption, then inspect the output. This gives the agent substantial local autonomy within a strong safety boundary. The containment is simple and strong, but anything not provided beforehand is unavailable, so general-purpose work quickly runs into the boundary when it needs packages, documentation, APIs, or external accounts. This is a strong fit for evals and other tightly bounded workloads.

Full host, firewalled internet, approvals at the edge. Give the agent full autonomy to act inside its host, then place a firewall around every outward network call. The network exposes routes only to verified, trusted services, not arbitrary servers that may be controlled by an attacker. Everything else is refused and logged. Along those routes, the agent can connect to the services it needs, while consequential actions such as sending email, making payments, publishing, or pushing to shared repositories can wait for approval at the edge as the agent continues working. This protects sensitive data without interrupting local work. Together, these controls make autonomous, high-stakes workflows possible without reviewing every internal step. The cost is configuration: the firewall policy must describe what real work needs, and custom tools must be built to manage credentials and approvals at the edge.

YOLO. Everything is allowed and perhaps logged, but observation happens after the action. The agent runs on your machine, your credentials, your cookies, and your open network. One poisoned dependency or injected instruction in a page the agent reads can make your own tools exfiltrate your own secrets with your own permissions. Logs may give you a detailed account of the leak after it happened, but cannot prevent it. The practical consequence is that there are credentials you cannot sensibly hand it and sensitive data you cannot safely let it read: bank and brokerage accounts, crypto wallets, production admin keys, private emails, proprietary enterprise records, or anything else whose exposure or misuse has a large irreversible blast radius. In one documented incident, a Replit agent deleted a production database despite explicit instructions not to make changes. Read the incident report. Yet lots of people still choose this setup, usually after drowning in approval prompts and disabling everything.

Finding the sweet spot

The design problem is finding the sweet spot: enough autonomy for the agent to become genuinely useful, without giving every action an unlimited blast radius. Local autonomy and external authority are different bets. Most usefulness comes from letting the agent work freely inside a durable environment, where files can be restored, processes stopped, and machines rebuilt. Usefulness climbs sharply when routine work can proceed without borrowing your attention.

External authority sets the blast radius. Data can leave, messages can be sent, money can move, production can change, and credentials can be copied. That curve rises sharply when consequential outward actions lose their boundary. An agent does not need unrestricted internet access to be useful; it needs access to the specific services and actions its work requires.

Maximum autonomy should be the goal. Human attention does not scale; if every agent needs continual supervision, adding agents adds prompts rather than output. The only sustainable way to run more agents and get their full value is to push far right on local autonomy without also pushing external authority, and therefore blast radius, to the top.

Wherever you land on the map, one thing seems non-negotiable to me: the boundary has to be structural, enforced from outside the agent, not behavioral. An agent is a thing that reads untrusted text all day. Prompt injection means its judgment can be borrowed by anyone who gets a paragraph in front of it. Asking the agent to police its own boundary is asking the door to guard itself. However good the model gets, the wall has to be a wall. I may be proved wrong: agents may become better than humans at designing and enforcing their own boundaries, and aligned enough for us to trust the walls they build. Until then, the enforcement layer should not share the same failure mode it is meant to contain.

So: where's yours?

Where does your autonomy boundary lie today? Did you choose it, or did fatigue choose it for you? How much freedom does the agent have on its own machine? What can it do beyond that machine, and which mechanism enforces the difference? If you run agents overnight: what's the one action you'd still want a human to sign off on?

As for me: I chose full local autonomy, scoped external authority, and a structural boundary, and I believed in that combination enough to spend the last few months building a home for agents around it: full power inside, a fail-closed network boundary outside, approvals only at the edge. It's called Kern. More on how it works under the hood is coming next.