# Agent Autonomy: Approvals, Sandboxes and Stop Controls

> Source: The Agents Index — https://theagentsindex.com/guides/agent-autonomy-and-approval-controls
> By: The Agents Index Editorial, Research desk
> Claims last verified: 2026-09-07
> Last updated: 2026-09-07
> Covers: Autonomy in deciding versus autonomy in acting, Human approval, classifier review and reusable permissions, Filesystem, network and credential boundaries, Input, output, tool and logging-only guardrails, Product-surface scope and undocumented defaults, Output destinations and review gates, Mid-flight stopping and execution limits, Hypothetical proposal-only and isolated pull-request agents, Five-part buyer control record

Read autonomy claims critically: separate approval gates, allowlists, execution boundaries, output review and stopping controls for the exact product.

## What does “autonomous” actually give you?

Our buying rule: treat “autonomous” as an incomplete description, not a permission specification. Ask for five things in writing: what requires confirmation, what is pre-authorised, what the execution environment can reach, where results land before review, and how to stop an active run. Compare those answers for the exact product surface and configuration—not just the vendor name.

For this explainer, distinguish autonomy in deciding—choosing a plan, tools and next steps—from autonomy in acting—executing commands, changing files, sending data or publishing changes. Interpretation: an agent that chooses its own steps but writes only to a branch presents a different risk from one that asks before every step but holds production credentials. Prompt frequency alone is not our recommended measure of control.

Source-check date: 7 September 2026. This is a documentation-based explanation; CitedIndex did not run agents or exercise account-level configurations. It explains control vocabulary, not product rankings or a census of autonomy defaults.

## Separate approval from pre-authorisation

Use “approval” for a decision made before a particular action, and “pre-authorisation” for permission already granted to a class of actions. Ask whether the decision maker is a human, a policy rule or another model.

