1 min lesson
Match controls to the agent's reach
Put this idea into your own words. "Agent surfaces do not all carry the same risk."
Step 1 of 2
Agent surfaces do not all carry the same risk.
Inline completion, an interactive IDE agent and a cloud agent differ in how far they can act without a person. Review the human checkpoint, systems access and execution environment for each surface.
Interactive diagram. Step through it with the Next and Previous controls below, or Tab to a region to read its detail.
More reach and less immediate review require tighter permissions, stronger isolation and a clear handoff to a person.
Learn more
Advanced table
Reference table
- Level
- 1
- Surface
- Tab / inline completion
- Human in loop?
- Every keystroke
- Matched guardrails
- Repository rules and normal code review
- Level
- 2
- Surface
- IDE agent with Ask or Plan
- Human in loop?
- Reviews plan before acting
- Matched guardrails
- Repository rules, read-only context and plan review before execution
- Level
- 3
- Surface
- Interactive CLI or a headless CI run
- Human in loop?
- A person drives locally or required checks review the result
- Matched guardrails
- Local Run Mode, sandboxing and hooks. CI also needs scoped credentials and required checks.
- Level
- 4
- Surface
- Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. in isolated VMs
- Human in loop?
- Asynchronous work across one or more repositories
- Matched guardrails
- Dedicated VM, scoped credentials, restricted egress, approved 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 and pull request review
- Level
- 5
- Surface
- SDK or other fully headless workflow
- Human in loop?
- No person reviews each action as it runs
- Matched guardrails
- Deny by default, narrow tools and egress, complete logs and mandatory review before merge
| Level | Surface | Human in loop? | Matched guardrails |
|---|---|---|---|
| 1 | Tab / inline completion | Every keystroke | Repository rules and normal code review |
| 2 | IDE agent with Ask or Plan | Reviews plan before acting | Repository rules, read-only context and plan review before execution |
| 3 | Interactive CLI or a headless CI run | A person drives locally or required checks review the result | Local Run Mode, sandboxing and hooks. CI also needs scoped credentials and required checks. |
| 4 | Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. in isolated VMs | Asynchronous work across one or more repositories | Dedicated VM, scoped credentials, restricted egress, approved 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 and pull request review |
| 5 | SDK or other fully headless workflow | No person reviews each action as it runs | Deny by default, narrow tools and egress, complete logs and mandatory review before merge |
Read each row from the agent surface to the human checkpoint and required controls.
An interactive user can stop an unsafe action before it runs. A headless workflow cannot. As direct review decreases, restrict credentials and network access, isolate execution and require review before changes merge.
Cloud Agent environments come from guided setup, a reusable snapshot or a repo-level .cursor/environment.json. Outbound access can be Default plus an allowlist, or Allowlist-only.
I would compare what the agent can reach, what it can change and when a person reviews the work. If the workflow removes an approval step or adds repository access, I would tighten permissions, isolation and merge requirements before using it.
Learn more
Optional practice
Test yourself on Match controls to the agent's reach
QA team moves from an IDE plan reviewed by a person to asynchronous Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. working across repositories. What must change?
QA nightly SDK job triages new issues and no one is watching it run. Which setup fits that surface?