Cursor en privacy: privacy mode, dataopslag en wat je als bedrijf regelt

Privacy mode

Privacy mode: wat het wel doet, en de drie gaten die erin zitten

Privacy mode is de belangrijkste schakelaar in Cursor, en tegelijk de meest verkeerd begrepen. De officiële formulering is precies: met privacy mode aan wordt je code nooit gebruikt voor training, niet door Cursor en niet door de modelaanbieders. Cursor onderhoudt daarnaast zero-data-retention-afspraken (ZDR) met alle aanbieders, wat betekent dat die je invoer en uitvoer niet opslaan. Let op wat er niet staat: privacy mode betekent niet dat je code je machine niet verlaat. Dat doet hij wel, elke prompt opnieuw. Privacy mode gaat over wat er aan de andere kant met die data gebeurt, niet over of hij verstuurd wordt.

Gat 1: risk classifiers blijven draaien

Ook met privacy mode aan mogen modelaanbieders classifiers draaien die schendingen van hun eigen gebruiksvoorwaarden detecteren. Data die daar uitspringt kan tijdelijk bewaard blijven voor onderzoek. Dat is standaard bij vrijwel elke commerciële LLM-aanbieder, maar het betekent dat "zero retention" niet honderd procent letterlijk is. Voor een verwerkersregister of een DPIA is dit het soort detail dat je expliciet moet benoemen in plaats van wegpoetsen.

Gat 2: je eigen API-sleutel valt erbuiten

Gebruik je een eigen sleutel van OpenAI, Anthropic of Google in Cursor (BYOK), dan vervalt de ZDR-afspraak. Cursor is daar onomwonden over: de dataverwerking volgt dan het privacybeleid van jouw aanbieder, niet dat van Cursor. Voor een bedrijf dat BYOK inzet om "meer controle" te hebben is dat vaak een verrassing, want in de praktijk lever je juist de contractuele bescherming in die je via Cursor wel had. In de beveiligingsaanbevelingen van Cursor staat daarom letterlijk het advies om BYOK te beperken als je de ZDR-garanties wilt behouden.

Gat 3: sommige modellen vallen buiten de ZDR-afspraken

Een klein aantal modellen eist dataretentie bij de aanbieder en valt daarmee buiten de ZDR-paraplu. Die staan standaard uit en vereisen goedkeuring door een beheerder. Het concrete voorbeeld in de documentatie is Claude Fable 5: Anthropic bewaart daarbij invoer en uitvoer om automatische en menselijke reviews op schadelijk gebruik te draaien, maar gebruikt die data volgens Cursor niet voor training of productverbetering. Anthropic verwijdert het bewaarde materiaal daarna automatisch en permanent na dertig dagen, traint er Claude niet op en deelt het niet met andere klanten. Het is dus een reviewvenster, geen open archief. Voor Enterprise-klanten en voor iedereen met privacy mode aan falen verzoeken naar dat model totdat het retentiebeleid in het dashboard is goedgekeurd, en die opt-in geldt voor het hele team. Als een verzoek naar Fable 5 tegen een van de guardrails aanloopt, routeert Cursor het automatisch door naar Claude Opus.

Wat er gebeurt als privacy mode uitstaat

Dit is de zin die elke Nederlandse werkgever moet lezen voordat hij Cursor uitrolt. Met privacy mode uit mag Cursor codebase-data, prompts, editor-acties, codefragmenten en andere code- en actiedata gebruiken en opslaan om de AI-functies te verbeteren en de eigen modellen te trainen. Voor een individuele gebruiker die zelf niets aanzet, is dat de uitgangssituatie. Voor je bedrijfscode betekent het dat proprietary logica, interne API-structuren en soms zelfs klantnamen in commentaarregels onderdeel worden van trainingsdata. Dit is precies het scenario dat je met beleid moet uitsluiten, niet met vertrouwen.

Instellen

Aanzetten, afdwingen en controleren: wie bepaalt het eigenlijk?

Privacy mode is per gebruiker een schakelaar, en per organisatie een beleidsinstelling. Dat onderscheid is het hele verhaal. Op een individueel account is privacy mode wel beschikbaar maar niet de standaard: je moet hem zelf aanzetten. Voor Teams staat hij standaard aan voor alle teamleden, en voor Enterprise-teams staat hij ook standaard aan. Een beheerder kan hem bovendien organisatiebreed afdwingen zodat leden hem niet kunnen uitzetten.

De MDM-policy die het gat dichttrekt

Team-brede afdwinging beschermt je team-account, maar niet je laptop. Een medewerker kan uitloggen en inloggen met zijn privé-account, en daar geldt jouw beleid niet. Cursor lost dat op met de Allowed Team IDs-policy. De instelling cursorAuth.allowedTeamId accepteert een lijst met team-ID's, gescheiden door komma's, bijvoorbeeld "1,3,7". Logt iemand in met een team-ID dat er niet bij staat, dan wordt hij direct geforceerd uitgelogd, krijgt hij een foutmelding en kan hij pas verder met een geldig ID. Via je device-management rol je die centraal uit met de AllowedTeamId-policy, die de lokale instelling overschrijft. Cursor ondersteunt MDM-policies op macOS en Intune of Group Policy op Windows. Dit is de enige harde rem op privé-accounts op bedrijfsapparatuur, en Cursor noemt het zelf de belangrijkste MDM-policy.

