I've been using Cursor with tool access much more lately, and the speedup is great. What makes me uneasy is that destructive actions can be only one command away—sometimes the main safeguard is me watching the terminal closely.
How are you handling this in practice? Do you keep agents completely away from cloud and production systems, or have you added stronger controls for development and staging too? I'm especially interested in command filtering, sandboxes, permission scoping, approval gates, API proxies, and whether anyone has had a close call. Prompts alone don't feel like enough of a safety mechanism.
5 Answers
One simple workflow is to make the agent prepare changes but never merge or deploy them. All modifications go through a pull request, and a human handles merges and deployments in every environment. It adds a manual step, but it creates a clear approval boundary without relying entirely on instructions in the prompt.
Prompts are not a reliable safety boundary. Put controls where commands and tools actually execute: run the agent as a restricted user, remove production credentials from its environment, deny dangerous commands and paths, and require approval for mutating operations. A wrapper can allow harmless commands like kubectl get, describe, and logs while rejecting anything that changes state and directing the agent to open a pull request instead.
The safest baseline is a normal dev-to-staging-to-production workflow. Let the agent work in a disposable environment, promote changes only after thorough testing, and keep production access separate. In production, AI should generally be limited to read-only investigation and triage.
That makes sense for production. I’m still trying to work out how much access is reasonable in staging, since a careless delete there could still cause real damage.
For larger setups, combine pre-execution hooks with audit logging. Hooks can block specific commands or require confirmation for sensitive ones, while a small monitoring service records the tools and events used during each session. Permission scoping, IAM, sandboxes, and approval gates work best together rather than relying on one gateway or system prompt.
A sandbox or container can restrict the files, processes, and credentials available during code execution. It’s useful, but it doesn’t automatically protect you from external API calls such as deleting cloud resources or force-pushing to a repository, so those need separate controls.
A command-level deny list is especially useful for obvious hazards like recursive deletion or infrastructure destruction. It isn’t a replacement for least privilege, but it can prevent a single bad command even if the agent decides to run it.