Enterprise
Cursor Enterprise: LLM Safety & Controls
You can't rely on an LLM to always make safe decisions. Cursor splits agent safety into two layers: deterministic security controls that block dangerous operations regardless of what the model suggests (run modes, enforcement hooks, .cursorignore, sandboxing) and non-deterministic steering that guides the model toward better behavior (rules, commands, MCP). Use both - controls are the safety net, steering reduces how often agents reach for trouble.
On this page
Why can't you just trust the model to behave?
LLMs generate text from probability distributions, not by retrieving facts or running deterministic logic. The same input can produce different outputs, the model can hallucinate plausible-but-wrong code, and a crafted prompt can steer it (prompt injection). So you don't trust the model to police itself. You wrap it in two layers that work together.
- Security controls
- Deterministic enforcement. Hard boundaries that block dangerous operations whatever the LLM suggests - terminal restrictions, hooks, approval workflows, sandboxing. Your primary defense.
- LLM steering
- Non-deterministic guidance. Shapes the model's context and available actions - rules, commands, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.. Improves quality but does not guarantee prevention.
Security controls are the safety net; steering reduces how often agents attempt problematic actions in the first place. Steering alone is not a security boundary - rules are suggestions the model will try to follow, not guarantees.
What deterministic controls block dangerous agent actions?
These controls enforce hard boundaries and work regardless of what the model proposes. By default Cursor requires your approval before running any terminal command, so you see the full command and can approve, deny or modify it before it runs.
- Control
- Run modes
- What it enforces
- In Cursor 3.6+, end users pick Auto-review (default), Allowlist or Run Everything. Auto-review runs allowlisted calls, sandboxes shell commands when it can, and routes the rest through an LLM classifier that returns allow or block.
- Control
- Enforcement hooks
- What it enforces
- Custom logic at points in the agent loop: before prompt submission, before file reading, after code generation and before terminal execution - to scan, redact or block.
- Control
- .cursorignore
- What it enforces
- Excludes files from semantic search, agent file reading and context selection - like .gitignore, but for what Cursor can access.
- Control
- .cursor directory protection
- What it enforces
- Enterprise teams can stop agents from modifying or deleting the .cursor/ directory and its rules and settings.
- Control
- Browser origin controls
- What it enforces
- Enterprise teams allowlist which websites the browser tool may navigate to; other origins are blocked.
- Control
- Sandboxing
- What it enforces
- Stronger isolation via Cloud Agents (a separate VM), file system permissions, or a dedicated dev machine.
| Control | What it enforces |
|---|---|
| Run modes | In Cursor 3.6+, end users pick Auto-review (default), Allowlist or Run Everything. Auto-review runs allowlisted calls, sandboxes shell commands when it can, and routes the rest through an LLM classifier that returns allow or block. |
| Enforcement hooks | Custom logic at points in the agent loop: before prompt submission, before file reading, after code generation and before terminal execution - to scan, redact or block. |
| .cursorignore | Excludes files from semantic search, agent file reading and context selection - like .gitignore, but for what Cursor can access. |
| .cursor directory protection | Enterprise teams can stop agents from modifying or deleting the .cursor/ directory and its rules and settings. |
| Browser origin controls | Enterprise teams allowlist which websites the browser tool may navigate to; other origins are blocked. |
| Sandboxing | Stronger isolation via Cloud Agents (a separate VM), file system permissions, or a dedicated dev machine. |
Configure .cursor directory protection and browser controls in the team dashboard (Enterprise only).
The run-mode allowlist is best-effort. A determined agent or prompt injection might bypass it, so always pair it with hooks. .cursorignore is a convenience feature, not a boundary: users can still open ignored files manually and it only excludes from indexing. For true protection, use file system permissions or encrypt the data.
Cursor agents run on your local machine by default and can read, write, execute and reach the network exactly as your user account can. If your account can delete files, the agent can too (with approval by default). Enabling auto-approval removes the review step - destructive commands or prompt injection could run before you see them.
How do hooks enforce policy and connect DLP tools?
Hooks run your own logic at key points in the agent loop and can return a deny decision. That makes them the place to enforce requirements the model must follow - blocking raw git commands, requiring approval for sudo, blocking database DROP statements, or scanning prompts and generated code for secrets before they leave or land on disk.
- Before prompt submission: scan prompts for API keys, credentials or PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive. and block submissions that contain them.
- Before file reading: redact or block access to config files with secrets, PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive. in logs, or proprietary algorithms.
- After code generation: scan generated code for vulnerabilities (SQL injection, XSS), risky licensed code, or hardcoded credentials before it is written.
- Before terminal execution: block dangerous commands or route them through an approval workflow.
For Data Loss Prevention, Cursor documents three integration paths. Endpoint DLP agents inspect Cursor's network traffic - point your DLP at the *.cursor.sh domains to scan or block outbound requests. Hooks-based DLP runs custom scanning in the agent loop. Third-party DLP integration calls your existing vendor's API from a hook so one policy covers every development tool.
You can make the agent ask before every read, edit, command or network request. In practice this is tedious because agents take many steps per task, so most teams use hooks to block dangerous operations automatically instead.
Do the model providers' own safety systems protect us?
Every provider (OpenAI, Anthropic, Google, xAI) runs safety systems that reject harmful prompts, refuse dangerous code and filter outputs. Cursor works with providers so models meet safety standards before they reach users, and providers keep evaluating models for issues.
These systems can be bypassed or tricked. Treat them as one more layer, not the wall - always implement your own controls through hooks and access policies.
How does steering guide the model toward better behavior?
Security controls block harmful actions after the model suggests them. Steering shapes the suggestions in the first place. It is non-deterministic - it improves outcomes but doesn't guarantee prevention - so pair anything that must hold with an enforcement hook.
- Rules
- Instructions added to the model's context before every request. Scoped as user, project or team rules - use team rules for company-wide security or compliance standards. The model tries to follow them; they are not guarantees.
- Commands & workflows
- Reusable prompts invoked with slash commands like /test or /deploy. A /security-review command can walk the agent through scanning for SQL injection, exposed secrets and input sanitization. Team admins create org-wide commands.
- MCP servers
- Model Context Protocol servers give agents access to external data - docs, internal APIs, knowledge bases. MCPs enrich context but do not enforce policy; unlike hooks, they inform rather than block.
Frequently asked questions
Is .cursorignore a security boundary?
No. It excludes files from semantic search, agent file reading and context selection, but users can still open ignored files manually and it only affects indexing. For real protection use file system permissions or encrypt the data, and add hooks to scan or block access.
Are Cursor agents sandboxed from my machine?
Not by default. Agents run locally with the same access as your user account - they can read, write, execute and reach the network as you can. For stronger isolation, run Cursor in a separate VM via Cloud Agents, restrict the process with file system permissions, or use a dedicated development machine.
Can rules force the model to follow our security standards?
Rules steer the model but don't guarantee compliance - they are instructions it attempts to follow. For requirements that must hold, combine team rules with enforcement hooks that deterministically block the disallowed operation.
Sources & last verified
- Cursor - LLM Safety & Controls
- Cursor - Hooks
- Cursor - Run Modes
- Cursor - Agent Security
- Cursor - Ignore Files
- Cursor - Rules
- Cursor - MCP
Cursor ships frequently. Facts verified against primary sources on June 25, 2026.