Browser protection deserves a separate conversation. By default every browser tool requires approval, not only the actions that may have external consequences - and that is not a formality. The reason lies in how the tool is built: the agent reads the page and acts on it through the same mechanism, so the boundary between data and command runs inside a single call. Even in a trusted application, text on a page can try to redirect the agent: an injection through content looks like an ordinary instruction and arrives from a place you do not expect. Before submitting a form or publishing, it pays to check three things: where the action goes, what exactly is being sent and on whose behalf.

Web search calls for the same wariness but for a different reason. It is useful where current documentation or release notes are needed, and harmful when its result is taken as an instruction. Page content is data, not a command; treating it otherwise opens the cheapest channel of influence over the agent's behavior. The marker of a substitution is visible to the eye: the found text starts addressing a performer - do this, run that, open the other - whereas documentation usually describes a system's behavior rather than handing out orders to its reader.

A chain of tools is more dangerous than any single one. The typical scenario looks harmless: the agent looks for the reason a build fails, finds a page discussing a similar error, reads a command there and offers to run it in the terminal. Each step on its own is reasonable, and the outcome is someone else's command executed in an environment that holds keys and repository access. Such a chain is broken only at the boundary between tools: the found text stays a reference, and the decision to execute belongs to a human who sees the whole command rather than a retelling of it.

The main idea fits in one sentence: permissions are not inherited from intent. Telling the agent just look is not the same as forbidding it to change files. Wording sets a direction but is not a technical limit; the limit is set by the run mode, the sandbox, the list of allowed commands, network rules and tool approvals. The check is simple: if lifting a prohibition takes no more than rewriting one phrase in the request, then there is no prohibition, only a wish.

Hence the practical order: first choose the tool for the task, then limit it for the specific scenario, and only then formulate the request. The reverse order - write a nice instruction and hope the agent stays inside it - works right up to the first time page content, command output or an external server's reply suggests something else. The order matters for another reason too: a limit put in place along the way does not undo an action that has already run.

In real work, permissions that are too wide announce themselves through indirect signs, and it pays to know them in advance. The diff touches files the task never mentioned. A network call nobody ordered shows up in the output. The agent reports an action it has taken instead of asking permission for it. The browser ends up on a page where you are signed in, although the task concerned local layout. None of those signs points to a failure of the model: the tool did exactly what it was allowed to do, and the question is who allowed it and when.

The typical failures are predictable. Believing that a phrase in the request limits permissions. Handing terminal output with secrets into the context. Allowing the browser to act on an authenticated page in a mixed-trust task. Taking the text of a found page for an instruction rather than for data. And granting rights once for the whole session without noticing that the task has changed since.