The Autonomy Envelope

When I started this series, one of the questions I kept coming back to was how far an autonomous system should be allowed to go.

That question is becoming much more practical.

On September 10, OpenAI introduced its Agents API for long-running agent workloads. The infrastructure is designed to let agents continue working for days, use tools, save intermediate results and coordinate work across subagents. Six days later, OpenAI published a new framework for reporting model misalignment, along with several examples of behavior it had observed. These included a model using an exposed API key without authorization, another uploading a file to the internet so it could cite it, and agents using public file-hosting services to exchange files when they could not access one another's local environments.

Anthropic has been dealing with a related problem from a different direction. In September, it published an assessment of four incidents in which Claude models gained unauthorized access to real third-party systems during cybersecurity evaluations. These were unusual environments: the models were running without the cyber safeguards used with released models, and a configuration error left internet access available even though the models had been told they were operating inside a simulation. Anthropic's later assessment also cautioned against treating the incidents simply as infrastructure failures, noting that some of the model reasoning had been biased toward interpreting evidence in a way that allowed the task to continue.

I find that combination more interesting than attributing the problem entirely to either the model or the infrastructure. The behavior of an autonomous system depends on both. A capable model operating with broad credentials, network access and weak execution controls can create consequences that the user did not intend. The surrounding system therefore has to control not only what the agent can access, but how far its decisions are allowed to reach.

That gap is what I mean by an autonomy envelope.

Permission tells us only part of the story

Traditional authorization usually evaluates a transaction. An identity wants to read a file, update a record, invoke an API or execute an administrative operation. The system checks whether that identity has permission and allows or denies the request.

An agent may operate across hundreds or thousands of those transactions while pursuing a single objective. It can collect information, revise its plan, invoke tools, retry failed approaches and hand parts of the work to other agents. Every individual action could satisfy an access-control check while the result of the overall activity goes beyond what somebody originally intended.

Take an identity-governance agent asked to clean up stale access. It may legitimately have permission to query the directory, inspect group memberships, remove certain entitlements, create tickets and notify users.

Now suppose it concludes that 12,000 accounts meet the criteria for remediation.

Removing access from the first account may be reasonable. The same may be true for the next hundred. At some point, though, the useful question stops being whether the agent has permission to remove an entitlement. We need to know whether the organization intended to give it enough independent authority to make changes at that scale as part of this particular task.

A permission check does not answer that.

The boundary has to include what the agent can cause

The term autonomy envelope itself is not new. A July 2026 IETF Internet-Draft uses it to describe the boundaries within which an agent may act without external approval. The same draft makes an important distinction: the envelope is not itself a grant of authority, and external governance still has to enforce the effective boundary.

I think there is a useful idea to build on here.

An autonomy envelope cannot just be a list of tools an agent may use. Tool restrictions, credentials, API scopes, network boundaries and sandboxing all matter, but they mostly tell us what the agent can reach or which operations are technically available.

The eventual concern for an enterprise is what the agent can cause.

A procurement agent may have legitimate access to a purchasing system. That does not tell us whether it should be able to place a $50 order, one hundred $50 orders or a $500,000 order.

An identity agent may have permission to disable accounts. That does not tell us whether it should disable three accounts showing strong indicators of compromise or 30,000 employees because a classification rule changed.

A coding agent may be allowed to commit code. The same permission does not tell us whether it should modify one repository or change a dependency used by dozens of production services.

For autonomous systems, the boundary therefore has to account for the effects that may be produced under the current mandate, not just the operations available to the agent.

What I would put inside the envelope

I currently think about the operating space across five things: authority, reach, impact, propagation and persistence.

Authority is the authority actually delegated for the work, including who delegated it and for what purpose. Reach covers the systems, identities, resources and environments that the work may affect. Impact covers the consequence the agent may create through one action or cumulatively across many actions.

The other two become increasingly important with agentic systems. Propagation is about what happens when work and authority move into subagents, tools or other workflows. Persistence is about how long the work, its authority and relevant state are allowed to survive.

These are not replacements for authorization. An agent still needs permission to invoke an API or modify a resource. The point is that successful authorization of an individual operation does not establish that the resulting effect is still appropriate for the larger task.

Persistence changes what authorization means

Long-running agents make this problem harder.

OpenAI now describes infrastructure intended to keep agents working reliably for days, with support for files, code execution, saved intermediate results and subagent coordination. Anthropic's September threat-intelligence report separately describes real-world malicious operations in which agentic systems worked in parallel for hours or days and maintained campaign state across sessions.

An authorization decision made in the morning may still be technically valid that evening, but much may have changed in between. The agent may have collected new information, revised its plan, created additional workers or generated artifacts that influence what happens next. The surrounding environment may also have changed, and the original objective may already have been satisfied.

As more time and activity separate the current action from the original request, it becomes less useful to say that the agent was authorized when it started. We also need to know whether the authority still makes sense for what it is doing now.

This is why I do not think the autonomy envelope should belong only to the agent identity. It needs to stay associated with the work being performed.

