Cursor 3 in Practice: Cloud Agents, Security, and Evaluation

Cursor 3: The Practical Answer

Cursor 3, released by Anysphere on April 2, 2026, changes the IDE from a mostly file-centered editor with an assistant into a control plane for coding agents. Its workspace can coordinate multiple local and cloud sessions, work across repositories, hand a conversation between local and remote execution, and bring the result back as a diff, commit, or pull request. The editor remains available because investigation, debugging, and precise correction still require direct work.

That is the useful answer to "what is Cursor 3?" It does not establish that autonomous agents make every developer faster, that generated changes are merge-ready, or that an isolated virtual machine removes the security risks of executing model-selected commands. Those claims must be measured against your repository, controls, and review process.

This guide therefore treats Cursor 3 as an engineering system rather than a feature list. You will learn:

• where the workspace, agent runtime, repository, and reviewer boundaries sit;
• what local-to-cloud handoff and parallel execution change operationally;
• how rules, code intelligence, browser access, plugins, MCP, and hooks affect context;
• what Cursor's current documentation says about data, secrets, retention, and network access;
• how to run a two-week pilot and gate rollout on merge-ready outcomes.

If agent loops are new to you, read Agent Loop: Architecture, Recovery, and Production Evaluation first.

A Control Plane, Execution Plane, and Evidence Plane

Calling Cursor 3 "agent-first" is useful only if the architecture is made concrete. A team is operating three planes:

The control plane is the workspace where a developer starts, observes, and redirects sessions. The execution plane is either the developer's machine or an isolated cloud VM where commands and tools actually run. The evidence plane is the diff, commit history, test output, artifact, remote desktop view, and pull request used to decide whether the work is acceptable.

This separation prevents a common category error: a fluent agent transcript is control-plane output, not evidence that the repository is correct. Approval should depend on the evidence plane and normal engineering controls.

What the unified workspace changes

The workspace makes local and cloud agents visible in one place and supports work across multiple repositories. That helps when a task spans an API, client, and shared schema, or when a developer wants to dispatch a slow migration remotely and continue local work.

The bottleneck then moves. Typing may become cheaper, but task definition, conflict management, review, and recovery become more important. A team that cannot state acceptance criteria or reproduce its environment will scale ambiguity, not delivery.

Local and Cloud Agents Are Different Trust Zones

A local session inherits the developer machine's files, network routes, credentials, and installed tools. A Cloud Agent receives a remote environment and credentials selected for that run. The conversation may move between them, but their authority should not be assumed to be equivalent.

Use an explicit handoff contract:

A cloud handoff should not silently widen access. If a local session can query production, do not copy that credential into the remote environment merely for convenience. Create a scoped test identity or remove that capability from the task.

How a Cursor Cloud Agent Runs

Cursor renamed Background Agents to Cloud Agents. According to its current documentation, each run uses an isolated virtual machine and can operate on one or more repositories, execute terminal commands, use supported MCP servers and hooks, and expose artifacts or a remote desktop for inspection.

A typical lifecycle is:

1. The developer selects repositories, a base revision, and a task.
2. Cursor provisions or restores an isolated environment.
3. The agent obtains repository context and configured capabilities.
4. It edits files and invokes commands or tools.
5. It reports evidence through the session and Git workflow.
6. A human and CI system decide whether the result may advance.

The VM is an execution isolation boundary, not a correctness boundary. It can keep one run from modifying another run's filesystem, but code inside the VM can still make outbound requests, expose a supplied secret, modify the wrong files, or follow malicious instructions from repository content.

Three environment setup strategies

Cursor documents three ways to prepare Cloud Agent environments:

Start with agent-led setup to discover prerequisites, then codify stable steps and use a snapshot only when its refresh owner and invalidation conditions are clear. Do not invent a configuration schema from examples in third-party articles; validate the file against Cursor's current environment documentation.

Parallel Agents Need Conflict Domains

Running agents concurrently can reduce wall-clock time only when the tasks are independent enough to merge. Ten agents editing the same package, lockfile, database migration sequence, or generated client create more reconciliation work than useful parallelism.

Define a conflict domain before dispatch:

• repository and base SHA;
• owned directories or interfaces;
• schema and generated-code ownership;
• files that must not change;
• dependency and migration coordination;
• expected integration order.

