Work with confidence
Understand FireCursor security and privacy
FireCursor’s security model depends on which execution path you choose. Local provider runs operate through the paired computer; Cursor Cloud runs in Cursor’s environment; Android connects through a temporary TLS tunnel protected by a random pairing token.
Quick answer
The shortest useful version.
Verify the project and provider, keep pairing details private, use local execution for local-only work, review cloud boundaries before cloud runs, and stop remote control when the session ends.
Step by step
Do this with confidence.
- 01
Classify the task
Identify repository sensitivity, external services, secrets, and whether cloud execution is acceptable.
- 02
Choose local or cloud
Local Cursor, Codex, and Claude runs stay with their supported interfaces on the paired computer. Cursor Cloud has a separate account and data boundary.
- 03
Protect pairing
Treat the QR code and token as short-lived credentials. Pair privately and end the tunnel after use.
- 04
Control tools and integrations
Review approvals, MCP scopes, plugins, connectors, hooks, and provider authentication as separate trust decisions.
Where sensitive values live
The pairing token is stored on the two paired endpoints. An optional Cursor API key stays in private, backup-disabled Android storage and is sent only to Cursor over HTTPS, not to the extension.
Provider credentials remain governed by their supported authentication path. Do not paste secrets into ordinary agent messages.
Security habits that scale
- Use the smallest task and tool scope
- Keep the app, extension, and providers current
- Verify checksums for directly distributed artifacts when appropriate
- Review diffs and external side effects
- Revoke stale connectors and stop unused remote sessions