1 min lesson
Model & MCP allowlist: per-tool auto-run vs manual approval
Name the parts in "Model & MCP allowlist: per-tool auto-run vs manual approval" and give the practical job of each one.
Step 1 of 2
Model & MCP allowlist: per-tool auto-run vs manual approvaldefault-deny applied to models and servers
The same default-deny capability thinking from the tool-use section applies to which models and which MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers the org permits. An admin sets an allowlist and a denylist and, crucially, decides per tool whether it auto-runs or waits for manual approval. That second axis is what lets you keep a useful server connected without trusting it to act unattended.
- Internal CI MCP
- Allowlisted; its read-only tools auto-run, its deploy tool stays manual-approval.
- Third-party server that can post to prod
- Blocked by default. It sits on the denylist until reviewed, pinned and scoped.
- Unapproved model
- Denied; Cursor won't send requests to a blocked model, so code never reaches it.
Auto-run is reserved for vetted, low-blast-radius tools; anything that can change prod stays gated or blocked.
Map this back to the trifecta: a server you don't control is an exit channel, so default-deny keeps it off until someone vets it. The allowlist isn't a static wall; it's per-tool privilege separation.
Learn more
Full explanation
Sandbox Mode: network off, git read-only, org-enforced
Sandbox Mode: network off, git read-only, org-enforcedthe agent runs with no ambient reach by default
Sandbox ModeAn agent execution mode in which terminal commands run in a restricted environment that blocks unauthorized file access and network activity, with network limited to the sandbox allowlist; admins enable it org-wide through the Run Mode policy. Press Enter for the full definition. gives command execution the constrained environment the tool-use section called for, as a product default.
No outbound egress unless explicitly granted, so a hijacked command can't phone home.
This is exfil starvation applied to the shell.
The agent reads history but can't rewrite, force-push or alter remotes.
Destructive git stays behind a gate, not in the agent's standing reach.
Admins enforce the sandbox so a user can't opt out of the protection.
Same enforcement model as Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. and MDM hooks.
Learn more
Full explanation
Network egress: one team allowlist, fail-closed
Network egress: one team allowlist, fail-closeddocumented today, with a three-layer policy announced on top
When the agent does need network access, start with what the docs describe today. The sandbox blocks unauthorized network activity, and one admin-managed team allowlist drives both the sandbox's default network allowlist and Cloud Agent egress, where admins choose Default + allowlist or Allowlist only. Cursor has also announced a three-layer egress policy, shown below as a design to plan around.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Cursor's announced network-control design: allowlist and denylist resolve first, and everything unmatched needs a human yes.
This is the tool-layer egress bound from the exfiltration section, made concrete. A hijacked curl aimed at attacker.example isn't on the team allowlist, so under Allowlist only it never routes. Fail-closed is the property that matters: nothing routes by omission. The docs make the same point about wildcards, warning that a whole-region cloud-storage entry in place of one exact host opens an exfiltration path for a prompt-injected agent.
"I'd enforce the threat model with real controls: MDM hooks that outrank user config to audit prompts, policy-check file reads and allowlist shell commands; a model and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. allowlist where vetted read-only tools auto-run but anything that can touch prod stays manual or blocked; Sandbox ModeAn agent execution mode in which terminal commands run in a restricted environment that blocks unauthorized file access and network activity, with network limited to the sandbox allowlist; admins enable it org-wide through the Run Mode policy. Press Enter for the full definition. with network off and git read-only, enforced org-wide; and egress on the team allowlist in Allowlist only mode, with exact hosts and no wildcards, so an unmatched host fails closed. Cursor has announced a three-layer egress policy on top of that, and I'd adopt it once it's documented."
Tie each control back to the principle it enforces. Hooks are deterministic code at the loop's checkpoints; the allowlist is default-deny privilege separation per tool; Sandbox ModeAn agent execution mode in which terminal commands run in a restricted environment that blocks unauthorized file access and network activity, with network limited to the sandbox allowlist; admins enable it org-wide through the Run Mode policy. Press Enter for the full definition. is exfil starvation plus a destructive-action gate; the egress allowlist is the fail-closed exit-channel control. Naming the mechanism and the principle together is what separates a senior answer from a feature recital.
QAn admin wants the org's shell-command allowlist to survive a developer who edits their own Cursor config to disable it. Which control gives that guarantee, and where in the agent loop does it fire?