Parallelize read-heavy investigations, independent test additions, documentation, isolated adapters, and clearly partitioned modules first. Serialize changes to shared schemas, authorization middleware, dependency manifests, build systems, and migrations unless one task explicitly owns integration.

Measure throughput at the merged-change level:

effective throughput =
  accepted tasks
  / (agent runtime + human review + conflict resolution + recovery time)

Counting simultaneous sessions or generated lines rewards activity rather than delivery.

Context Is a Supply Chain

Cursor agents do not reason from the prompt alone. Their context can include repository files, language-server information, prior session state, browser pages, plugin-provided capabilities, MCP responses, hook output, terminal output, and project rules. Each source has a different owner and trust level.

Treat context as a supply chain:

An MCP response that matches a JSON schema can still contain malicious instructions or incorrect data. Schema validation establishes shape, not trust. See Model Context Protocol: Architecture and Security Boundaries for the protocol-level distinction.

Cursor Rules Improve Consistency, Not Authority

Cursor supports project rules under .cursor/rules/*.mdc and can read AGENTS.md. These files are useful for durable conventions: build commands, architectural boundaries, test expectations, review checklists, and paths that require special handling.

A useful rule is short and verifiable:

---
description: API change contract
globs: services/api/**/*.go
alwaysApply: false
---

- Preserve backward compatibility for public JSON fields.
- Run `go test ./services/api/...`.
- Do not modify generated clients directly.
- Report changed endpoints and migration requirements in the final summary.

Rules should point to executable checks rather than duplicate long manuals. "Run this test and report this evidence" is stronger than "write high-quality code."

Rules are still prompt context. They do not enforce tenant isolation, restrict network egress, protect a branch, or prevent secret disclosure. Put non-negotiable controls in IAM, repository permissions, CI, network policy, and the application itself. This distinction is central to Context Engineering.

Security and Data Boundaries

Cursor's Cloud Agent security documentation is unusually important because the product executes terminal commands remotely and is designed to operate with less synchronous supervision.

As of October 1, 2026, the documented boundary can be summarized as follows:

Re-check these properties before procurement or rollout because cloud controls and retention terms can change. The source of truth is the current Cursor security documentation and your signed agreement.

The prompt-injection path

A realistic failure chain is:

untrusted issue, dependency, web page, or repository file
  -> instruction enters agent context
  -> agent chooses a terminal or MCP action
  -> broad secret or network access is available
  -> data or authority crosses the intended boundary

Mitigate each edge:

1. Label untrusted inputs and prevent them from redefining the task.
2. Remove production credentials from routine environments.
3. Separate build secrets from runtime secrets.
4. Use OIDC or other short-lived identity where supported.
5. Restrict egress to required domains.
6. Require approval for high-impact tools.
7. Rotate exposed credentials and preserve an incident trail.

The complete threat model is covered in Prompt Injection: Threat Model and Defenses.

Review the Change, Not the Performance

Cursor can expose diffs, commits, pull requests, artifacts, logs, and a remote desktop. These are evidence surfaces. They become useful only when tied to a claim:

Do not accept "tests passed" without the command, revision, and test scope. Do not accept a screenshot as evidence of data integrity. Do not accept a clean diff as evidence that omitted files were unnecessary.

Keep the normal branch protection and CI path. The agent may prepare a commit or PR; it should not be the actor that grants its own exception, approves its own high-risk change, or weakens the check that evaluates it.

What Independent Evidence Does and Does Not Show

Productivity claims for coding agents are highly sensitive to tool generation, task selection, repository familiarity, and whether review and rework are counted.

METR's 2025 randomized controlled trial covered 16 experienced open-source developers and 246 tasks under early-2025 tool conditions. Participants expected AI to make them faster, but the measured result was about 19% slower. METR now marks that result as evidence about those tools and conditions, not a timeless estimate for current agents.

In a February 2026 update, METR explained that later observational experiments suffered from serious selection effects: developers could choose when to use AI, making the assisted and unassisted tasks incomparable enough that the study could not reliably estimate current uplift. That is a warning against reading a raw "tasks with AI were faster" dashboard as causation.

A March 2026 METR maintainer study reviewed 296 agent-produced pull requests associated with 95 issues across three repositories. Automated graders scored the changes about 24.2 percentage points higher on average than maintainers' merge decisions. The sample is narrow, and the agents did not receive the normal iterative feedback available to human contributors, so it is not a universal rejection rate. It does show why benchmark passing and merge readiness are different outcomes.

