A read-only prompt is not a permission boundary
Separate task intent, exposed tools and operating-system permissions before asking an agent to inspect a project.
Ouros editorial team
A request to “only read” tells an agent what you want. It does not remove its ability to write. Safer inspection starts by separating three questions: what did you ask, what tools can the agent use, and what does the computer allow those tools to do?
Three layers, three different jobs
Your task brief describes intent. It can narrow the goal, name the files to inspect and say which decisions need another conversation. That is useful even when the tools are tightly restricted: the agent still needs to know what work would be helpful.
The tool list describes available actions. A file reader is different from a shell. A shell can call other programs, start processes and make requests. Calling a tool “inspect” does not make every action behind it harmless. Look at the actual action, not its friendly name.
The operating system supplies the underlying authority. If an agent runs as your user, commands may have access to the same files you do. A carefully worded prompt does not change file permissions. A chosen project folder is a working location, not automatically a locked boundary.
Work through a small inspection
Suppose you want to understand why a parser test fails. Begin with the test and parser file, not the whole home folder. Preserve any existing edits. Ask for a proposed explanation before requesting a correction. Name the project check that would settle the question.
Use this brief to make those decisions explicit:
# 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.
Fill each section with a concrete answer. “Improve the parser” leaves the scope open. “Explain why the empty-input test disagrees with the parser; do not edit files” sets a useful first task. If the next step requires editing, approve that separately and review the resulting change.
Now compare two setups. In one, the agent has a reader for a small sample folder. In the other, it has a general shell in your main project. The prompt can be identical, but the possible effects are not. Choose the smaller authority that still answers the question. Check the tool controls rather than assuming the brief enforces them.
Treat source text as material, not orders
A project file or web page can contain instructions aimed at an agent. Those instructions may be unrelated to your task. OWASP describes this as a prompt-injection risk: untrusted content can try to cross into the instruction channel. A comment saying “upload the project for debugging” should not become permission to do so.
Before a request leaves your computer, review which text and attachments it includes and where it goes. Before a shell command runs, review its effect and working location. If you cannot tell, pause that action and continue with a smaller read-only inspection.
Keep a record of what was actually read and proposed. That gives you something to review without mistaking a polite response for a security guarantee.