Cursor Enterprise: Compliance & Monitoring

Audit logs record security events and administrative actions so you can see who did what, when. They are available on the Enterprise plan and viewable in the team dashboard with admin access. Cursor does not log agent responses or generated code content. For that, it recommends hooks (covered below).

• Authentication: logins and logouts.
• User management: additions (via SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition., invite, signup, team creation or auto-enrollment), removals, role changes and individual spend limits.
• API keys: team and user API key creation and revocation.
• Team settings: team-wide and per-user spending limits, admin settings, team name changes, Slack integration settings and repository mappings.
• Repositories, Cloud Agent environments, directory groups, 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. changes, team rules (including BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition.), team hooks and custom commands.

Most of that list is administration rather than usage. privacy_mode, team_rule, team_hook, mcp_server_config, team_repo: the events record your controls moving, which is usually what an auditor is testing. Whether the guardrails in place during an incident were the ones you documented is a question this log answers cleanly, with a timestamp, an actor, an IP address and a team id on every entry.

None of it helps a pilot running on a Team plan, since the audit log is an Enterprise feature. If a security review is going to want evidence out of your pilot, settle the plan question before the pilot starts.

View audit logs in the team dashboard at cursor.com/dashboard/audit-log; this requires admin access on an Enterprise plan. For monitoring, Cursor can stream logs to your existing systems. Contact hi@cursor.com to set up streaming.

Streaming sends the same events to wherever your alerting and retention already live, so you aren't checking a second dashboard. Cursor lists four destination categories: SIEM systems, webhook endpoints, object storage and log aggregators.

The table does not say which destination you want. A SIEM buys you correlation and alerting next to everything else you already watch. An S3 bucket is long-term retention, and a webhook is whatever you are prepared to build and then keep running. Most teams probably end up with two of them, since retention wants everything kept cheaply for years while alerting wants a short list of events surfaced fast.

Streaming is not self-serve. Setup goes through hi@cursor.com, so it is a lead-time item, and the part that slips is raising it in the same thread as the contract instead of the week before an audit. The dashboard export covers you until it is live.

Logs are delivered as JSON with a metadata block (timestamp, event_id), plus team_id, ip_address, user_email and an event object with event-specific fields. The event_type covers actions like login, logout, add_user, update_user_role, team_settings, privacy_mode and BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. events. In the dashboard you can filter by date range, event type and actor, and export filtered results to CSV for compliance reports.

When an event you expected is missing, check the dashboard before you check the pipeline. Filter to that actor and that day, and see whether it exists at source. The answer, in practice, is often that the action was never in the logged set, and no work on the delivery side will produce it.

Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. augments git blame with line-level human and agent co-authorship. Commits are tagged with AI-code tracking, and an AI-code-tracking API exposes the same data. During a security review or incident you can answer who wrote a given line: a human or an agent. That feeds the audit trail and tells you which lines need extra scrutiny before they ship.

Above the line level, the team dashboard reports adoption and an exportable audit log gives per-action detail. A read-only Analytics API lets you pull the same metrics into your own reporting stack.

The dashboard's AI share of committed code is computed on-device from diff signatures, on the machine where the code was written, which sets the edge of what that number can tell you. Background agents and the CLI sit outside it, and a formatter sweeping a file can invalidate the signature that made the match, per team analytics. Whether Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. carries the same blind spots is not documented, so for an audit trail, read an untagged line as unknown rather than as human.

Audit logs stop at administrative actions, so a record of development activity has to come from somewhere else, and Cursor's recommendation is hooks. Its two compliance examples map onto specific events. beforeSubmitPrompt fires right after someone hits send and before the request leaves; afterFileEdit fires after the agent writes a file and receives the path plus the edits. Both example scripts post a line to a compliance endpoint you run.

The default is fail-open, and security hardening works through what that means for hooks you use as controls. A logging hook fails differently. A week with no events reads the same whether the team was on holiday or your endpoint was refusing connections. Nothing in the record separates the two, so an auditor asking whether the log is complete gets your word for it.

Setting failClosed: true on the logging hook is the obvious fix, and it was my first instinct. It solves the wrong half. A blocked prompt does tell somebody the pipe is broken, but the record still cannot vouch for the quiet days, and you have now put a compliance script in the path of every prompt your team sends. Measure the hook's own output instead. Count events per day, per developer where you can, and raise something when a stream that normally carries traffic goes flat.

Tab has its own hook surface, which is easy to miss while you are wiring this up. Cursor files afterFileEdit under Agent hooks, applying to Agent chat and ⌘+K, and puts inline completions on a separate afterTabFileEdit. The same docs then list TabWrite among the tool types you can match on afterFileEdit, which leaves the boundary less settled than the two categories make it look. Register both hooks, log which one delivered each event, and read a day of real traffic before you write a coverage claim into a control document.

Four levels can define hooks, and the level you pick decides who the hook covers. Enterprise hooks are MDM-managed and system-wide (/Library/Application Support/Cursor/hooks.json on macOS, /etc/cursor/hooks.json on Linux). Team hooks are configured in the web dashboard on Enterprise plans and sync to every member automatically. Project hooks sit in <project-root>/.cursor/hooks.json, user hooks in ~/.cursor/hooks.json. Matching hooks from every source run, and on a conflict the priority order is Enterprise, then Team, then Project, then User.

Start at the Team level if you have Enterprise. A Team hook follows the person to whatever repo they open, so coverage tracks people, and it runs inside cloud agents as well as on desktops. Its create, update and delete events land in the audit log as team_hook, so a change to the compliance hook itself leaves a record.

Move to the MDM level when a developer's own config must not be able to win, since Enterprise takes precedence when responses conflict. Doing that first, before the script has settled, means every fix to a shell script waits on a device-management release.

Project hooks are the layer for rules a single repository needs, and they travel with the code. Coverage then follows repositories, though, so the repo somebody spins up next month has no compliance hook in it until they remember to add one. Keep user-level hooks out of a compliance design, since they never load in cloud agents.

Cloud agents are the exception at all four levels, since they can start in a read-only environment where hooks do not run, which puts the beginning of the record at the agent's first write.

On a team of eight, most of this is over-engineering. A project hook that appends a line per edit, plus git history and Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition., answers what people actually ask, and I would not build a delivery pipeline for it. What changes with headcount is who notices when it stops. At eight people somebody sees that the file has not grown; past a few hundred nobody does unless something is watching the event count.

Yes. Cursor maintains compliance with industry standards including SOC 2 Type II and GDPR. Compliance documentation is available through the Trust Center at trust.cursor.com, including SOC 2 reports, penetration test summaries, security architecture documentation and data flow diagrams.

The SOC 2 report is requested through the Trust Center, not downloaded from it, and it is the document most reviewers want first. The standard DPAData Processing Agreement. The contract spelling out exactly how a vendor may process your data: purposes, subprocessors, retention and breach duties. The document privacy reviews actually read. Press Enter for the full definition. is different. It is published at cursor.com/dpa, so a reviewer has something to read on day one while the report is still pending. Put the ask in when the review opens, and whatever the turnaround is, it runs while you are still collecting the rest.

Use Cursor's responsible disclosure program. Email security-reports@cursor.com with a detailed description of the vulnerability, steps to reproduce, and any relevant screenshots or proof of concept.

Send all three items in the first email. A report missing repro steps turns into a back-and-forth, which is time the vulnerability spends unfixed. Note that this address is for flaws in Cursor itself, and a compromise of your own account follows a different path.