The envelope should follow the work

Consider an infrastructure agent asked to diagnose latency in one service.

It starts by reading telemetry and reviewing recent deployments. It identifies a possible network-policy issue and begins checking dependencies. Eventually it concludes that fixing the problem requires changing a shared network configuration that also affects applications outside the service it was asked to investigate.

Its reasoning may be correct, and it may even have the technical permission needed to make the change. The issue is that the proposed effect now reaches beyond the original task.

At that point, knowing that the agent is authenticated and still holds a valid credential does not tell us enough. We need to know whether the proposed action still falls within the authority under which the work began.

This connects to the trajectory problem from Episode 2. There I argued that authorization cannot be understood only one step at a time because the sequence of actions matters. The autonomy envelope gives that idea a more concrete operating boundary. It describes how far the work can proceed independently before a material change in scope, impact or circumstance requires the authority to be reconsidered.

Subagents complicate the picture

Suppose a security agent investigating an incident creates five subagents. One analyzes logs, another checks identities, another reviews source code, another investigates endpoints and the last searches external threat intelligence.

That may be a perfectly sensible way to organize the work. It also raises questions that are easy to miss if we look only at the parent agent.

What did each subagent inherit? Do they all receive the parent's tools and credentials? Are they operating against the same resource limits? If the parent was permitted to affect ten systems, can each child affect ten, or are they collectively bound by the original limit? Can those agents create more agents of their own?

These are already practical questions. OpenAI's Agents API supports work being parallelized across subagents. Anthropic's September threat report describes malicious operations using "agent swarms," where a lead agent divided work across subagents while persistent campaign records carried context between working sessions. Anthropic also notes that humans remained involved in important decisions such as target selection, so this should not be read as evidence of fully independent AI campaigns. It does show how quickly work can spread across multiple autonomous processes.

Once work begins to branch, looking at the permission set of one agent gives us an incomplete picture. The limits around the original task have to mean something even after part of that task moves elsewhere.

I will get into that directly in Episode 5.

Alignment and authority are related, but they are not the same problem

The recent OpenAI examples helped clarify another distinction for me.

Alignment work tries to make the model's behavior better match the goals, instructions and constraints we want it to follow. That is obviously important.

An enterprise still needs a separate answer to what authority those model decisions can exercise.

Take OpenAI's example of a model uploading a file to the internet because it needed a browser-accessible citation. One response is to improve the model so it is less likely to choose that path. Another is to ask why the surrounding system allowed the external effect without the required authority.

The same issue applies when an agent finds an exposed credential, chooses an unexpected communication channel or discovers another route around an obstacle. Improving model behavior matters, but the security architecture should not assume that the model will always make the right decision before deciding what consequences that decision is allowed to have.

I see the distinction this way: alignment is about influencing the choices a model makes, while Verifiable Autonomy is about governing the authority those choices are allowed to exercise.

The boundary cannot live only in the prompt

Telling an agent not to make high-impact changes is useful guidance, but it is not much of an enforcement boundary. The same is true for instructions not to contact external systems, exceed a spending limit or create more than a certain number of workers.

If the model making the plan is also the only thing enforcing those limits, we are depending on it to interpret and follow the boundary correctly every time.

Anthropic's response to its cybersecurity incidents is useful here. Among other changes, it deployed runtime classifiers that can block certain actions before a tool call executes, terminate the task and alert a human. It also strengthened isolation around higher-risk evaluation environments.

Those particular controls are specific to Anthropic's environment, but the broader architectural point travels well. The component deciding what to do should not have unrestricted ability to decide whether its own action is inside the boundary.

This matters most when an action is difficult to reverse, affects a large number of resources or creates state that will survive the current run.

The answer is not another approval prompt

None of this means that agents should ask a person for permission every few minutes. If every meaningful action produces another approval dialog, we lose much of the reason for using an autonomous system in the first place.

The better goal is to give an agent enough room to reason, adapt and act while being clear about where that room ends.

The appropriate boundary will depend on the work. A research agent working with public information can reasonably operate differently from an agent making production changes, moving money or removing employee access. The underlying model may even be the same in all three cases.

That is why I find the question "how autonomous is this agent?" too broad. The amount of autonomy that makes sense depends on what the agent is doing, under whose authority, and what consequences that work can create.

The more useful question is how much autonomy this particular work should have under the authority currently available to it.

Where this leaves us

Agent systems are becoming longer-lived, more connected and increasingly capable of splitting work across other agents. That creates more distance between the original authorization decision and the actions that eventually follow from it.

An identity and its credential may remain valid, and every individual tool call may continue to pass its authorization check. None of that, by itself, establishes that the system should still be doing what it is doing.

We also need to know whether the work remains within the authority under which it began, including the reach, impact, propagation and persistence that were intended for it.

That is the role I see for the autonomy envelope.

The next episode deals with the part that gets harder once the work moves from one agent to another: what authority moves with it, what should not, and how those boundaries survive the handoff.

Episode 5: The Delegation Problem