Controleren of het ook echt zo staat

Op Enterprise-plannen loggen de audit logs wijzigingen in privacy mode expliciet, met een scope die aangeeft of het om een gebruiker of om het hele team ging. Dat maakt van "wij hebben privacy mode aan" een controleerbare uitspraak in plaats van een aanname. Wie geen Enterprise-plan heeft, moet het periodiek handmatig verifiëren, bijvoorbeeld tijdens een halfjaarlijkse check op de instellingen van je AI-tooling.

Welke versie je controleert

Instellingen verhuizen. De stabiele build op 3 augustus 2026 is 3.14.7 volgens Cursors eigen download-API, en er is in de 3.x-lijn al minstens één menu-verhuizing gedocumenteerd (de hiërarchische ignore-instelling ging in 3.11 naar Cursor Settings, Indexing, Ignore Files). Zit je op een oudere build en vind je een instelling niet, controleer dan eerst je versienummer. Meer over installeren en bijwerken staat op Cursor installeren.

Datastromen

Waar je code naartoe gaat: twee stromen, en maar één ervan slaat op

Cursor beschrijft in de enterprise-documentatie twee manieren waarop data je lokale omgeving verlaat. Dat model is nuttig omdat het de vraag "slaat Cursor mijn code op?" scherper maakt dan een ja of nee. Het antwoord is: standaard niet blijvend, met één duidelijke uitzondering die je zelf kunt uitzetten.

Cloud Agents zijn de enige functie die code opslaat

Cursor is hier expliciet: Cloud Agents zijn de enige functie waarvoor Cursor je code moet opslaan. Anders dan bij indexering of een gewoon modelverzoek heeft zo'n agent langere tijd toegang tot je repository nodig om wijzigingen te maken. De architectuur is een geïsoleerde virtuele machine per agent, gescheiden van andere agents en gebruikers. Opgeslagen worden versleutelde kopieën van de repositories waaraan de agent werkt, alleen tijdens de looptijd, en die worden na afloop verwijderd. En dan het bruikbaarste zinnetje uit de hele documentatie voor een bedrijf met een streng beveiligingsbeleid: Cloud Agents zijn optioneel, en als je beleid opslag van code verbiedt, zet je ze gewoon niet aan. Alle andere functies van Cursor blijven dan gewoon werken.

De bestandscache die weinig mensen kennen

Cursor cachet tijdelijk bestandsinhoud op de eigen servers om latency en netwerkverkeer te beperken. Die bestanden worden versleuteld met unieke, door de client gegenereerde sleutels, en die sleutels bestaan op Cursors servers alleen voor de duur van het verzoek. De gecachete inhoud is tijdelijk en wordt onder privacy mode nooit trainingsmateriaal. Het is geen probleem, maar het is wel een verwerking die je in je register mag noemen als je volledig wilt zijn.

Versleuteling en eigen sleutels

Cursor versleutelt data met TLS 1.2 of hoger onderweg en AES-256 in rust, voor de hele infrastructuur. Enterprise-klanten kunnen daarbovenop Customer Managed Encryption Keys (CMEK) inzetten: embeddings en Cloud Agent-data worden dan versleuteld met jouw eigen sleutel, en jij beheert rotatie en toegang. Dat is de zwaarste variant en vereist contact met sales; het is geen self-servicefunctie.

Wat de agent zelf mag op je machine

Los van waar data heen gaat, is er de vraag wat de agent lokaal mag doen. Standaard vragen terminalcommando's om goedkeuring en moeten gevoelige acties handmatig worden geaccordeerd. Netwerkverzoeken zijn met standaardinstellingen beperkt tot GitHub, directe links en de zoekproviders; de agent kan geen willekeurige netwerkverzoeken doen. Elke MCP-toolaanroep vraagt afzonderlijk om goedkeuring, tenzij je specifieke tools op een allowlist zet. Meer over hoe die agent werkt staat op Cursor functies.

Indexering

Codebase-indexering: wat gaat er omhoog en wat blijft lokaal?

Om semantisch te kunnen zoeken bouwt Cursor een index van je project. Daarvoor gaat je codebase in kleine stukjes naar Cursors servers om embeddings te berekenen. Dit is de stap waar veel securityteams over struikelen, en terecht: het is de enige functie waarbij je hele repository in delen langs een externe server komt, ook als je verder niets vraagt.

De tegenstrijdigheid die we niet gaan wegpoetsen

