What can an agent touch?

Explore the separate authority of local files, shell commands, model requests and hosted processing.

Open a boundary to see what needs a separate decision. This guide does not scan your device. The full map is open for printing.

Local files

Authority: Access to the folders and files available to the application.
Check before acting: Choose the smallest folder needed. Check file permissions and any synced-folder destination.
Risk to consider: A local file may already be synced elsewhere. Local storage does not prove local model processing.

Host shell

Authority: Commands run with the permissions of their operating system user.
Check before acting: Inspect operating system permissions, exposed tools and the working directory before running a command.
Risk to consider: A command can change files, start processes or use the network even when a prompt asks it not to.

Model request

Authority: The selected model service receives the context sent to it.
Check before acting: Confirm the selected destination, attached files and approval for sharing before sending.
Risk to consider: A local editor window does not make a remote model request local. A local server address is not proof of its downstream behavior.

Hosted processing

Authority: A remote service receives the submitted input and performs its own work.
Check before acting: Confirm the service, account access, paid access when required, and the actual input before starting.
Risk to consider: A successful sign-in does not grant paid Zilch extraction. Formatting text locally does not perform extraction.

Select a boundary to see what it allows, what needs review and what a reassuring label can hide. The guide is educational and printable. It does not scan your device, change permissions or certify a secure setup.

A local file can be in a synced folder. A shell command can use the network. An editor can be local while its chosen model is remote. A signed-in account can still lack access to a separately paid service. Review those facts independently rather than treating shared branding as one permission.

Write the task intent separately

# Task brief

## Goal

Describe one outcome.

## Scope

List the files or subsystem to inspect.

## Existing work

State which changes must be preserved.

## Acceptance

Name the relevant test or observable result.

## Approval boundary

List actions that need a separate decision.

Use the brief to state the outcome and approval decisions. Then inspect actual tool access, operating-system permissions and request destinations. A prompt saying “read only” does not remove write access. An instruction found in a source file does not authorize an upload or a provider change.

For a review, print all boundaries and mark which ones the task actually crosses. Keep private paths and credentials off the shared copy.