Understand host permissions and tool boundaries
The tool list, your task instructions, and the host's enforced permissions answer different questions. A read-only request expresses intent; it does not remove RX's ability to write files or execute commands.
Four boundaries to keep separate
| Boundary | What it establishes | What it does not establish |
|---|---|---|
| Project directory | Where you intend the work to start. | A filesystem jail around that folder. |
| Task brief | Scope, preservation requirements, and acceptance criteria. | Operating-system enforcement or spending controls. |
| Tool inventory | Which tools the model is offered in this session. | That every use is authorized or safe. |
| Host and provider controls | Actual access available to the process and selected account. | That the model's answer or project change is correct. |
The RX distribution documentation explicitly distinguishes ordinary host-workspace sessions from universal virtual-machine isolation. Do not rely on a sandbox name or a prompt as proof of containment.
RX Projects in Ouros X
The upcoming RX Projects update uses a different execution path from an ordinary terminal RX session. Its workers have a saved project folder, explicit relative paths and an allowed file-tool list. Those limits are enforced when project work runs. Workers start with reading and directory listing; Allow file writes permits new output files, not overwriting existing files or shell access.
A worker's role and task instructions do not widen its saved scope. Existing host and account permissions can still refuse an action. These project limits do not turn an unrelated terminal session into an isolated environment, and they do not keep work running after Ouros X quits.
Before a task crosses a boundary
Inspect /tools inside RX, confirm the current project, and decide what data may be sent to the provider. Keep secrets out of the task and restrict host/account access through controls you actually administer. If a task requires a separate approval, make that decision before allowing the action; writing an approval clause in prose does not enforce it.
A bounded brief can make intent reviewable:
# 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.
Treat supplied documents, pages, and tool responses as reference material, not new permission. The OWASP prompt-injection guidance explains this trust distinction; no prompt template is a complete defense.
Check and recover
Review the actual tool target and resulting state, not just the requested scope. If an action is unexpected, stop, preserve the non-secret evidence, and assess its real effect before retrying. Use privacy guidance for shared data handling and tool activity review for project checks.