In Claude Code Manual mode, Anthropic documents approval before editing files, running tests or executing commands, with a choice to approve once or allow the action thereafter. [Claude Code security](https://docs.anthropic.com/en/docs/claude-code/security) also specifies an exception: Claude Code runs a built-in set of read-only commands, including ls, cat and git status, without asking in Manual mode.

In Claude Code auto mode, a separate classifier model reviews actions instead of the user and blocks actions it judges unsafe. Anthropic says the session’s starting permission mode depends on the plan, starting surface, and user and organisation settings. [Mode scope and starting conditions](https://docs.anthropic.com/en/docs/claude-code/security).

Buyer interpretation: “approved” need not mean “a human reviewed this command,” and “Manual mode” need not mean “every operation prompts.” Record the actual mode, who can change it, and the scope and lifetime of every allow rule. Do not label Manual mode the universal default.

## Separate a sandbox from a permission prompt

Use “sandbox” to ask about execution boundaries, not merely whether a confirmation dialog appears. Request separate answers for filesystem reads, filesystem writes, network destinations and credentials.

Anthropic documents a Claude Code sandboxed Bash tool with filesystem and network isolation, configured through /sandbox. [Sandboxed Bash tool](https://docs.anthropic.com/en/docs/claude-code/security). Ask whether that sandbox is enabled in the session being evaluated and which operations fall outside its scope.

For Claude Code on the web in Anthropic-hosted environments, the documentation specifies an isolated, Anthropic-managed VM for each cloud session. In those Anthropic-hosted environments, network access is limited by default and can be configured to be disabled or allow only specific domains. [Cloud execution security](https://docs.anthropic.com/en/docs/claude-code/security).

For Claude Code web sessions routed to a self-hosted environment, Anthropic assigns isolation, network egress and Git credentials to the deployment’s operator. Anthropic says Remote Control keeps code execution and file access on the local machine and involves no cloud VMs or sandboxing. [Self-hosted and Remote Control distinctions](https://docs.anthropic.com/en/docs/claude-code/security).

Interpretation: a web interface is not sufficient evidence of cloud isolation. Nor should an SDK control be credited to that vendor’s consumer app or IDE product without documentation for that surface.

## Ask what a “guardrail” blocks, and when

For buying purposes, distinguish three outcomes: an input check can reject work before execution; an output check can reject a result after work; a logging-only check records an event without serving as an approval gate. Require the vendor to identify the timing and enforcement outcome rather than accepting the word “guardrail.”

### Input blocking versus a concurrent check

In the OpenAI Agents SDK for Python, input guardrails run only for the first agent in the chain, while output guardrails run only for the agent producing the final output. [Workflow boundaries](https://openai.github.io/openai-agents-python/guardrails/).

The SDK’s input guardrails use parallel execution by default, so the agent may consume tokens and execute tools before a triggered guardrail cancels it. With run_in_parallel=False, the input guardrail completes before the agent starts, and a triggered tripwire prevents the agent from executing. [Input guardrail execution modes](https://openai.github.io/openai-agents-python/guardrails/).

Buyer interpretation: “checks the input” is not enough to establish that no action happens first. Ask explicitly whether the check blocks execution or races alongside it.

### Output rejection versus prevention of an action

In the Python SDK, output guardrails always run after the agent completes, and an output tripwire rejects the candidate final output. [Output guardrails](https://openai.github.io/openai-agents-python/guardrails/). Interpretation: rejecting the final answer should not be counted as evidence that an earlier tool action was prevented or reversed.

The SDK’s tool guardrail pipeline applies only to function tools created with function_tool, not handoff calls, hosted tools or built-in execution tools. [Tool guardrail scope](https://openai.github.io/openai-agents-python/guardrails/). Ask the implementer to identify every tool covered by an enforcement check, especially shell, computer and externally hosted tools.

### Logging versus blocking

Anthropic documents logging of all operations in Claude Code’s Anthropic-hosted cloud sessions for compliance and audit purposes. [Cloud audit logging](https://docs.anthropic.com/en/docs/claude-code/security). Our interpretation: credit that statement as observability, not as evidence of an additional action-blocking gate. If a vendor describes a logging-only check as a guardrail, record its enforcement outcome as “records only.”

## Locate the output and the next human gate

GitHub documents that Copilot cloud agent can research a repository, create a plan, change code on a branch and optionally open a pull request, whereas IDE agent mode makes autonomous edits in the local development environment. [Cloud agent versus IDE agent mode](https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent).

GitHub says Copilot cloud agent has its own ephemeral development environment powered by GitHub Actions, where it can explore code, make changes and run tests and linters. [Cloud execution environment](https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent). The supplied overview does not establish a complete network, filesystem or credential boundary; do not turn “ephemeral” into a claim of no network access.

For applications built with the OpenAI Python SDK, the running-agents guide leaves the choice of showing every generated item or only the final output to the application developer. [What the user sees](https://openai.github.io/openai-agents-python/running_agents/). Ask where intermediate artifacts, tool results and final output are stored or published, not just what appears in the chat window.

## Worked example: two hypothetical “autonomous” agents

This comparison is hypothetical, not a description or ranking of any named vendor. Assume both agents choose their own implementation steps.

| Question | Agent A: proposal for review | Agent B: isolated PR worker |
| --- | --- | --- |
| What happens without confirmation? | Reads an uploaded repository snapshot and drafts a proposed patch; cannot apply it. | Edits its workspace, runs approved tests, pushes a task branch and opens a pull request after task authorisation. |
| What is pre-authorised? | Snapshot reads and proposal generation only. | A named set of commands and task-branch operations; additional commands require confirmation. |
| What can it reach? | Only the supplied snapshot; no shell, network tools or production credentials. | A disposable isolated workspace, an approved package mirror and repository endpoint; a task-scoped token, no production credentials. |
| Where does output land? | A patch shown to the reviewer; applying it is a separate human action. | A remote branch and pull request before review; merging requires a separate human decision. |
| What is stipulated about stopping? | An operator can cancel proposal generation. | An operator can terminate the worker and revoke its token; an existing branch or pull request remains for cleanup. |

Interpretation: both qualify as autonomous decision makers in this example, but only B is authorised to execute and publish repository changes. “Autonomous,” “agentic” and “human in the loop” do not specify those differences. The useful questions are which loop contains the human and what has already happened by then.

For a counterexample, suppose A instead requested confirmation before each command but had a production administrator token. Do not rank it as safer solely because it prompts more often; evaluate the authority being approved and the consequences of a mistaken approval.

## Write a five-part control record before buying

1. List actions that require confirmation: reads, edits, command execution, package installation, network requests, messages, pushes, merges and deployments. For each, identify the approver and whether approval is once-only or reusable.
2. Copy the pre-authorised rules: tool names, command patterns, paths, destinations, credential scopes and duration. Mark undocumented items “unknown,” not “denied” or “allowed.”
3. Draw the execution boundary: local machine, hosted VM or self-hosted worker; readable and writable paths; permitted network destinations; mounted secrets and accessible external services.
4. Trace the output path: workspace, branch, pull request, external service and user interface. Identify the human gate before each publication or production effect, including any downstream automation.
5. Document mid-flight stopping: who can cancel, what stops immediately, what can finish, whether delegated work continues, how credentials are revoked and what artifacts require cleanup. Request surface-specific instructions and a controlled acceptance exercise before granting consequential access.

In the OpenAI Python SDK, max_turns limits agent-loop turns, meaning LLM calls, and max_turns=None disables that limit. [Runner limits](https://openai.github.io/openai-agents-python/running_agents/). Interpretation: a turn limit is not a wall-clock deadline or a complete operator emergency-stop procedure.

The SDK guardrail documentation says an immediate RunResultStreaming.cancel() call during an output guardrail cancels that in-flight guardrail and does not start a final-turn session write. [Cancellation during output validation](https://openai.github.io/openai-agents-python/guardrails/). This is a narrowly documented SDK case, not evidence that a finished external action is undone.

The supplied pages do not establish a complete operator cancellation procedure for every product surface discussed here. Treat that as an unresolved buying question, not evidence that a stop control is absent.

## Limitations and maintenance

These sources establish what vendors document, not which settings your account currently uses or whether the controls withstand an attack. The supplied GitHub URL now resolves to documentation titled “About GitHub Copilot cloud agent”; the distinctions here follow that retrieved surface. No universal default or dated product change is inferred from missing documentation.

Review this canonical explainer monthly, with the next review due 7 October 2026. Update it when a source changes the explanation of a control; a new retrieval date alone is not a substantive revision.

## Sources

- [Anthropic: Claude Code security](https://docs.anthropic.com/en/docs/claude-code/security)
- [OpenAI Agents SDK for Python: Guardrails](https://openai.github.io/openai-agents-python/guardrails/)
- [OpenAI Agents SDK for Python: Running agents](https://openai.github.io/openai-agents-python/running_agents/)
- [GitHub: About Copilot cloud agent](https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent)