To kanaler, to angrebsflader
Udviklere bruger AI to steder. Hvert sted har et forskelligt dataflow. Hvert kræver en forskellig sikkerhedskontrol.
IDE-integreret AI — Cursor, GitHub Copilot, VS Code-udvidelser og Claude Desktop kan læse dit projekt. Kodefiler, konfigurationsfiler og miljøvariabler er alle inden for rækkevidde. AI-modellen modtager det, udvikleren indsætter, eller hvad klienten henter fra projektkonteksten.
Browserbaseret AI — Claude.ai, ChatGPT og Gemini kører i browseren. Udviklere indsætter kode, stack traces og fejlmeddelelser via browserens tekstfelter. Teksten sendes direkte til AI-udbyderen. Intet filter sidder imellem.
Begge kanaler eksponerer følsomme data for AI-udbydere. Begge kræver kontroller. Men den rette kontrol for hver kanal er forskellig. Et team, der kun dækker én kanal, har kun beskyttet halvdelen af udviklernes arbejdsgang.
IDE-laget: MCP-serveren
For brugere af Claude Desktop og Cursor er Model Context Protocol (MCP) det rette sikkerhedslag.
MCP sidder mellem AI-klienter og AI-model-API'er. MCP-serveren læser alle data i denne grænseflade, inden de når modellen.
Denne position muliggør tre ting:
Fjernelse af nøgler og hemmeligheder — API-nøgler, databasestrenge, auth-tokens og interne URL'er opdages og erstattes med sikre tokens inden afsendelse. Modellen modtager [API_KEY_1] i stedet for den reelle nøgleværdi.
Brugerdefinerede kodemønstre — Teams kan tilføje tilpassede matchregler for interne produktkoder, kunde-ID'er og servicenavne. Standardværktøjer til PII kender ikke disse mønstre. Tilpassede regler kører i MCP-serveren inden data forlader systemet.
Ingen forstyrrelse af udviklingsarbejdet — Udvikleren bruger Cursor eller Claude Desktop præcis som før. MCP-serveren kører mellem klient og API. Udvikleren mærker ingen forskel. De får den samme AI-hjælp.
GitHub Octoverse 2024 registrerede 39 millioner lækede hemmeligheder på GitHub — en stigning på 25 % år over år. Den samme vane, der driver disse lækager, driver også lækager via IDE-AI. Legitimationsoplysninger ender i committed kode. De ender også i indsat kontekst. MCP-serverinterception dækker AI-kanalen af dette samme mønster.
Se også: MCP Server PII-sikkerhed i 2026
Browserlaget: Chrome-udvidelsen
For browserbaseret AI — Claude.ai, ChatGPT, Gemini — er en Chrome-udvidelse den rette kontrol.
Udvidelsen kører som et indholdsscript på hver AI-platform. Den læser tekst, inden udvikleren indsender den. Den finder følsomt indhold — navne, hemmeligheder og kodemønstre, du definerer — og maskerer dem, inden teksten når AI-udbyderen.
De to lag dækker forskellige kanaler:
MCP-serveren dækker — al AI-brug via Claude Desktop eller Cursor. Kodegennemgang, fejlfindingssessioner og projektkontekstforespørgsler går alle gennem dette lag.
Chrome-udvidelsen dækker — al browserbaseret AI-brug. Claude.ai, ChatGPT, Gemini, Perplexity og enhver anden AI-grænseflade i browseren. Dette inkluderer udviklere, der bruger browser-AI til dokumentationsarbejde eller spørgsmål, de foretrækker at holde uden for IDE'en.
Se også: Blokering vs. anonymisering til browser-DLP
Hvad kombineret dækning ser ud som
Et udviklingsteam, der kører begge lag, opnår fuld dækning. Sådan fungerer det i praksis.
En udvikler bruger Cursor med Claude til at fejlfinde et live problem. MCP-serveren fjerner hemmeligheder fra stack tracen, inden Claude ser det. Ingen nøgler sendes.
Den samme udvikler åbner derefter Claude.ai i browseren til et arkitekturspørgsmål. De inkluderer en intern service-URL. Chrome-udvidelsen fjerner URL'en, inden den sendes. Ingen intern URL når Claude.
En kollega bruger ChatGPT til dokumentationshjælp. De indsætter kode med en API-nøgle. Chrome-udvidelsen opfanger nøglen, inden den sendes til OpenAI. Ingen nøgle eksponeres.
Ingen af kanalerne eksponerer hemmeligheder eller følsom kode for AI-udbydere. Begge udviklere bruger AI til rigtige arbejdsopgaver. Sikkerhedsteamet har tekniske kontroller på begge kanaler — ikke blot politikregler.
CVE-2024-59944 viser ét eksempel på det bredere mønster. Udvikler-AI-værktøjer uden interceptlag er en lækagekanal. To-lagsmodellen er det direkte svar på denne risiko.
Se også: PII-lækage via AI-kodningsassistenter i produktion
Hvorfor ét lag ikke er nok
Nogen teams blokerer browser-AI og stoler udelukkende på IDE-værktøjer. Andre tillader browser-AI men dækker ikke IDE'en. Begge tilgange efterlader et hul.
En udvikler, der bruger Cursor på arbejdet, kan også åbne ChatGPT i en browserfane for at tjekke et hurtigt spørgsmål. En IDE-kun kontrol fanger ikke det. En browser-kun kontrol fanger ikke IDE-sessionen. Begge kanaler er aktive i en rigtig udviklerhverdag.
To-lagsmodellen dækker begge. Den kræver ikke, at udviklere undgår den ene eller den anden kanal. Den kører stiltiende begge steder.
anonym.legal tilbyder begge lag: en MCP-server til IDE-integreret AI og en Chrome-udvidelse til browserbaseret AI. Begge kører på den samme detektionsmotor — 273 entitetstyper, 48 sprog, reversibel kryptering.