Twee officiële Cursor-bronnen zeggen niet hetzelfde over bestandsnamen. Op cursor.com/data-use staat dat de embeddings en metadata over je codebase, zoals hashes en bestandsnamen, in de database van Cursor kunnen blijven staan. In de zoekdocumentatie staat daarentegen dat Cursor embeddings maakt zonder bestandsnamen of broncode op te slaan, dat bestandsnamen geobfusceerd worden en codechunks versleuteld. Wat vaststaat en in beide bronnen terugkomt: platte broncode wordt niet blijvend opgeslagen, en embeddings wel. Over de precieze status van bestandsnamen, geobfusceerd of opgeslagen, spreken de twee pagina's elkaar tegen. Als bestandsnamen in jouw organisatie zelf gevoelig zijn, bijvoorbeeld omdat ze klantnamen of projectcodes bevatten, stel die vraag dan schriftelijk aan Cursor voordat je uitrolt.

Je eigen sleutel voor bestandspaden

Je kunt de versleuteling van bestandspaden zelf aansturen met een bestand .cursor/keys in de root van je workspace, waarin je een path_decryption_key meegeeft. Dat is een kleine maar reële controle die zelden genoemd wordt in Engelstalige overzichten.

Uitsluiten van indexering versus uitsluiten van toegang

Cursor kent twee ignore-bestanden en het verschil is belangrijk. .cursorignore blokkeert bestanden voor Agent, Tab, Inline Edit en @-verwijzingen: de AI komt er niet bij. .cursorindexingignore sluit bestanden alleen uit van indexering; ze blijven wel beschikbaar voor de AI-functies, maar duiken niet op in codebase-zoekopdrachten. Dat tweede is bedoeld voor grote gegenereerde bestanden of vendor-code die je index vervuilen, niet voor geheimen. Standaard negeert Cursor al alles wat in je .gitignore staat plus een ingebouwde lijst met lockfiles, .env-bestanden, node_modules, __pycache__, binaries, media en archieven.

Wat Cursor zelf zegt over de grenzen hiervan

Belangrijk genoeg om letterlijk over te nemen: .cursorignore is geen beveiligingsgrens. De documentatie noemt drie beperkingen. Volledige bescherming is niet gegarandeerd vanwege de onvoorspelbaarheid van LLM's. De terminal en de MCP-servertools die de agent gebruikt kunnen toegang tot code die onder .cursorignore valt niet blokkeren. En gebruikers kunnen genegeerde bestanden gewoon zelf openen. Voor echte beveiliging verwijst Cursor naar bestandsrechten op je besturingssysteem of versleuteling van de data zelf. Zet geheimen dus niet in je repository en vertrouw niet op een ignore-bestand als laatste verdedigingslinie.

Aanbevolen patronen om vandaag toe te voegen

De documentatie geeft een concrete lijst globale patronen om standaard in elk project op te nemen, telkens met de recursieve globstar-prefix zodat ze in elke submap gelden: .env, .env met willekeurige extensie, credentials.json, secrets.json, alle .key-bestanden, alle .pem-bestanden en id_rsa. Dat kost je vijf minuten en dekt de meest voorkomende ongelukken af.

EU en dataresidentie

Kan de verwerking binnen de EU? Nu nog niet, en dit is precies wat er wel kan

Dit is de vraag waar Nederlandse bedrijven op vastlopen, en waar de Engelstalige artikelen over Cursor niets over zeggen. Het antwoord per 3 augustus 2026 is helder en ongemakkelijk: Cursor biedt dataresidentie aan, maar alleen als US-only. Er is geen algemeen beschikbare EU-dataresidentie. Wat er voor Europa wel is, is inference-only dekking voor de EU plus IJsland, uitsluitend op aanvraag. Opslag en dataverwerking vallen daar dus niet onder.

Wat US-only dataresidentie precies inhoudt

Voor wie het overweegt, en het is voor Nederlandse bedrijven vaker relevant dan je denkt omdat het in elk geval de willekeur wegneemt. Dataresidentie werkt over drie onafhankelijke lagen: inference draait volledig in de gekozen regio, datapijplijnen die je content raken draaien alleen daar, en Customer Data wordt alleen daar opgeslagen, inclusief back-ups. In de regio blijven dan onder meer Tab, bewerken, autocomplete, semantisch zoeken en het volledige gebruik van Cloud Agents. Alleen bepaalde modelfamilies draaien in-region: GPT-modellen, Claude 4.6 en hoger, Gemini 2.5 Flash, Composer en Grok 4.5. Kies je een model dat er niet bij staat, dan krijg je een foutmelding, en Auto kiest alleen nog uit die lijst. Er geldt een opslag van 10 procent op de modelprijzen, die Cursor in dollars publiceert. Het is een Enterprise-functie, wordt per team ingeschakeld door je account team, en je moet rekenen op maximaal twee weken doorlooptijd. Reist een gebruiker naar het buitenland, dan blijft het verkeer naar de Amerikaanse infrastructuur lopen, met wat extra latentie.

Wat er zelfs met dataresidentie aan buiten de regio kan vallen

