Skip to lesson
Exit
AI & Agent Security Threat Model1 / 2

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.

Allowlist / denylist with per-tool gating
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 isolated agent execution mode that contains the blast radius: file access scoped to the workspace, network off by default and git restricted to read-only, enforceable org-wide. Press Enter for the full definition. gives command execution the constrained environment the tool-use section called for, as a product default.

Network off by default

No outbound egress unless explicitly granted, so a hijacked command can't phone home.

This is exfil starvation applied to the shell.

Git read-only

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.

Org-enforced

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

Three-layer egress: allowlist, denylist, default-deny

Three-layer egress: allowlist, denylist, default-denyDNS filtering plus an HTTP proxy enforce it

When the agent does need network access, egress is controlled in three layers with two enforcement points underneath.

THREE-LAYER EGRESS CONTROL

Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.

diagram: stack

Allowlist and denylist resolve first; everything else needs a human yes, enforced at DNS and the proxy.

This is the tool-layer egress bound from the exfiltration section, made concrete. A markdown image or a hijacked curl aimed at attacker.example matches neither list, so it stops at the default-deny layer and waits on a person, with DNS filtering and the built-in HTTP proxy as the two places that make it stick. Fail-closed is the property that matters: nothing routes by omission - an unmatched host needs a human yes.

Say it like this

"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 isolated agent execution mode that contains the blast radius: file access scoped to the workspace, network off by default and git restricted to read-only, enforceable org-wide. Press Enter for the full definition. with network off and git read-only, enforced org-wide; and three-layer egress - allowlist, denylist, default-deny - backed by DNS filtering and an HTTP proxy, so an unmatched host needs a human yes before anything routes."

Interview move

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 isolated agent execution mode that contains the blast radius: file access scoped to the workspace, network off by default and git restricted to read-only, enforceable org-wide. Press Enter for the full definition. is exfil starvation plus a destructive-action gate; three-layer egress 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?