Approval Is Not Isolation: Designing Safer AI-Agent Tool Access

Approving an AI agent’s action and limiting its technical reach are different decisions.

Source review cutoff: November 1, 2026, 11:45 p.m. Eastern Time (GMT−05:00).

Approving an AI agent's action and limiting its technical reach are different decisions. A person may intend to authorize one test run, not access to unrelated files or permission to publish a release. A useful access policy must express both the permitted task and the boundary within which it can run.

Claude Code's documentation provides a concrete example of these layers. This analysis uses its local execution model to explain a broader design problem, not to rank products or claim that one configuration eliminates agent risk.

Hero image: Human approval and resource isolation are separate controls. AI-generated conceptual illustration, not a product interface, tested architecture or guarantee against attacks.

AUTHORIZATION AND CONTAINMENT WORK TOGETHER

Tool permissions govern which actions the agent can take. In Claude Code, rules can allow, ask about or deny tool use. Matching rules are evaluated in deny, ask, then allow order; a narrower allow rule does not override a broader matching deny. The documentation describes permissions and operating-system sandboxing as complementary controls. Prompt behavior also depends on the active mode and sandbox settings, so counting prompts is not a reliable measure of protection. Claude Code permissions

The working directory illustrates the distinction. In Manual mode, Claude Code asks before its file tools access locations outside the permitted directory scope. That prompt is not an operating-system barrier: an approved, unsandboxed shell command can still write wherever the user's account can. The security documentation also distinguishes Manual mode from the auto mode now used as the starting mode for interactive terminal and VS Code sessions. Do not assume every session begins with the same approval behavior. Claude Code security

CoinRank analysis: authorization should describe intent, while containment should limit the consequences of a mistaken or manipulated action. One cannot substitute for the other. A blocked command may indicate a useful boundary, rather than a workflow defect that needs a broader permission.

KNOW WHAT THE SANDBOX ACTUALLY COVERS

Claude Code's built-in sandbox is off by default. When enabled, it applies operating-system restrictions to shell commands and their child processes. Built-in file and web tools, MCP servers and hooks sit outside that shell boundary and need their own controls. It is supported on macOS, Linux and WSL2, not native Windows. Sandbox documentation

Its defaults are not a private workspace containing only the project: shell reads can reach much of the machine, including credential files, and subprocesses inherit environment variables. Write access is narrower, covering the working directory, temporary storage and added locations, subject to protected paths. Network access is filtered through a host-checking proxy, but outbound encrypted content is not inspected by default. The documentation explicitly warns that this is not complete isolation. Sandbox defaults and limitations

Before treating a workflow as contained, map each operation to the process that performs it and the resource it reaches. Review that map as a whole; a reassuring label on one component is not evidence about every other component.

A LEAST PRIVILEGE MATRIX FOR THREE REAL TASKS

The matrix below is CoinRank's proposed workflow design, not a vendor default or a guarantee. Apply the relevant controls separately to shell execution, file tools and connected services.

Explain an unfamiliar repository

Local access to grant: Read the selected source snapshot; no edits or shell execution unless separately justified

Network and identity: No external access for an offline explanation; no service credentials

Approval and stopping point: Stop with findings and cited files. Ask before running repository code or expanding scope

Fix a bug and run tests

Local access to grant: Read the project; write to a dedicated working copy and required temporary paths; exclude unrelated secrets

Network and identity: Only justified dependency or test endpoints; test identity, not production credentials

Approval and stopping point: Approve the test plan and changes in scope. Stop with a diff and test results, before merge or deployment

Publish an approved website update

Local access to grant: Read the approved artifact; write only required staging output

Network and identity: Exact publishing service and target; narrowly scoped publishing identity

Approval and stopping point: Approval identifies the artifact and destination. Verify the live result, then end the temporary access

WHY THE TASK BOUNDARY MATTERS

For repository explanation, the desired output is understanding. Running an installation script adds execution risk without necessarily improving that answer. Start with the supplied files; missing information is a reason to explain a limitation or request a specific extension, not to grant general system access.

For a bug fix, tests are executable code, not merely evidence. Keep the working copy disposable and decide which dependencies and external services are genuinely needed. Separate the ability to produce a patch from the authority to merge it. A successful test run supports a technical judgment; it does not authorize release.

Publishing introduces an external state change. A narrowly contained local process may still hold a credential that can alter a remote production service. The publishing account's permissions and the approved destination therefore belong in the access review. A local sandbox cannot, by itself, define what a remote service will let that account do.

These distinctions extend the operational questions raised in CoinRank's Clawdbot overview: moving from answers to actions requires explicit decisions about authority. This article examines those decisions at the task level rather than treating autonomy as a single on-or-off choice.

VERIFY THE BOUNDARY BEFORE EXPANDING ACCESS

Before a recurring agent workflow is trusted, establish a small acceptance test:

1. Record the task, permitted tools, data locations, external destinations and approving owner. Give temporary access a clear expiry or end condition.
2. Inspect the effective settings for the actual version, platform and execution mode. Include connectors and helper processes, not only the main shell.
3. In an authorized test environment, use harmless files and controlled endpoints to check that required operations succeed and out-of-scope operations are refused. Do not test with real secrets.
4. Preserve the approved scope and test results. If the task needs more access, review that specific change and repeat the affected checks rather than widening the entire policy.

This is a proposed verification process, not a substitute for a security assessment. Passing a few checks cannot prove the absence of every unintended path.

WHAT THE CONTROLS CANNOT PROMISE

Approval does not establish that retrieved text or repository content is trustworthy. Anthropic describes prompt-injection mitigations while acknowledging that no system is immune to every attack. Its security guidance also notes that reviewing a project's MCP configuration does not reveal every server a session may load. Security safeguards and MCP scope

An allowed destination is not automatically an approved destination for every piece of data. Likewise, a permitted write location may still contain something important. Narrow the access, but also review what the workflow sends and changes.

The next step is not to maximize or minimize the number of approval dialogs. Choose one real task, write down the least access it requires and verify that the implemented boundaries match that description. Expand capability only when the task requires it and the new scope has an accountable owner.

〈Approval Is Not Isolation: Designing Safer AI-Agent Tool Access〉這篇文章最早發佈於《CoinRank》。