Cursor publiceert hiervan een eerlijke lijst, en die verdient aandacht omdat het precies de functies zijn die mensen dagelijks gebruiken. Buiten de regiogarantie vallen: SSO en authenticatie, die altijd via Cursors identityprovider WorkOS lopen. Codebase-indexering, als je codebase zelf buiten de Verenigde Staten staat. BYOK, waarvoor dataresidentie niet ondersteund wordt. Custom modellen via een eigen base-URL of een gateway van derden, die de regio van die gateway dragen. MCP-servers en externe integraties zoals @Web en @Docs, die elk hun eigen regio hebben. Bugbot en code review, die draaien waar je repositories staan. Gedeelde links die buiten het team terechtkomen. En Cloud Agents die vanuit Slack of het web gestart worden, waarvan de regio van het startcommando niet gegarandeerd kan worden.

Wat dit concreet betekent voor een Nederlands bedrijf

Praktisch gesproken verwerk je persoonsgegevens die in code, commentaar of prompts zitten in beginsel buiten de Europese Economische Ruimte. Je leunt daarbij op de verwerkersovereenkomst van Cursor en op de afspraken met de subverwerkers. Cursor stelt zelf dat de DPA uitgebreide gegevensbeschermingsverplichtingen bevat volgens marktstandaarden, waaronder dataminimalisatie, toegangscontrole en veilige verwerking, en dat alle subverwerkers onder passende verwerkersovereenkomsten vallen. Wij doen hier geen juridische uitspraak over of dat in jouw situatie volstaat. Dat is een beoordeling voor je functionaris gegevensbescherming of privacyjurist, op basis van hoofdstuk V van de AVG over doorgifte naar derde landen. Wat je wel zelf kunt doen: zorgen dat er zo min mogelijk persoonsgegevens in je codebase zitten, want dat verkleint de vraag tot iets hanteerbaars.

De andere kant: Cursor gebruikt geen infrastructuur in China

Op de beveiligingspagina staat een expliciete vermelding die je in een leveranciersbeoordeling kunt gebruiken: Cursor gebruikt of onderhoudt geen infrastructuur in China, en zet geen bedrijven met een hoofdkantoor in China in als subverwerker. Dat is voor sommige Nederlandse organisaties, zeker in de publieke sector of in gereguleerde ketens, een relevante uitsluiting.

Certificeringen

SOC 2 Type II: wat het wel zegt en wat het niet zegt

Cursor onderhoudt SOC 2 Type II. Dat is de enige certificering die uit primaire bron te bevestigen is. Er is geen vermelding gevonden van ISO 27001, ISO 42001 of andere normen; de helppagina spreekt van "SOC 2 Type II and more" zonder die "more" ergens te specificeren. Wij claimen dus niets anders dan SOC 2 Type II.

Wat een SOC 2 Type II-rapport wel bewijst

Een SOC 2 Type II-attestatie zegt dat een externe auditor over een periode heeft vastgesteld dat de beschreven beheersmaatregelen niet alleen bestaan maar ook werkten. Dat is meer dan een Type I, die alleen een momentopname is. Cursor voegt daaraan toe dat het zich verbindt aan minimaal jaarlijkse penetratietests door gerenommeerde derden, dat elke subverwerker onder een leveranciersrisicoprogramma valt en jaarlijks opnieuw wordt beoordeeld, dat toegang tot infrastructuur volgens least privilege wordt verleend en dat multifactor-authenticatie wordt afgedwongen.

Wat het niet bewijst, en dit is het punt

SOC 2 is een Amerikaans raamwerk voor beheersmaatregelen. Het is geen AVG-conformiteitsverklaring, geen uitspraak over de rechtmatigheid van doorgifte naar de Verenigde Staten en geen vervanging voor je eigen DPIA. Een leverancier die SOC 2 Type II heeft, kan nog steeds data buiten de EER verwerken, en dat doet Cursor ook. Gebruik het rapport dus als bouwsteen in je leveranciersbeoordeling, niet als eindconclusie. Voor de AVG-kant gaat het om de verwerkersovereenkomst, de subverwerkerslijst en je doorgiftetoets, niet om het SOC 2-logo.

Beveiligingslekken melden

Vind je een kwetsbaarheid, dan is het adres security-reports@cursor.com. Cursor zegt toe meldingen binnen 5 werkdagen te bevestigen en kritieke incidenten per e-mail aan getroffen gebruikers te communiceren. Leg dat adres vast in je eigen incidentprocedure, samen met je meldplicht richting de Autoriteit Persoonsgegevens.

Technische controles

Wat je technisch kunt afschermen, en wat een schijnzekerheid is

Cursor maakt zelf een verhelderend onderscheid dat je in je beleid kunt overnemen: er zijn security controls, die deterministisch afdwingen wat een agent niet mag, en er is LLM-steering, die het gedrag van het model bijstuurt maar niets garandeert. Rules, commands en instructiebestanden vallen in de tweede categorie. Wie denkt dat een regel in AGENTS.md een beveiligingsmaatregel is, bouwt op zand.

Run Modes: kies auto-review, niet run everything

