Cursor’s agents run in two places: in the editor and CLI on your engineers’ laptops, and as Cursor Cloud Agents in VMs on Cursor’s infrastructure. Cursor security at company scale means one set of rules for both: what each agent can reach, which credentials it never holds, and which engineer answers for each request. Here’s how we secure Cursor agents with Formal, and where Cursor’s own controls already do the job.
What does Cursor security already cover?
As of November 2026, Cursor documents a solid baseline for Cloud Agents: a Firecracker-based microVM per agent in a separate AWS account, Privacy Mode, an outbound allowlist admins can lock org-wide, Runtime Secrets stripped from transcripts, and pull requests for review (Cursor’s Cloud Agent security overview).
Most Cursor AI security advice stops there. A domain allowlist decides which hosts an agent reaches, not which requests it sends, and configured secrets still reach the VM as environment variables. Formal adds the layer on the wire: a policy decision per request, credentials held outside the agent, and logs tied to the engineer, on laptops and in the cloud.
How do you secure Cursor on engineers’ laptops?
Formal Endpoint runs on the laptop. With Transparent Mode on (macOS and Linux), it intercepts the connections your network rules select, logs them and applies policy, without changing Cursor’s settings.
Formal recognizes Cursor by process: the app by its code signature on macOS (team ID VDXQ22DGB9) and by process name on Linux, the Cursor CLI by its cursor-agent launcher. Both match process.is_cursor, and process.has_agent_ancestor also catches what Cursor spawns. So a rule can send Cursor’s MCP and model traffic through policy while the engineer’s browser passes untouched. See network rules.
How do you secure Cursor Cloud Agents without static secrets?
Cursor Cloud Agents can mint short-lived OIDC tokens. The Endpoint, installed in the agent’s environment, exchanges that token for a short-lived Formal machine session, refreshes it automatically and runs Transparent Mode inside the VM. No Formal API key goes into the environment.
The Cursor preset’s claim condition pins tokens to your Cursor team and optionally one repository (claims.team_id, claims.repo_url). Its End-User Email Expression, claims.owner_email, maps each run to the Formal user with the same email, so rules can match the engineer, not only the machine user. The config, from the Cloud Agents guide:
auth_mode = "oidc"
[oidc]
provider = "cursor"
integration_id = "integrationoidc_<INTEGRATION_ID>"
[transparent_proxy]
enable = true
enforce = true
fail = "closed"
With fail = "closed", the proxy stays enforced if the Endpoint errors. Set it up through Cursor’s guided setup or a versioned .cursor/environment.json. A Control Plane Permission limits the machine user to Endpoint authentication and logging. Why we built it this way: Giving Cloud Agents Production Access with OIDC, Not Secrets.
Can you stop Cursor Cloud Agents from merging their own pull requests?
Yes. With a network rule on github.com and api.github.com for your agent machine users, the Endpoint terminates TLS and a Rego policy blocks the GraphQL mutations enablePullRequestAutoMerge, enqueuePullRequest and mergePullRequest, plus the REST merge endpoint. Agents still push branches and open pull requests. The Prevent Merges by Cloud Agents recipe creates the rule and policy for you.
How do Cursor agents reach your data without holding API keys?
Put the credential on the Connector. A native user on a Formal resource holds the API key or database password, and the Connector adds it to requests your policies allow. On laptops, a network rule forwards matching traffic from the Endpoint to the Connector with the engineer’s identity. In Cloud Agents, the same OIDC trust can mint a short-lived federation token for the Connector. We document an approval-gated version of this flow for Devin; the Connector side is PAM.
How does Cursor MCP security work with Formal?
Route Cursor’s MCP servers through the MCP gateway on the Connector. It adds the upstream credential, controls who can use each server and which tools, and logs every tool call with a Formal identity. Where Cursor runs decides the setup:
- Cursor on a laptop with the Endpoint: keep the server’s original URL. A network rule forwards agent MCP traffic to the Connector, and the Endpoint adds the engineer’s identity.
- Cursor Cloud Agents: they call MCP servers from Cursor’s cloud, so the Endpoint in the VM doesn’t see those calls. Add the server’s Connector address under Plugins & MCPs in the Cursor dashboard, and each member signs in to Formal. The Connector must be reachable from Cursor’s cloud.
The gateway covers remote MCP servers over HTTPS, not local stdio servers.
Where does Formal stop in a Cursor enterprise security setup?
- Model data handling stays with Cursor. Privacy Mode and Cursor’s model provider agreements are Cursor settings.
- Formal doesn’t review the code Cursor writes. That’s application security tooling.
- The engineer mapping trusts Cursor’s claim. Formal verifies the token signature;
owner_emailis Cursor’s statement about who started the run.
