--- title: "Anomity Integrates with Cursor | Anomity Blog" description: "Anomity now reads your Cursor team: auto-run, sandbox and MCP allowlist settings, the MCP servers members add, keys left after offboarding, and model spend." url: "https://anomity.ai/blog/anomity-cursor-integration/" source: html --- Anomity Integrates with Cursor Contents - Why Cursor, and why now - What the connector reads - Team settings live in the audit log - What it flags - The MCP servers people add - The offboarding gap - Model usage and spend - How setup works - Current limits - How Anomity and Cursor fit together - Frequently asked questions 0% 7 min read Share - X.com - LinkedIn - Email - Copy URL - Copy markdown [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Anomity Integrates with Cursor ![Anomity robot illustrating Anomity Integrates with Cursor] Company # Anomity Integrates with Cursor Anomity Research Anomity Research · Oct 25, 2026 · 7 min read Share: Copied TL;DR - Anomity now connects to Cursor . The connector reads one Cursor team through Cursor's Admin API: its members, its governance settings, the MCP servers people configure in Cursor, what offboarding revoked and what it left behind, and who used which model at what cost. - Cursor has no API that returns team settings, so the connector reads them from the audit log , where every settings change records the whole settings object. It carries what it has seen between syncs, so a snapshot is not lost when the event ages out of Cursor's history. - On by default, it flags auto-run left to each member or Run Everything offered, no MCP allowlist , agent sandboxing off , MCP servers configured in Cursor that are not on your Anomity MCP allowlist , and removed members whose personal API keys were retained . - Cursor usage joins the AI Spend board next to Claude Enterprise, the Anthropic Console and the OpenAI Platform: per person, per model, per day, with service accounts on their own line. - Setup is one team Admin API key , and a read-only key is what we ask for. Anomity never calls an endpoint that changes the team. - The Endpoint Sensor already sees Cursor on every laptop and enforces at Cursor's hooks. The connector adds the team plane: the policy each laptop is supposed to run under , and the people and keys behind it. Anomity now integrates with **Cursor**. Connect a Cursor team and Anomity reads how the team governs its agent, from auto-run and sandboxing to the MCP allowlist, hooks and extension signing, along with the MCP servers people configure in Cursor, who is on the team, what offboarding left behind, and who used which model at what cost. The integration is available today from the discovery connectors page in the Anomity console. Anomity already sees Cursor on the laptop. This connector adds the team, and this post explains how the two halves fit together. ## Why Cursor, and why now Cursor is an agent, not just an editor. It runs terminal commands, edits files and calls MCP tools, and how much of that it does without asking is a setting. We have covered it closely from the endpoint: [what auto-run allow and deny lists can and cannot stop](https://anomity.ai/blog/cursor-auto-run-yolo-allow-deny-limits/), [the config surface it leaves on each machine](https://anomity.ai/blog/cursor-config-surface-cursorrules-mcp-drift/), and a run of sandbox escapes such as [DuneSlide](https://anomity.ai/blog/duneslide-cursor-sandbox-escape-cve-2026-50548-50549/). Since July, Anomity has enforced policy at Cursor's hooks on managed devices. What a laptop cannot show is the team. Whether auto-run is governed for everyone or left to each member, whether there is an MCP allowlist, whether sandboxing is on, who was removed and what was left valid: those live in Cursor's team admin settings, and one device only sees their effect on one person. The Cursor Admin API answers them for the whole team. ## What the connector reads Everything below comes from one team Admin API key, and every call is a read. From Cursor What Anomity records **Members** Every member and role. Cursor keeps removed members in the list, marked as removed, which makes 'departed' a fact rather than an absence. If the list cannot be read, the sync fails rather than showing an empty connector as healthy. **Team settings** The team's governance posture, from auto-run and sandboxing to the MCP allowlist and conversation sharing. Read from the audit log, as explained below. **MCP servers configured in Cursor** One row per server, configured for the whole team or by members in their own settings, with its transport, who configured it and the hosts they signed in to. **Offboarding records** What Cursor revoked, and what it kept, each time it removed a member. **Model usage** Who used which model on which day, with tokens and cost, across editor, CLI, cloud agents and bots. The first sync reads 90 days. ## Team settings live in the audit log Cursor's Admin API has no endpoint that returns a team's settings. What it does have is an audit log, and every time an admin changes a team setting, Cursor records the entire settings object in that event. The most recent one is the team's current posture, so that is where the connector reads it. There is a catch. On the live team we tested, Cursor's audit log reached back about 60 days, so a team that has not changed a setting in two months has no posture to read. The connector therefore carries state between syncs. The first sync reads back 180 days, in case a plan keeps more; later syncs read only what is new and keep the last settings snapshot, the MCP servers seen configured and the offboarding records, so nothing is forgotten when its event ages out of Cursor's history. With no snapshot at all, every settings check reports 'Not checked' instead of raising a finding: a setting nobody could read is not one the team got wrong. The next time an admin changes anything, the following sync picks up the whole posture. ## What it flags Findings come from a new Cursor team governance template in Anomity's cloud AI posture policy, and each names the Cursor control behind it. Check What it means Default **Auto-run left to members** Team auto-run controls are off, so each member decides how much the agent runs unasked, Run Everything included. On **Run Everything offered** A member may pick the mode that runs every terminal command and tool call with no approval. On **No MCP allowlist** Members can add any MCP server to Cursor, and the agent can call its tools. On **Agent sandboxing off** Agent commands run with the member's full account access, not the sandbox's file and network limits. On **MCP server not on your allowlist** A server configured in Cursor, for the team or by members, that is not on the Anomity MCP allowlist. On **Departed member, keys retained** Cursor revoked sessions and repository grants on removal, but recorded personal API keys as retained. On **Members outside your domains** and **admin sprawl** Active members whose email is not on your corporate domains, and more than three owners and admins. On **Bring your own key allowed** Requests on members' own provider keys run on accounts the company does not hold, outside spend reporting. Off **Extension signing off** Extensions are installed in Cursor without signature verification. Off **Hooks not awaited** The first prompt after start can run before enterprise, team and project hooks have loaded. Off **Invites from any domain** A forwarded or leaked invite lets an outside account join the team. Off **IP allowlist off** and **conversation sharing** No inbound IP allowlist, and conversations shareable beyond the team or indexable by search engines. Off The off-by-default checks are choices plenty of well-run teams make the other way, such as bring-your-own-key, or skipping the pause that waiting for hooks costs at startup. Findings route to the SIEM, [Slack](https://anomity.ai/blog/anomity-slack-app-integration/) or [Jira](https://anomity.ai/blog/anomity-jira-integration/) like every other Anomity finding. ## The MCP servers people add Cursor's audit log records each MCP server configuration with a name, a transport and a scope (the team, or one member's own settings), but never its URL. Separately, it records the host a member signed in to when a server asked for authentication. The connector joins the two by name, and deliberately narrowly: 'Atlassian MCP' matches mcp.atlassian.com, but a server called 'atlassian-internal-bridge' does not borrow an approved Atlassian host. Where a host is known, the server is checked against your Anomity MCP allowlist by host; otherwise by name, and the row says it was checked by name only. It is the same allowlist Anomity applies on the endpoint and to agents in [Okta](https://anomity.ai/blog/anomity-okta-for-ai-agents-integration/), which is the point of having one, as we argued in [how to build an MCP server registry](https://anomity.ai/blog/how-to-build-an-mcp-server-registry/). Forty members who configured the same server are one row, and if the allowlist cannot be loaded, nothing is flagged on a guess. ## The offboarding gap When Cursor removes a member, its audit log records what was revoked. On the live team we verified against, a removal recorded sessions revoked, repository grants cleared, and personal API keys retained. The person was gone; their keys were not. The connector found exactly that member. The finding is raised only when the member list says the person is removed and has not been re-added, never from absence alone, and when usage data shows that person active after the removal, the finding says so. It is the same class of problem as keys owned by people who have left, which the [OpenAI API Platform connector](https://anomity.ai/blog/anomity-openai-api-platform-integration/) flags, and it is easy to miss because the offboarding looked complete. ## Model usage and spend Usage becomes daily lines per person and model, with service accounts on their own line. Cursor joins the AI Spend board next to [Claude Enterprise](https://anomity.ai/blog/anomity-claude-enterprise-integration/), the [Anthropic Console](https://anomity.ai/blog/anomity-anthropic-console-integration/) and the OpenAI Platform. The cost shown is what Cursor charged for each request, which includes usage covered by the plan, so it is the cost of the usage, not the invoice. Requests a member makes on their own provider key do not appear here at all, which is what the bring-your-own-key check is for. ## How setup works - In Cursor, a team admin creates a team Admin API key in the dashboard under Settings, API keys, on the Team API keys tab. A read-only key is what we ask for. - In Anomity, add a Cursor connector from the discovery connectors page and paste the key. It is stored encrypted. - Test the connection. Anomity reads the member list and reports how many members it can see. Cursor itself refuses personal and service-account keys on the Admin API, and Anomity passes its message through. - Sync. The first sync backfills the audit log and 90 days of usage; later syncs read what is new. Every call is a read: GETs, plus the POST request Cursor uses for usage queries. Revoking Anomity's access is deleting the key in Cursor. A rotated key that reads the same team keeps the history Anomity has collected; a key for a different team starts over, so nothing from the old team is reported against the new one. ## Current limits We verified the connector end to end against a live Cursor team on the Business plan before shipping it. The limits are at the edges, and we would rather name them: - Settings appear after a change. Cursor publishes its settings only in the audit log, so a team that has not changed one within its audit history shows 'Not checked' until an admin next does. - Enterprise teams have not been swept yet , and their audit retention and settings fields may differ. Enterprise-only features such as model access controls, repository blocklists and the Analytics API are not read. - Read-only keys and the audit log. We have not confirmed that a read-only key can read the audit log on every plan. Where it cannot, those facts show as not available, never as findings. - No Privacy Mode check. Privacy Mode is not part of the settings Cursor records, so the connector does not report it. We covered what it does in Cursor Privacy Mode and enterprise controls . - Very large teams. One sync reads up to 40,000 usage requests, newest first. Beyond that, spend history starts at the oldest day reached and the team row says so. ## How Anomity and Cursor fit together Cursor's team settings are where the agent is governed, and where you fix what the connector finds. Anomity covers both sides. On each managed device, the Endpoint Sensor inventories Cursor, the MCP servers in its local config, its extensions, rules and secrets, and on Cursor's hooks Anomity decides allow, deny or log before a shell command, file read or MCP tool call runs. In the cloud, the connector reads the team: the policy every laptop should run under, who is on it, what offboarding left behind and what it costs. Put together, the gaps become specific. An MCP server added on one laptop and one added for the whole team are checked against the same allowlist, and a team with sandboxing off is a fact, not a guess from one machine. It is the same pairing Anomity makes for code hosts, where the [GitHub](https://anomity.ai/blog/anomity-github-integration/) and [GitLab](https://anomity.ai/blog/anomity-gitlab-integration/) connectors read the platform side of the AI tools developers use. Anomity collects metadata only, redacts secret values on the endpoint, and is SOC 2 Type II attested. It complements your network, EDR, DLP, GRC and SIEM controls rather than replacing them. To see it against your own Cursor team and fleet, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What does the Anomity Cursor integration do? It connects one Cursor team to Anomity's cloud discovery and reads five things: the member list, including removed members; the team's governance settings, such as auto-run, sandboxing and the MCP allowlist; the MCP servers configured in Cursor, for the whole team or in members' own settings; the offboarding record Cursor writes when it removes someone; and model usage with the cost of each request. Anomity raises findings on all of it through the same cloud AI posture policy that covers its other connectors. How is this different from what the Endpoint Sensor already sees? The Endpoint Sensor sees Cursor on each managed device: the install, the MCP servers in its local config, its extensions and rules, the secrets in its settings, and, through Cursor's hooks, each shell command, file read and MCP tool call, where Anomity can allow, deny or log it before it runs. It cannot see the team: how auto-run, sandboxing and the MCP allowlist are set for everyone, who was removed and what was left valid, or what the team spends. The connector reads that side, so the two together show both the policy and what is actually running. Why does Anomity read Cursor's settings from the audit log? Because Cursor's Admin API has no endpoint that returns a team's settings. Every time an admin changes a team setting, Cursor records the whole settings object in an audit event, so the most recent one is the team's current posture. Cursor kept about 60 days of audit log on the team we tested, so the connector backfills 180 days on its first sync, reads only what is new after that, and keeps the last snapshot it saw. A team with no readable snapshot gets 'Not checked', never a finding. What does the departed member finding mean? When Cursor removes a member, it records what it revoked. On the live team we verified against, a removal recorded sessions revoked and repository grants cleared, and personal API keys retained. Anomity flags a member whose latest record says the keys were retained, who is marked removed in the member list and has not been re-added. It is never claimed from absence alone, and when usage data shows that person active after the removal, the finding says so. The fix is to revoke the keys, or confirm they no longer authenticate. What credentials does Anomity need from Cursor? One team Admin API key, created by a team admin in the Cursor dashboard under Settings, API keys, on the Team API keys tab. A read-only key is what we ask for. Every call the connector makes is a read: GETs, plus the POST request Cursor uses for usage queries. The key is stored encrypted, can be rotated from the console, and revoking Anomity's access is deleting the key in Cursor. Does the integration change anything in Cursor? No. Anomity never calls an endpoint that changes the team. It reads posture and raises findings in its own console, routed wherever your other findings go: the SIEM, Slack or Jira. Does it work on every Cursor plan? We verified it end to end against a live team on Cursor's Business plan. Enterprise-only features, such as model access controls, repository blocklists, billing groups and the Analytics API, are not read. An Enterprise team has not been swept yet, and its audit retention and settings fields may differ. Where a plan or key cannot read the audit log, settings, MCP servers and offboarding show as not available rather than as findings. Does Anomity replace Cursor's own admin controls? No. Cursor's team settings are where auto-run, sandboxing and the MCP allowlist are actually enforced, and that is where you fix what the connector finds. Anomity complements Cursor the way it complements the network, EDR, DLP, GRC and SIEM stack: it shows whether those settings are in place, checks the MCP servers people add against one allowlist across every agent, and enforces policy at the agent hook on each managed device. ## Related posts [Company ### Anomity Integrates with GitLab Anomity now reads GitLab Duo governance on your top-level group: Duo lock, MCP access, prompt-injection protection, AI Catalog scope and group access tokens. Anomity Research · Oct 20, 2026 · 7 min](https://anomity.ai/blog/anomity-gitlab-integration/) [Company ### Anomity Integrates with Cloudflare Anomity now reads Cloudflare AI Gateway, agent Workers and MCP Server Portals, and flags MCP servers on managed devices that bypass every portal. Anomity Research · Sep 30, 2026 · 8 min](https://anomity.ai/blog/anomity-cloudflare-integration/) [Company ### Anomity Integrates with Atlassian and Rovo Anomity now covers Atlassian Rovo on the endpoint and in the Atlassian org: AI activation, Rovo agents, activity logging, and tokens outside the MCP allowlist. Anomity Research · Sep 18, 2026 · 8 min](https://anomity.ai/blog/anomity-atlassian-integration/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Anomity Integrates with Cursor", "description": "Anomity now reads your Cursor team: auto-run, sandbox and MCP allowlist settings, the MCP servers members add, keys left after offboarding, and model spend.", "datePublished": "2026-10-25", "dateModified": "2026-10-25", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/anomity-logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/anomity-cursor-integration/", "relatedLink": [ "https://anomity.ai/blog/anomity-gitlab-integration/", "https://anomity.ai/blog/anomity-cloudflare-integration/", "https://anomity.ai/blog/anomity-atlassian-integration/" ] }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/anomity-cursor-integration.png", "width": 1200, "height": 630 }, "articleSection": "Company", "wordCount": 1449, "timeRequired": "PT7M", "inLanguage": "en", "url": "https://anomity.ai/blog/anomity-cursor-integration/", "keywords": "Cursor team governance integration, Cursor, Integrations, AI Coding Agents, MCP, Agent Governance, Offboarding, AI Spend, Cloud Discovery" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What does the Anomity Cursor integration do?", "acceptedAnswer": { "@type": "Answer", "text": "It connects one Cursor team to Anomity's cloud discovery and reads five things: the member list, including removed members; the team's governance settings, such as auto-run, sandboxing and the MCP allowlist; the MCP servers configured in Cursor, for the whole team or in members' own settings; the offboarding record Cursor writes when it removes someone; and model usage with the cost of each request. Anomity raises findings on all of it through the same cloud AI posture policy that covers its other connectors." } }, { "@type": "Question", "name": "How is this different from what the Endpoint Sensor already sees?", "acceptedAnswer": { "@type": "Answer", "text": "The Endpoint Sensor sees Cursor on each managed device: the install, the MCP servers in its local config, its extensions and rules, the secrets in its settings, and, through Cursor's hooks, each shell command, file read and MCP tool call, where Anomity can allow, deny or log it before it runs. It cannot see the team: how auto-run, sandboxing and the MCP allowlist are set for everyone, who was removed and what was left valid, or what the team spends. The connector reads that side, so the two together show both the policy and what is actually running." } }, { "@type": "Question", "name": "Why does Anomity read Cursor's settings from the audit log?", "acceptedAnswer": { "@type": "Answer", "text": "Because Cursor's Admin API has no endpoint that returns a team's settings. Every time an admin changes a team setting, Cursor records the whole settings object in an audit event, so the most recent one is the team's current posture. Cursor kept about 60 days of audit log on the team we tested, so the connector backfills 180 days on its first sync, reads only what is new after that, and keeps the last snapshot it saw. A team with no readable snapshot gets 'Not checked', never a finding." } }, { "@type": "Question", "name": "What does the departed member finding mean?", "acceptedAnswer": { "@type": "Answer", "text": "When Cursor removes a member, it records what it revoked. On the live team we verified against, a removal recorded sessions revoked and repository grants cleared, and personal API keys retained. Anomity flags a member whose latest record says the keys were retained, who is marked removed in the member list and has not been re-added. It is never claimed from absence alone, and when usage data shows that person active after the removal, the finding says so. The fix is to revoke the keys, or confirm they no longer authenticate." } }, { "@type": "Question", "name": "What credentials does Anomity need from Cursor?", "acceptedAnswer": { "@type": "Answer", "text": "One team Admin API key, created by a team admin in the Cursor dashboard under Settings, API keys, on the Team API keys tab. A read-only key is what we ask for. Every call the connector makes is a read: GETs, plus the POST request Cursor uses for usage queries. The key is stored encrypted, can be rotated from the console, and revoking Anomity's access is deleting the key in Cursor." } }, { "@type": "Question", "name": "Does the integration change anything in Cursor?", "acceptedAnswer": { "@type": "Answer", "text": "No. Anomity never calls an endpoint that changes the team. It reads posture and raises findings in its own console, routed wherever your other findings go: the SIEM, Slack or Jira." } }, { "@type": "Question", "name": "Does it work on every Cursor plan?", "acceptedAnswer": { "@type": "Answer", "text": "We verified it end to end against a live team on Cursor's Business plan. Enterprise-only features, such as model access controls, repository blocklists, billing groups and the Analytics API, are not read. An Enterprise team has not been swept yet, and its audit retention and settings fields may differ. Where a plan or key cannot read the audit log, settings, MCP servers and offboarding show as not available rather than as findings." } }, { "@type": "Question", "name": "Does Anomity replace Cursor's own admin controls?", "acceptedAnswer": { "@type": "Answer", "text": "No. Cursor's team settings are where auto-run, sandboxing and the MCP allowlist are actually enforced, and that is where you fix what the connector finds. Anomity complements Cursor the way it complements the network, EDR, DLP, GRC and SIEM stack: it shows whether those settings are in place, checks the MCP servers people add against one allowlist across every agent, and enforces policy at the agent hook on each managed device." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Anomity Integrates with Cursor", "item": "https://anomity.ai/blog/anomity-cursor-integration/" } ] } ```