Standaard vraagt Cursor om goedkeuring voordat een terminalcommando draait. In Cursor 3.6 en hoger kies je tussen Auto-review, Allowlist en Run Everything. Auto-review draait commando's die op de allowlist staan, plaatst shell-commando's in een sandbox waar dat kan, en stuurt de rest langs een classifier die op basis van veiligheid en aansluiting op jouw bedoeling toestaat of blokkeert. Dat is de aanbevolen instelling in Cursors eigen hardeningsdocumentatie, met sandboxing aan. En de bijbehorende waarschuwing die je moet doorgeven aan je team: een allowlist is best-effort, geen beveiligingsgrens. Vastberaden agents of prompt injection kunnen eromheen. Combineer hem daarom altijd met hooks.

Hooks: de plek waar je echt controle hebt

Hooks laten je eigen logica draaien op vier momenten in de agent-loop, en dit is voor een securityteam veruit de interessantste functie. Vóór het versturen van een prompt kun je scannen op API-sleutels, inloggegevens, persoonsgegevens of vertrouwelijke informatie en de verzending blokkeren. Vóór het lezen van een bestand kun je toegang tot configuratiebestanden met geheimen weigeren. Ná het genereren van code kun je scannen op kwetsbaarheden of op weggelekte sleutels. En vóór het uitvoeren van een commando kun je bijvoorbeeld alle git push-commando's blokkeren, elk sudo-commando door een goedkeuringsproces sturen of database-DROP-statements tegenhouden. Zet failClosed op kritieke hooks, zodat een falende hook de actie blokkeert in plaats van doorlaat.

Audit logs en wat er níet in staat

Op Enterprise loggen audit logs authenticatie, gebruikersbeheer, API-sleutels, teaminstellingen, uitgavenlimieten, repositorybeheer, Cloud Agent-omgevingen, directory-groepen, wijzigingen in privacy mode, team rules en team commands. Ze zijn te bekijken in het dashboard en te streamen naar een SIEM zoals Splunk, Datadog of Sumo Logic, naar een webhook of naar een S3-bucket; dat regel je via hi@cursor.com. Belangrijk voor je verwachtingsmanagement: Cursor logt geen agent-antwoorden en geen gegenereerde code. Wil je prompts en gegenereerde code vastleggen voor compliance, dan verwijst Cursor je naar hooks. Dat is technisch mogelijk, maar het betekent wel dat je zelf een systeem inricht dat prompts opslaat, en dan komt de medezeggenschapskant om de hoek kijken (zie hieronder).

Netwerk en connectiviteit

Voor netwerkbeheerders: Cursor adviseert het domeinpatroon *.cursor.sh op de allowlist te zetten en de Cursor-domeinen uit te zonderen van SSL-inspectie. Voor Cloud Agents kun je egress instellen op Default plus allowlist of op Allowlist-only. Per MCP-server kun je een eigen netwerkbeleid opleggen. Dit zijn precies de punten die je vooraf met je netwerkbeheer wilt afstemmen, want anders wordt Cursor door je proxy of endpointbeveiliging gebroken en gaan mensen alsnog buiten de gebaande paden werken.

Extensies

De extensiekant: een supply chain die niet die van Microsoft is

Cursor is een fork van VS Code, maar haalt extensies niet uit de Microsoft VS Code Marketplace. Ze komen uit de Open VSX-registry. Dat lijkt een detail voor developers en is in werkelijkheid een risicopost die in vrijwel geen enkele Nederlandse beoordeling van Cursor voorkomt.

Waarom dit een securityvraag is

Cursor waarschuwt hier zelf voor, en het is de moeite waard om die waarschuwing letterlijk door te geven: dezelfde publisher.extension-naam kan op Open VSX naar een andere uitgever of andere code wijzen dan op de Microsoft Marketplace. Behandel extensie-ID's daarom als dependencies en installeer alleen van uitgevers die je vertrouwt. Cursor routeert het zoeken en downloaden van extensies via een eigen marketplace-proxy en draait daar automatische malware- en supply-chain-analyse op; extensies die zakken voor die controle worden geblokkeerd. Voor een aantal veelgebruikte extensies die alleen in de Microsoft Marketplace staan, publiceert Cursor eigen gecontroleerde Anysphere-varianten.

Wat je als beheerder kunt afdwingen

Drie knoppen, en er zit een adder onder het gras bij de eerste. Met de instelling extensions.allowed bepaal je welke extensies geïnstalleerd mogen worden. Dat is een allowlist-model: zodra je één regel toevoegt, is alles wat niet expliciet is toegestaan geblokkeerd. Er is geen impliciete "sta alles toe"-terugval. Wil je alleen een specifieke uitgever blokkeren en de rest toestaan, dan moet je expliciet een wildcard-regel toevoegen die alles toestaat, naast de regel die je weigert. Team-beheerders configureren dit in het dashboard onder Security & Identity; welke minimale clientversie daarvoor nodig is, konden wij niet in de documentatie terugvinden. via MDM overschrijft de AllowedExtensions-policy zowel het dashboard als de lokale instelling. De tweede knop is Marketplace Install Cooldown, waarmee je installaties en updates uitstelt tot een versie een minimaal aantal uur publiek is; standaard staat die op 0, dus uit. De derde is verplichte handtekeningverificatie van Open VSX-extensies. Cursor nuanceert zelf: cooldown en handtekeningverificatie zijn clientseitige installatiecontroles, ze vullen de analyse op marketplace-niveau aan maar vervangen die niet.