The defensible conclusion is neither "agents always slow developers down" nor "agents now make developers faster." It is: measure the current tool on representative work, include review and rework, and preserve task-selection information.

A Two-Week Cursor 3 Pilot

Run the pilot as a bounded engineering experiment, not a company-wide license rollout.

1. Build the task set

Select 24 to 40 recent tasks before assigning a tool:

• 30% low-risk, well-specified maintenance;
• 40% ordinary feature or test work;
• 20% cross-module or ambiguous debugging;
• 10% security, migration, or other high-consequence work used initially for observation only.

Record estimated difficulty, repository, task type, and developer familiarity. Exclude synthetic toy tasks unless toy work is what the team ships.

2. Freeze the acceptance contract

For each task, define:

• observable expected behavior;
• tests and static checks;
• allowed scope and forbidden changes;
• required evidence;
• rollback or failure handling;
• who makes the final acceptance decision.

Do this before the agent runs. Moving the criterion after seeing an output makes the evaluation impossible to interpret.

3. Compare workflow outcomes

Use a baseline from comparable recent work or randomize eligible tasks between the existing workflow and Cursor-assisted workflow. Preserve tasks where the developer declines agent use; that selection signal is part of the result.

Track:

Report median and tail values by task class. A single average can hide expensive failures.

4. Start with narrow authority

Use test data, read-only external systems, short-lived identities, domain allowlists, protected branches, and human merge approval. Add a capability only after the task set demonstrates that it is needed.

5. Decide before expanding

Agree on thresholds before the trial. For example: no policy violations, no regression increase, at least 75% acceptance without major rework, P95 cycle time below the team's target, and lower total cost per accepted task for the eligible task class.

A Runnable Go Evaluation Gate

The following program consumes independently reviewed task records and fails the release gate if the pilot misses its thresholds. It deliberately evaluates accepted work, not agent self-reports.

package main

import (
	"encoding/json"
	"fmt"
	"os"
	"sort"
)

type Record struct {
	TaskID           string  `json:"task_id"`
	Accepted         bool    `json:"accepted"`
	DurationMS       int64   `json:"duration_ms"`
	CostUSD          float64 `json:"cost_usd"`
	PolicyViolations int     `json:"policy_violations"`
	ReviewerMinutes  float64 `json:"reviewer_minutes"`
}

type Report struct {
	Tasks                      int     `json:"tasks"`
	AcceptanceRate             float64 `json:"acceptance_rate"`
	P95DurationMS              int64   `json:"p95_duration_ms"`
	CostPerAcceptedTaskUSD     float64 `json:"cost_per_accepted_task_usd"`
	ReviewerMinutesPerAccepted float64 `json:"reviewer_minutes_per_accepted"`
	PolicyViolations           int     `json:"policy_violations"`
	Passed                     bool    `json:"passed"`
}

func main() {
	if len(os.Args) != 2 {
		fail("usage: go run gate.go records.json")
	}

	file, err := os.Open(os.Args[1])
	if err != nil {
		fail(err.Error())
	}
	defer file.Close()

	var records []Record
	if err := json.NewDecoder(file).Decode(&records); err != nil {
		fail(err.Error())
	}
	if len(records) == 0 {
		fail("records must not be empty")
	}

	latencies := make([]int64, 0, len(records))
	accepted := 0
	violations := 0
	totalCost := 0.0
	totalReviewMinutes := 0.0

	for _, record := range records {
		if record.DurationMS < 0 || record.CostUSD < 0 || record.ReviewerMinutes < 0 {
			fail("duration, cost, and reviewer minutes must be non-negative")
		}
		latencies = append(latencies, record.DurationMS)
		totalCost += record.CostUSD
		totalReviewMinutes += record.ReviewerMinutes
		violations += record.PolicyViolations
		if record.Accepted {
			accepted++
		}
	}

	sort.Slice(latencies, func(i, j int) bool {
		return latencies[i] < latencies[j]
	})
	p95Index := (95*len(latencies)+99)/100 - 1

	report := Report{
		Tasks:            len(records),
		AcceptanceRate:   float64(accepted) / float64(len(records)),
		P95DurationMS:    latencies[p95Index],
		PolicyViolations: violations,
	}
	if accepted > 0 {
		report.CostPerAcceptedTaskUSD = totalCost / float64(accepted)
		report.ReviewerMinutesPerAccepted = totalReviewMinutes / float64(accepted)
	}

	report.Passed = accepted > 0 &&
		report.AcceptanceRate >= 0.75 &&
		report.P95DurationMS <= 900_000 &&
		report.CostPerAcceptedTaskUSD <= 3.00 &&
		report.ReviewerMinutesPerAccepted <= 20 &&
		report.PolicyViolations == 0

	output, err := json.MarshalIndent(report, "", "  ")
	if err != nil {
		fail(err.Error())
	}
	fmt.Println(string(output))
	if !report.Passed {
		os.Exit(1)
	}
}

