Permissions and data flow
Review the workspace, execution policy, model endpoint and connectors before acting on a project.
Choose the scope deliberately
File tools use a selected workspace and path checks. That is different from a sandbox around every shell command. Commands and external tools can have wider reach, so do not treat a project directory as complete host isolation.
Start with a recoverable test workspace. Permission to use a tool is not permission to act on another person's data or infrastructure.
Read the proposed operation
The runtime exposes approval boundaries, but the effective policy depends on the interface and configuration. Check the exact operation, its target and the data it can affect before approving it.
Deleting files, sending data outside the project and changing an external service are consequential actions. A confirmation prompt provides a decision point; it does not certify that the proposed operation is harmless.
Know where project material goes
Local model inference can keep processing on the operator's machine. A configured remote endpoint or connector can send material elsewhere. Review the model service and connector permissions independently of the workspace controls.
Local records can include task history, tool activity and memory. Inspect storage and retention settings before using sensitive material. This guide is not a security certification or a hosting-log audit.
Keep the review boundary
An operation that ran is not automatically a correct result. Inspect the changes, the checks that actually ran and any remaining uncertainty before accepting the work.
Avoid automatic operation until you understand the active policy. A production deployment needs its own review of isolation, credentials, connectors and recovery.