Plugins uit de Cursor Marketplace

Naast extensies is er de Cursor Marketplace met plugins. Die worden volgens Cursor stuk voor stuk handmatig beoordeeld voordat ze verschijnen, moeten open source zijn, bevatten geen binaries en respecteren je bestaande MCP-allowlist en blocklist. Ook updates worden handmatig beoordeeld; plugins worden niet automatisch uit de broncode bijgewerkt. Blijkt een plugin een risico, dan wordt hij direct verwijderd. Het blijft software van derden, dus het advies om de broncode zelf te bekijken voordat je een plugin voor je hele team aanzet, staat los van wat Cursor er zelf over zegt.

De praktische regel voor je team

Zet een allowlist met de uitgevers die je organisatie al gebruikt, zet install cooldown op een waarde boven nul, en spreek af dat een nieuwe extensie via een ticket gaat in plaats van via een impuls. Dat is dezelfde discipline die je op npm-packages toepast, alleen dan op de editor zelf.

AVG

Wat je als Nederlandse werkgever moet regelen

Cursor is een verwerker van gegevens die jij als verwerkingsverantwoordelijke aanlevert. Zodra je bedrijfscode door Cursor laat lezen, ben jij degene die moet kunnen uitleggen wat er verwerkt wordt, waar, op welke grondslag en met welke waarborgen. Hieronder staat wat je concreet vastlegt. Dit is geen juridisch advies; laat de beoordeling doen door je functionaris gegevensbescherming of privacyjurist.

De verwerkersovereenkomst en de subverwerkers

De DPA staat op cursor.com/dpa (ook bereikbaar als cursor.com/terms/dpa) en de Master Service Agreement op cursor.com/msa. De partij waarmee je contracteert is Anysphere, Inc. De subverwerkerslijst staat publiek op trust.cursor.com/subprocessors en wordt volgens Cursor jaarlijks opnieuw beoordeeld. Zet in je eigen proces dat je die lijst minstens één keer per jaar naast je register legt, want daar staan de modelaanbieders en inference-partners in waar je code feitelijk langskomt.

Persoonsgegevens in code zijn echte persoonsgegevens

Het meest gemaakte denkfoutje: "wij verwerken alleen code, geen persoonsgegevens." In de praktijk zitten er persoonsgegevens in testdata, in fixtures, in seed-scripts, in commentaarregels met klantnamen, in logbestanden die je erbij haalt en in de tickets die je in je prompt plakt. Dat is verwerking, en die telt. De meest effectieve maatregel is niet contractueel maar praktisch: haal echte persoonsgegevens uit je testdata en houd productiedumps buiten je ontwikkelomgeving. Dat verkleint de vraag van "mag dit" naar "hier valt weinig te lekken".

Wat je medewerkers wel en niet mag laten doen

Leg dit vast in gewone taal, niet in juridisch jargon, want anders leest niemand het. Een werkbare basis: privacy mode staat aan en dat controleer je centraal. Inloggen met een privé-account op een bedrijfsapparaat mag niet, en dat dwing je af met de MDM-policy voor toegestane team-ID's. Repositories met bijzondere persoonsgegevens of met gegevens onder een geheimhoudingsplicht staan op een blocklist en gaan Cursor niet in. Cloud Agents zijn uit tenzij expliciet toegestaan, omdat dat de enige functie is die code opslaat. Eigen API-sleutels zijn niet toegestaan, want daarmee vervalt de zero-retention-afspraak. Geheimen komen niet in de repository, en de aanbevolen ignore-patronen staan in elk project. Nieuwe extensies en MCP-servers gaan via een goedkeuring.

De medezeggenschapskant die vaak wordt overgeslagen

Zodra je hooks inzet om prompts, gegenereerde code of commando's te loggen, bouw je een systeem dat het gedrag van medewerkers vastlegt. Dat is in Nederland niet vrij: op grond van artikel 27 van de Wet op de ondernemingsraden heeft de ondernemingsraad instemmingsrecht bij regelingen rond personeelsvolgsystemen. Hetzelfde geldt voor de analytics- en AI-code-trackingfuncties waarmee je per gebruiker kunt zien hoeveel er met AI geschreven wordt. Bespreek dat vooraf met je OR of personeelsvertegenwoordiging en leg het doel vast (compliance en beveiliging, niet individuele prestatiebeoordeling). Doe je dat niet, dan loopt een technisch nette uitrol alsnog stuk op een arbeidsrechtelijk bezwaar.

