How to Tell an AI Coding Agent What Not to Touch

Give the agent one named task, only the context it needs and a check you can rerun. A task shaped this way produces a diff small enough to review and a result you can repeat.

Each move fails in its own way. Without a boundary, the agent edits files you never meant to open, and the diff becomes hard to read. Thin context fails more quietly: the code compiles and the tests pass, but the change ignores patterns the rest of the repo follows. Without a check you can rerun, you are taking the agent's word that the work is done.

Asking for a plan before the agent writes code is the easiest step to skip. It means a short wait while nothing visible happens, and the price of skipping it shows up later, in review.

If the plan names files you didn't expect, you learn that before any code exists. If it names the right files, you have a list to check the diff against. Once four hundred lines of diff are on screen, changing the approach means throwing that work away.

The habit that matters most for a team is leaving a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Match the effort to the change. A one-file fix needs a clear done state and a typecheck, and a plan adds little. A change across several files is where a plan pays for itself, and where the check should include tests and a reviewer who knows that code.

Keep whatever lets someone rerun the work or pick it up later. A finished task is the merged code plus a short trail that shows how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

The last item pays off over time. A rule or template saved from one good run means the next run starts from what already worked, not from a blank prompt.

Use all three, in that order, and stop as soon as the boundary holds. A non-goal in the prompt covers one task, and a rule covers a convention. A hook covers what must not happen even when the model has talked itself into a good reason.

The rule layer is an .mdc file under .cursor/rules/ with a glob in its frontmatter. A rule scoped to **/*.tsx with alwaysApply: false is attached only when a matching file is in context. That makes file-scoped boundaries cheap enough to keep several of them.

Enforcement is what separates the third layer from the first two. Rules are instructions the model tries to follow, so they shift the odds without setting a floor. A hook is a script you write and check into the repo. It runs at fixed points in the agent loop, including before a file read and before a shell command, and your code returns allow or deny, whatever the model decided.

Put anything load-bearing in a hook, and set failClosed: true on it. By default, a hook that crashes or times out lets the action through.

Escalate when you catch yourself repeating a boundary. The second time you type the same non-goal into a prompt, turn it into a rule. When you watch the agent walk past a rule, turn that rule into a hook.

Not reliably. .cursorignore keeps files out of agent file reading and context selection, which is useful. Cursor's docs call it a convenience feature, not a security boundary. Users can still open an ignored file by hand, and terminal commands and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. tools can still read it.

The risk is a false belief. You add a path, watch it disappear from context, and treat that part of the tree as fenced off. Then an agent with shell access reads the file through a command, because the shell does not know the editor was told to look away.

For anything that must not be read, Cursor's documented answer is file system permissions or encryption, with a hook on top to scan or block access. Keep .cursorignore for what it does well: keeping secrets and noise out of the context you pay for.

Every other instruction gets slightly worse. A rule that carries one instruction plus three hundred others spreads the model's attention across all of them, and that attention is finite.

When Cursor's field engineers explain output quality, they put model choice ahead of context, at something like 60/40 to 70/30. Context is still the share you control, so filling it with prohibitions that have nothing to do with today's task is a poor trade. A presenter in Cursor's JetBrains workshop said Cursor's own rules run about eight lines.

So add a boundary when you catch the agent crossing it, instead of listing everything it could conceivably do. Leave style rules to the linter, because deterministic tooling enforces deterministic rules better than a paragraph of English.

Team size changes who owns the list. On a small team, two or three scoped rules plus a line in the prompt match the risk. In a larger organization, the boundaries that matter ship as enterprise hooks through MDM. Every matching hook runs and a deny from any of them wins, so a developer's own hooks can't override that block. Rules and hooks can also ship as plugins in a team marketplace that admins limit to selected Organization Groups, so the design team doesn't load the security team's prohibitions.