Read-Only Is Not the Same as Safe

An agent cannot edit the repository. It can still read a log containing customer information and include it in a remote request or a published explanation, if its tools and data path allow that.

Nothing in that hypothetical example requires a file write.

I like read-only modes. They are useful restrictions, especially for review and investigation. I don't like treating the label as a complete security argument.

Integrity and confidentiality are different properties. Preventing a change to local files doesn't, by itself, establish who can see their contents or where those contents can travel.

Start with the data path, not the mode name

For an agent-assisted task, I would identify what can be read, which process or service receives it, and where outputs can appear.

That includes the model provider, local and remote tools, logs, review comments and any connected workspace. A tool named search may run locally or call a remote index. A browser may already be authenticated to services the task doesn't need.

The answer depends on the actual product, integration, account and organization policy. I wouldn't infer retention, training use, residency or access controls from the word enterprise or from a familiar brand name.

GitHub's current application card distinguishes data flows across its agent surfaces and explicitly discusses responsibility for a bring-your-own-provider configuration. That is a reason to inspect the selected path, not to assume every Copilot session sends data through the same route.

Read-only should be one property in that description. It shouldn't replace the description.

Source code isn't the only sensitive input

A repository can contain private fixtures, copied production responses or internal endpoint information. Development machines can also hold browser profiles, credential files and local service configuration outside the checkout.

I would avoid collecting all of that merely because a tool is capable of reading it. The task should establish a need for particular information, and the environment should enforce meaningful limits where possible.

The right question isn't whether the agent is generally trustworthy. It is whether this task requires this class of data under the approved handling rules.

For many investigations, a sanitized schema or a small synthetic fixture can answer the technical question. If real data is necessary, its use needs the appropriate authorization and controls. Replacing names in one field doesn't automatically anonymize an entire payload.

I would not ask someone to paste secrets into a chat so the agent can diagnose an authentication problem. A person can configure a credential through the intended secure mechanism without turning its value into task content.

File access and network access are separate boundaries

A process may have restricted writes and broad reads. It may also have an outbound network path. Those properties need to be examined together.

The VS Code security guide, checked on October 23, 2026, explicitly separates sandbox behavior, permission checks and network configuration. It notes that outbound network access can remain enabled under its documented defaults and that tool paths and harnesses differ.

I am deliberately not presenting a generic setting that supposedly secures every session. A shell command, a built-in file tool and a remote MCP tool can pass through different controls.

Restricting a local process doesn't necessarily restrict a connected remote service. Blocking an arbitrary external host doesn't prevent disclosure to an allowed service that should not receive a particular payload.

Likewise, an allowed destination isn't permission to send every accessible file there. Access to a provider for legitimate inference still requires appropriate selection of the context supplied.

A permitted route and a permitted payload are different decisions.

This is where a read-only label becomes particularly incomplete. It says little about either one unless the product defines those properties explicitly.

The agent can follow the task and still expose too much

Prompt injection is one route to an undesirable action, but it is not required for every disclosure.

An agent honestly trying to explain a failing test may quote an entire response body when a status code and a sanitized field name would suffice. A reviewer may include a sensitive configuration value in an otherwise useful comment.

I would want output handling to consider necessity and destination, not only whether the conclusion is correct.

This also matters for task records. Preserving evidence does not require keeping raw credentials, complete private payloads or every retrieved document. Logs that improve observability can create another data store with its own access and retention obligations.

A link or bounded summary may be more appropriate than a copy. Sometimes neither is appropriate in the destination where the agent is about to write.

Read-only access to the source doesn't prevent a different tool from publishing the resulting text. The review of that publication path needs to consider what it contains.

Approval needs enough information to be meaningful

A request for permission to call a tool should identify the operation and relevant destination without displaying secrets in the prompt itself.

A person approving a broad capability for convenience may not be approving every later use of sensitive content. Long-lived approvals, inherited authentication and ambiguous tool descriptions can widen the practical boundary beyond the user's immediate intention.

I would prefer task-scoped access with an understandable lifetime. Where a product supports separate permissions for reading, processing and publishing, those should reflect the task rather than share one blanket decision by default.

That doesn't mean asking a person about every ordinary file. Approval fatigue can make a nominal checkpoint less useful. Enforced restrictions and clearly defined safe paths can reduce unnecessary prompts while preserving meaningful decisions.

The existing guardrails article concerns control over agent behavior. Here the question is narrower: which data may cross which boundary, even during behavior that appears routine.

Test the boundary without using real secrets

For an authorized evaluation, I would use disposable files containing unique, harmless markers rather than actual credentials or customer records. Then check which reads, requests, logs and outputs contain those markers.

The setup should use a controlled environment and destinations approved for the test. The purpose is to observe the data path, not to try bypassing organization controls.

A successful fixture establishes something about the observed tools and configuration. It doesn't prove every model decision will minimize data or that every future integration inherits the same restrictions.

Denied operations deserve testing too. A tool should not silently retry through a more privileged route simply because its first attempt was blocked. An unavailable source should remain unavailable in the report, not become a reason to weaken the boundary.

I would also test what survives after the session: retained outputs, cached tool responses and published artifacts. Stopping the agent is not necessarily the same as removing information already sent or stored.

Keep read-only useful by describing what it protects

I don't want to discard a useful mode because it doesn't solve every problem. Preventing mutation can substantially reduce the risk of an investigation or review task.

I want the claim to remain specific: which writes are prevented, which reads remain possible, what network paths exist and which publication actions are available.

Once those are explicit, the team can decide whether the environment is appropriate for the data involved. Without them, safe becomes a feeling attached to a mode selector.

A read-only agent may be exactly the right tool. I would still ask what it can learn, who receives that knowledge and what remains after the task finishes.

When you approve read-only agent access, which data boundary do you verify separately? I'd be interested in the practical checks that made the mode's actual guarantees clear.