Wat wij hier niet doen

Wij geven geen oordeel over de vraag of doorgifte naar de Verenigde Staten in jouw situatie rechtmatig is, of jouw DPIA verplicht is, of welke grondslag past. Dat hangt af van je sector, je gegevens en je risicoprofiel. Wat deze pagina wel doet, is de feiten leveren waarmee je die beoordeling kunt maken zonder dat je zelf door Engelstalige documentatie hoeft te spitten. Voor de bredere AI-governance rond je hele toolstack is AI-governance het begrip waarmee je verder zoekt.

AI-verordening

De EU AI Act-kant: welke verplichtingen raken dit gebruik echt?

Er wordt veel gesuggereerd over de EU AI Act en AI-codetools, meestal in de richting van "dit wordt verboden" of "dit is hoog-risico". Voor een AI-code-editor klopt geen van beide. De verplichtingen die je wel raken zijn concreter en minder spannend, maar ze bestaan.

AI-geletterdheid geldt nu al

De verplichting rond AI-geletterdheid is sinds februari 2025 van kracht en geldt breed: organisaties moeten ervoor zorgen dat medewerkers die met AI-systemen werken daar voldoende kennis van hebben, passend bij hun rol en context. Voor een ontwikkelteam dat een agentische editor gebruikt betekent dat concreet: mensen moeten weten wat er met hun code gebeurt, wat een model wel en niet betrouwbaar doet, en waarom gegenereerde code nog steeds gereviewd moet worden. Dit is de enige AI Act-verplichting die vandaag al hard geldt voor vrijwel elke Nederlandse werkgever die Cursor uitrolt.

Is een AI-code-editor hoog-risico?

In de regel niet. De hoog-risicocategorieën uit Annex III gaan over toepassingen die mensen direct raken, zoals recruitment, kredietverlening, onderwijs en kritieke infrastructuur. Code schrijven valt daar niet onder. De kanttekening: het systeem dat je met Cursor bóuwt kan wel hoog-risico zijn. Bouw je een CV-screeningtool, dan gelden de eisen voor dat product, en dan is de vraag hoeveel van die code door een agent geschreven is ineens onderdeel van je technische documentatie en je risicobeheersing. Meer over de tijdlijn en het uitstel via het Digital Omnibus-pakket staat in ons artikel over de EU AI Act-deadline van augustus 2026.

De AI Act is nu al merkbaar in wat je kunt kiezen

Dit is het scherpste en meest verifieerbare voorbeeld dat we konden vinden, en het komt van Cursor zelf. Over de lancering van Grok 4.5 schrijft Cursor dat het model beschikbaar is in elk land dat Cursor normaal ondersteunt, behalve in de EU, omdat de EU AI Act voorschrijft dat toezichthouders geïnformeerd moeten worden voordat krachtige nieuwe AI-modellen worden uitgebracht; EU-beschikbaarheid zou in de weken daarna volgen. Voor een Nederlandse lezer is dat een tastbaar gevolg: een van de goedkoopste modellen in Cursor was bij lancering hier niet te kiezen. Of dat inmiddels is veranderd, konden wij op het moment van schrijven niet vaststellen. Meer over de modelkeuze en wat die kost staat op Cursor modellen en prijzen.

Transparantie richting je eigen klanten

De transparantieverplichtingen uit de AI Act gaan over AI-systemen die met mensen communiceren en over gegenereerde content. Code die je met Cursor schrijft en vervolgens zelf reviewt en uitlevert valt daar niet onder. Lever je software met een chatbot of met AI-gegenereerde output erin, dan gelden die verplichtingen voor dat product. Houd de twee vragen dus uit elkaar: hoe je code maakt, en wat je product doet.

Shadow AI

Shadow AI: het echte risico is niet Cursor, het is Cursor zonder beleid

Cursor is gratis te downloaden, installeert in een paar minuten en vraagt geen creditcard. Het gratis Hobby-plan geeft toegang tot Agent, Chat en Tab met beperkt verbruik. Dat betekent dat een developer die hem vanmiddag wil proberen, dat vanmiddag doet. Zonder ticket, zonder inkoopproces, en met een persoonlijk account waarin privacy mode standaard uitstaat. Dat is de meest waarschijnlijke manier waarop jouw bedrijfscode in trainingsdata terechtkomt, en het is geen kwade wil.

Waarom een verbod niet werkt

Het instinct is om Cursor te blokkeren tot er beleid is. In de praktijk levert dat twee dingen op: mensen die het thuis of op een privé-laptop gebruiken, en een IT-afdeling die niet meer weet wat er speelt. De tooling is te goed en het productiviteitsverschil te merkbaar om met een verbod te winnen. De effectievere route is snelheid: zorg dat de goedgekeurde variant er eerder is dan de ongecontroleerde, en maak hem beter dan het gratis alternatief.

De drie maatregelen die het meeste opleveren