func fail(message string) {
	fmt.Fprintln(os.Stderr, message)
	os.Exit(2)
}

Use thresholds that reflect your own service levels and risk. Keep the raw records, sampling rules, baseline, evaluator identity, Cursor version, model policy, and environment revision so the result can be reproduced. When a model helps judge subjective outputs, calibrate it as described in LLM-as-a-Judge and keep deterministic checks for deterministic requirements.

Production Rollout Gates

Move from pilot to routine use in stages:

For every stage, keep these invariants:

1. The task has a named human owner.
2. The environment is reproducible from a known revision.
3. Secrets are scoped, short-lived where possible, and not stored in rules or repository config.
4. The agent cannot bypass the check that judges its output.
5. A failed run can be stopped, inspected, and recovered without guessing its state.
6. Session and snapshot deletion have an owner and schedule.

Common Failure Modes

Optimizing generated volume

More tokens, files, or simultaneous agents can increase review load. Optimize accepted outcomes and elapsed delivery time.

Treating the VM as a sandbox for secrets

Isolation between VMs does not prevent a command from sending a secret over an allowed network path. Scope credentials and egress independently.

Copying local authority to the cloud

A developer's broad credential set is usually larger than a single task needs. Issue task-specific identities instead of reproducing the laptop environment.

Encoding policy only in rules

Rules can be ignored, displaced by context, or interpreted incorrectly. Enforce critical policy through deterministic systems.

Letting parallel work share hidden state

Shared migrations, generated files, and dependency locks turn parallel execution into merge and semantic conflicts. Declare ownership before dispatch.

Using benchmark pass rates as merge rates

A test harness cannot represent every maintainability, product, or operational concern. Include the reviewer decision and rework in the metric.

Keeping every session forever

Default retention is not a records-management policy. Define deletion, legal hold, and audit requirements before sensitive use.

When Cursor 3 Is a Good Fit

Cursor 3 is a strong candidate when your team:

• already works comfortably in an IDE-centered workflow;
• has repeatable builds and meaningful automated checks;
• can partition tasks and review changes through Git;
• benefits from remote execution or multi-repository coordination;
• can establish scoped cloud identities and data controls.

Be cautious when builds depend on undocumented local state, production access is routinely available to developers, most tasks require tacit domain judgment, or reviewers are already overloaded. The agent workspace amplifies the operating system around development; it does not repair a missing one.

Compare it with terminal-first and platform-integrated alternatives using the same task set, controls, and cost definition. Our AI Coding Tools Comparison Method explains how to avoid feature-count comparisons.

Final Assessment

The durable contribution of Cursor 3 is not a claim that the editor has disappeared. It is a clearer separation between assigning work, executing work, and accepting work. Local and cloud agents widen the execution options; files, LSP, browser access, plugins, MCP, hooks, and rules widen the context; diffs, tests, artifacts, and pull requests make review possible.

The system is valuable when those surfaces reduce time to an accepted change without weakening security or moving hidden labor onto reviewers. Prove that with a representative pilot, least-privilege environments, independent evidence, and explicit release gates. That is a stronger adoption case than any demo, model label, or benchmark headline.

Sources and Further Reading

• Cursor 3 announcement - release date and agent workspace scope
• Cursor Cloud Agent documentation - runtime, environment, integrations, artifacts, and handoff
• Cursor Cloud Agent security and network documentation - compute, data, secrets, retention, and egress boundaries
• Cursor Rules documentation - .cursor/rules/*.mdc and AGENTS.md
• METR: Updated analysis of AI coding productivity - randomized-trial scope and later selection-bias limits
• METR: Many SWE-bench-passing PRs would not be merged - automated grader versus maintainer evidence