By · Last updated 2026-03-29

Tilbage til BlogAI Sikkerhed

39 mio. GitHub-lækager: Risikoen ved AI-kodning

67 % af udviklere har ved et uheld eksponeret hemmeligheder i kode (GitGuardian 2025). 39 millioner hemmeligheder blev lækket på GitHub i 2024 — en stigning på 25 % år over år.

March 29, 20268 min læsning
GitHub secret leaksdeveloper AI securitycredential exposureMCP Server protectionGitGuardian 2025

39 millioner legitimationsoplysninger lækket på ét år

GitHubs Octoverse 2024-rapport afslørede, at 39 millioner hemmeligheder blev lækket på GitHub i 2024. Det er en stigning på 25 % år over år fra 2023. Hemmelighederne inkluderer API-nøgler, databasestrenge, auth-tokens og cloud-legitimationsoplysninger.

Årsagen er velkendt. Udviklere committer kode med hemmeligheder indeni. Hemmelighederne stammer fra fejlfindingssessioner. Eller de er hårdkodet i stedet for gemt som miljøvariabler. Med 39 millioner lækager er dette ikke en sjældenhed. Det er rutine.

AI-værktøjer tilføjer en anden lækagekanal

GitGuardians forskning fra 2025 viste, at 67 % af udviklere ved et uheld har eksponeret hemmeligheder i kode. De samme vaner, der skaber GitHub-lækager, skaber også lækager via AI-værktøjer.

En udvikler indsætter kode i Claude, ChatGPT eller en anden AI-assistent for at få hjælp. Den kode indeholder ofte aktive legitimationsoplysninger. AI-modellen modtager hemmeligheden. Den kan gemme den i samtaleoversigten. Den sender den til udbyderens servere. Udvikleren mister kontrollen — uden advarsel.

Tre eksempler:

Databasefejlfinding. En udvikler indsætter en stack trace. Tracen indeholder forbindelsesstrengen. AI'en læser adgangskoden med.

Pipeline-gennemgang. En udvikler deler et datapipeline-script. Scriptet indeholder en AWS-adgangsnøgle og en hemmelig nøgle. AI'en modtager begge.

API-integrationsgennemgang. En udvikler beder om feedback på en integration. Koden indeholder en aktiv partner-API-nøgle. Nøglen forlader udviklerens netværk.

I hvert tilfælde er målet legitim hjælp. Lækagen af legitimationsoplysningerne er en bivirkning ved at give AI'en tilstrækkelig kontekst. Dette er samme mønster som GitHub-lækager — ikke ondsindet, blot rutine.

CI/CD-pipelines er udsat for den samme risiko

Lækager af hemmeligheder i CI/CD-pipelines steg med 34 % i 2024. Build-scripts, deployment-konfigurationer og infrastruktur-som-kode-filer gennemgås nu alle med AI. Disse filer indeholder ofte cloud-legitimationsoplysninger og servicekontotoken.

Efterhånden som AI-værktøjer dækker mere af udviklercyklussen — gennemgang, dokumentation, fejlfinding, optimering — vokser eksponeringsfladen med dem.

Hvordan MCP-arkitektur blokerer lækager

For teams, der bruger Claude Desktop eller Cursor IDE, placerer Model Context Protocol (MCP) serverarkitektur et legitimationsfilter i stien mellem udvikler og AI-model.

MCP-serveren håndterer al tekst, der bevæger sig gennem sessionen. Indsat kode, stack traces, konfigurationsfiler, fejlfindingskontekst — alt passerer igennem et anonymiseringstrin, inden modellen ser det.

Motoren finder legitimationsmønstre: API-nøgleformater, databasestrenge, OAuth-tokens, private nøglehoveder og brugerdefinerede formater, som dit sikkerhedsteam definerer. Hvert match erstattes med et token inden transmission.

Sådan ser det ud i praksis:

En udvikler indsætter en stack trace med en database-forbindelsesstreng. MCP-serveren erstatter strengen med [DB_CONNECTION_1]. AI'en ser tracen med tokenet på plads. Den yder fejlfindingshjælp baseret på den anonymiserede version. Den faktiske legitimationsoplysning forlod aldrig det interne netværk.

Dette stopper den samme lækagevektor, der fylder GitHub med hemmeligheder. Kanalen er anderledes — AI-værktøjer i stedet for git commits — men løsningen virker på samme måde: blokér det, inden det transmitteres.

Se vores sikkerhedsoversigt for, hvordan anonym.legal håndterer dette på tværs af AI-værktøjer og dokumentarbejdsgange, og compliance-centret for revisionskontroller.

Detektion efter hændelsen er for sent

Nogen teams bruger scanning efter commit til at opfange lækkede hemmeligheder. GitGuardian og truffleHog fungerer godt til GitHub-kanalen. De dækker ikke AI-værktøjssessioner.

Når en hemmelighed når en AI-udbyders servere, er eksponeringen sket. Scanning finder den bagefter. MCP-laget anonymiserer inden modellen ser det overhovedet.

De 39 millioner GitHub-lækager dokumenterer én kanal. Eksponering via AI-værktøjer er det samme problem i en kanal med mindre overvågning og ingen audit trail. Forebyggelse inden transmission dækker begge.

Kilder

Klar til at beskytte dine data?

Begynd at anonymisere PII med 285+ enhedstyper på tværs af 48 sprog.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.