The situation
You began by pasting code into a chat window and pasting answers back. Then you tried the tool everyone recommends, and it opened your files by itself, changed three of them, and asked whether it could run a command you did not fully recognise. You clicked allow, because the alternative was reading it, and it worked. By Thursday you are clicking allow without reading at all.
The idea in one paragraph
The model did not get smarter when you switched tools. It got reach. A chat window can only produce text, and you decide what happens to that text. An agent is the same model wrapped in a program that can act on its behalf: open files, write to them, run commands, fetch things. Everything it now does without you is something you granted, sometimes by clicking quickly. So the useful question about an agent is never how clever it is. It is what it can touch, and what happens when it is wrong.
The permission surface
| What it reaches | Asks first | What you stop doing | If it is wrong |
|---|---|---|---|
| Files, read | No, inside the project | Choosing what it sees | A confident answer from the wrong file |
| Files, written | One asks; the other saves to disk | Reviewing before it lands | Working code replaced between two glances |
| The shell | Yes, by default in both | Running the command yourself | Whatever that command does is done |
| The network | Yes, and reach is narrow | Nothing, yet | Untrusted text gets into the session |
Only the first row can be wrong and cost you nothing but a retry.
How it actually works
The model still executes nothing. It emits a request — read this file, run this command — and the program around it decides whether that request runs, then feeds the result back into the conversation. That split is the whole story: permission lives in the program, not in the model, so a model that is confused, or that has read something written to manipulate it, still cannot exceed what the program allows.
What the program allows differs by product, and is worth reading once for the one you use. Claude Code documents read-only defaults, an explicit prompt before edits and commands, and a working-directory boundary it does not write outside without a further approval. Cursor documents agents changing workspace files without approval while terminal commands prompt, and says plainly that its run modes are best-effort guardrails rather than a hard security boundary. Both keep network reach narrow by default, because text fetched from the web can carry instructions (checked 10 August 2026).
A third shape moves the work off your machine entirely. GitHub's cloud agent runs in an ephemeral environment powered by Actions, where it explores the code, changes it and runs the tests, then hands back a pull request. Nothing it did touched your disk, and the review is the gate.
What this changes for you
- Put the project under version control before you allow the first write. Cursor's documentation gives the reason itself: changes save immediately to disk, so the undo has to exist already.
- Approve in the moment, allowlist only when calm. One approval is a decision about one command; an allowlist entry is a decision about every future one, usually made while impatient.
- Keep what you cannot undo out of reach: production credentials, the deploy command, the live database. Reach you never granted needs no review.
Where it breaks
The real failure is not a dramatic command, it is fatigue. Forty approvals in an afternoon train you to approve the forty-first without reading, and that is the one that mattered. Allowlists exist to cut the number down, which genuinely helps, and every entry is permanent while your attention is not.
Approval is also not a security boundary. It is a question about whether you understood, and often you will not: a long command doing one useful thing and one destructive thing still looks like a long command.
Refusing all reach has its own cost. An agent that can run the test and read the failure corrects itself; one that can only produce text needs you as its hands for every step. What works is a boundary small enough that you still read what crosses it.
Terms used on this page
- Agent — a model wrapped in a program that can act: open files, edit them, run commands, fetch pages. The model proposes, the program executes.
- Tool call — one such request, and the unit that permission is granted or refused on.
- Permission prompt — the product asking before an action it does not auto-approve. Answering once is not the same as allowlisting.
- Allowlist — a standing approval for a named action so it stops asking. A decision about every future case, not this one.
- Prompt injection — instructions hidden in content the model reads, written to make it act against you. The reason fetched text is treated as untrusted.
Read next
The context window — what the model actually sees while it answers, and why a session that has read half your project can still get worse instead of better.