I've been using Cursor with tools enabled much more lately, and the speed is great. What makes me nervous is that sometimes the only thing stopping a command like "delete this" from running is me watching the terminal.
Are people using stronger protections than prompts and careful supervision? Do you keep agents completely away from production and cloud accounts, or have you found a reliable way to give them useful access without letting them perform destructive actions? I'm especially curious about staging environments and whether anyone has had a close call.
4 Answers
A practical workflow is to let the agent modify code but make a human handle all merges and deployments. Every change goes through a pull request and automated static or security checks before it can move between environments. For larger teams, event logging and a small monitoring service can record every tool invocation so you can review exactly what happened during a session.
I stopped relying on terminal supervision by putting an execution-control layer in front of the agent. It blocks commands and paths that should never run, asks for approval for sensitive operations, and can compare the requested command with the task’s intended scope. That provides protection at execution time instead of hoping the model follows a system prompt.
For cloud APIs, make sure the controls cover API calls too. A container sandbox may restrict local code execution while still allowing an agent with credentials to delete a cloud resource or force-push through an external tool.
Use several layers instead of relying on instructions in the prompt. Run the agent in a sandbox or under a restricted service account, keep production credentials out of its environment, and require approval for destructive actions. A shell wrapper or pre-tool hook can deny commands such as recursive deletion, infrastructure destruction, force pushes, or mutating cluster operations before they execute.
A useful pattern is an allowlist for commands rather than only a denylist. For example, a restricted account might allow kubectl get, describe, and logs while rejecting every mutating command and telling the agent to open a change for a human to review.
The safest setup is a normal development-to-staging-to-production pipeline. Let the agent work in development or staging, require thorough tests and review before promotion, and keep production access separate. In production, an agent can handle read-only investigation or triage, but deployments and mutations should stay manual.
That makes sense for production. I’m mostly trying to solve the staging problem, since giving the agent more access there still feels like one bad command away from deleting something important.
That kind of monitoring is useful, but it’s mainly an audit trail unless it sits directly between the agent and the tools. Preventive hooks, scoped IAM permissions, and approval gates are what stop the dangerous action in the first place.