What It Can Touch

An agent acts through a short list of tools: read, search, write, run a command, fetch from the network. The list looks modest until you notice that "run a command" means anything your account can do from a shell. Pushing to the shared repository, installing a package and querying a database are all one command each.

Permissions, the subject of Chapter 3, decide which of these happen without asking you. This page is the inventory those rules are written against: what each tool can reach, and what undo exists if it reaches the wrong thing.

The Standard Tools

As of 2026 most agents ship roughly the same set. They read a file. They list and search, by file name and by content. They edit an existing file or create a new one. They run a shell command. They fetch a URL or search the web. Tool servers, connected over a standard protocol, can add more, from a ticket tracker to a database client; Chapter 4 covers what each of those lets into the session.

In a transcript the tools look small and alike: one line each, a verb and a target. That flattening is the trap. "read refunds" and "read the environment file" are the same size on screen and very different in consequence, and "run the test runner" and "run a migration" are both just "run". The table below sorts them by what they actually reach.

Search deserves a note of its own. It returns a list of matches, and the agent then decides which of them to read. A search for the refund rule can match four files and the agent can read one, which is how a change ends up consistent with one copy of a rule and blind to another. The search tool reaches every file; the agent's attention reaches the ones it chose.

Reading Is Not Harmless

Everything the agent reads goes into its context. Unless the model runs on your own machine, the context travels to the provider that runs the model with every request. A read of the environment file puts the database password into that request, alongside your question about refunds. Nothing about the read looks dangerous in the transcript: one line, a file name, a line count.

So which files may be read is a decision, not a default. Chapter 12 makes it in detail; the short version is that anything holding a secret should be unreadable by the agent's process, not merely unmentioned in your request.

The same applies to what commands print. A test that fails while connecting to a database can print the connection string, password included, and that output joins the context exactly as a file read would. So can a log file, a configuration dump or a stack trace from a service that echoes its settings. The agent did not go looking for the secret; it read output that contained one.

Writes in the Repository Are Recoverable

Inside the repository, an edit is cheap to undo, on one condition: you started from a clean working tree and a commit. Then every change since that commit is the agent's, and one or two git commands put the tree back exactly as it was. Chapter 3 sets up that starting point and Chapter 9 makes the commit before every request a habit.

Outside the repository there is no such undo. An agent that tidies your shell configuration, rewrites a global settings file for the package manager or edits a file on a shared drive has changed something no commit recorded. Its edit tool can reach those files as easily as refunds, because the tool's reach is your account's reach.

Deletions follow the same rule. A file the agent deletes inside the repository comes back from the last commit. A file it deletes elsewhere, or a file inside the repository that was never staged or committed, is gone, which is one more reason to start every session from a tree with nothing uncommitted in it.

The Shell Is Everything Else

The shell tool runs the test runner, git, the package manager, a database client and anything else installed. On a Cragmoor laptop that includes pushing to the shared repository, installing a new package from the public registry and, because the staging configuration sits in the repository, running commands against the staging database. The danger is not the tool. It is what the environment lets a command reach.

Running the tests is the case people underestimate. The test runner executes code in the repository, and the agent can edit that code. A test file can contain anything a program can do: open a network connection, delete a directory, read a credentials file. Permission to run the test runner is, in effect, permission to run whatever the agent wrote, and Chapter 3 decides where that is acceptable.

The fetch tool reaches in the other direction. It brings text from outside into the context: a documentation page, an issue in a public tracker, a dependency's README. That text sits next to your instructions with nothing to mark it as less trustworthy, and if it contains a sentence telling the reader to run an install script or send a file somewhere, the agent may treat it as part of its task. Chapter 12 covers that attack; here it is enough that "fetch" is not a read-only tool in any sense that matters.

Asking and Not Asking

Each tool call either runs at once or is shown to you for approval first. By default, reads usually run and commands usually ask. Edits vary: some tools ask before each one, others apply edits inside the project at once and let you keep or undo them afterwards. The rules that change those defaults, allowing the test runner without a prompt or refusing a push outright, are the permissions of Chapter 3.

Approval is only as good as your reading of what you approve. The first prompt of a session gets a careful look. By the fortieth, the yes tends to come before the reading, and a rubber stamp is worse than no prompt at all because it looks like control. That is the reason to keep prompts rare enough to read, and to make sure the worst command cannot reach anything that matters even if you approve it by reflex.

Many tools also offer a third answer to a prompt, roughly "yes, and don't ask again". It is convenient, and it quietly turns one approval into a standing rule for every future command of that shape, in this session or beyond it. An approval given at the fortieth prompt, to get a test run going, can outlive the session as permission for a whole family of commands nobody chose deliberately. Read what a standing rule covers before you create one.