Ten eerste: de MDM-policy voor toegestane team-ID's. Dat is de enige maatregel die daadwerkelijk voorkomt dat iemand met een privé-account op een bedrijfslaptop werkt, en Cursor noemt hem zelf de belangrijkste. Ten tweede: een teamplan met privacy mode afgedwongen, zodat de goedgekeurde route ook de prettigste route is (meer verbruik, gedeelde rules, centrale facturatie). Ten derde: SSO en waar mogelijk SCIM, zodat toegang automatisch vervalt als iemand uit dienst gaat. Zonder die derde stap houd je oud-medewerkers met toegang tot een tool die je codebase kent.

Zichtbaar maken wat er al draait

Voordat je beleid schrijft, meet je. Kijk in je netwerklogging naar verkeer richting de Cursor-domeinen, kijk in je software-inventarisatie op beheerde apparaten, en vraag het gewoon aan je teams zonder dat er een sanctie aan hangt. Vrijwel elke organisatie die dit doet, ontdekt dat er al mensen mee werken. Dat is geen incident maar het startpunt van je uitrol, en het is een stuk makkelijker om die mensen naar een teamplan te migreren dan om ze terug te fluiten.

Het gesprek dat je met je developers voert

Wat werkt: uitleggen waarom privacy mode uit een probleem is, met de letterlijke formulering van Cursor erbij dat codebase-data, prompts en codefragmenten dan gebruikt mogen worden om modellen te trainen. Wat niet werkt: dreigen met de AVG. Developers snappen supply chain en dataflow beter dan de meeste juristen; geef ze de feiten en ze regelen het zelf. Precies dat gesprek voeren wij in de Cursor-training, samen met de instellingen die erbij horen.

Stappenplan

Wat je regelt voordat je team ermee begint

Deze volgorde volgt de eigen admin-setupgids van Cursor, aangevuld met de stappen die specifiek voor een Nederlandse organisatie gelden. De eerste zes stappen kosten samen minder dan een dag; de rest is beleidswerk dat je parallel laat lopen.

Open punten

Wat we niet met zekerheid konden vaststellen

Op een pagina die securityteams gebruiken om een besluit te nemen, is een eerlijke onzekerheidslijst meer waard dan een gladde tekst. Dit zijn de punten waar de officiële documentatie geen uitsluitsel geeft, of waar twee officiële bronnen elkaar tegenspreken. Wij vullen die niet in.

Bestandsnamen bij indexering

Cursor.com/data-use zegt dat embeddings en metadata zoals hashes en bestandsnamen in de database kunnen blijven staan. De zoekdocumentatie zegt dat Cursor embeddings maakt zonder bestandsnamen of broncode op te slaan en dat bestandsnamen geobfusceerd worden. Beide zijn officiële Cursor-bronnen. Vraag dit schriftelijk na als bestandsnamen in jouw organisatie gevoelig zijn.

EU-dataresidentie: geen datum, geen prijs, geen voorwaarden

Cursor zegt dat bredere EU-ondersteuning in actieve ontwikkeling is en dat inference-only dekking voor de EU plus IJsland op aanvraag beschikbaar is. Er is geen datum, geen prijs en geen omschrijving van de voorwaarden gepubliceerd. De opslag van 10 procent op de modelprijzen geldt expliciet voor US-only dataresidentie; of die ook voor de EU-optie geldt, is onbekend.

Andere certificeringen dan SOC 2

Alleen SOC 2 Type II is bevestigd, samen met een minimaal jaarlijkse externe penetratietest. Er is geen vermelding gevonden van ISO 27001, ISO 42001 of enige andere norm. De helppagina noemt "SOC 2 Type II and more" zonder die "more" te specificeren. Ga er dus niet van uit dat er meer is.

Beschikbaarheid van Grok 4.5 in de EU

Cursor schreef bij de lancering dat EU-beschikbaarheid in de weken daarna zou volgen, zonder lanceerdatum en zonder concrete EU-datum. Op het moment van schrijven konden wij niet vaststellen of het model inmiddels wel of niet in de EU beschikbaar is. Controleer dit zelf in de modelkiezer voordat je erop begroot.

Wat er tussen versie 3.11 en 3.14.7 is veranderd

De stabiele build op 3 augustus 2026 is 3.14.7 volgens Cursors eigen download-API, maar de changelog toont 3.11 van 10 juli 2026 als laatste genummerde release. Wat er precies in 3.12, 3.13 en 3.14 zit, is niet als genummerde releasenotities gepubliceerd. Voor privacy-instellingen betekent dat: controleer bij twijfel in je eigen client waar een instelling staat, in plaats van te vertrouwen op documentatie die mogelijk een build achterloopt.

Systeemeisen

Cursor publiceert nergens een expliciete lijst met minimale systeemeisen: geen minimale versies van macOS, Windows of Linux, geen RAM- of CPU-eisen, geen schijfruimte. Voor een uitrol op oudere bedrijfslaptops betekent dat je zelf moet testen. Als fork van VS Code ligt de ondergrens in de praktijk in dezelfde orde, maar dat is onze inschatting en geen officiële uitspraak.