Sikkerhed ved vibe coding: Sådan beskytter du en AI-bygget app

Flere instruktioner til arbejdet med Ailoot findes i dokumentationen.

Hvorfor bliver AI-byggede apps oftere hacket?#

Jeg bygger selv produkter med AI, og jeg bliver ikke paranoid omkring sikkerhed i en grad, hvor jeg vil ”låse alt helt ned”. Men der er et grundlæggende niveau, du ikke må komme under, ellers kan du en dag vågne op til en tom database og en andens kryptominer på din server. Denne guide handler om det grundlæggende niveau. Ikke ”bliv sikkerhedsekspert”, men ”skyd ikke dig selv i foden uden grund”.

Problemets kerne er enkel. Når du beder en AI-agent om at ”bygge en app til booking af kunder”, får den appen til at fungere så hurtigt som muligt. Sikkerhed er ekstra arbejde, som ikke er synligt i en demo. Derfor sættes databasen op som åben, betalingsnøglen havner direkte i koden, og kontrollen af ”har denne bruger adgang?” findes kun i browseren, hvor den kan omgås på et sekund.

Den anden årsag er selve platformene.

Med andre ord opstår hullet af sig selv som standard. Du har ikke gjort noget forkert. Du har bare ikke gjort noget – og inden for sikkerhed betyder passivitet netop ”åbent for alle”.

Og så er der et tredje lag. AI er mere tilbøjelig end mennesker til at lække hemmeligheder. Ifølge GitGuardians rapport fra 2026 offentliggør commits lavet med AI nøgler og adgangskoder i offentlige repositories i omkring 3,2 procent af tilfældene – dobbelt så ofte som normalt. Logikken er klar: Agenten kører git add . og git push uden at se sig for, og din .env-fil med nøglerne bliver offentlig sammen med alt det andet.

Hvad har vibe-kodere allerede lært på den hårde måde?#

Den bedste kur mod skødesløshed er at lære af andres fejl. Her er fire rapporter, der er værd at læse, før du udgiver dit projekt.

Lovable og RLS slået fra. Platformen Lovable bygger apps ud fra tekstbeskrivelser. I 2025 blev der fundet et systemisk hul i dens apps, som fik tildelt CVE-2025-48757. Årsagen: De genererede apps havde ingen adgangsregler på rækkeniveau i databasen (RLS, forklaret nedenfor). En forsker undersøgte et udvalg og fandt 303 eksponerede adgangspunkter på tværs af 170 apps. Navne, telefonnumre, betalingsstatus, andre personers API-nøgler og endda hjemmeadresser blev eksponeret. I omkring 70 procent af de undersøgte apps var beskyttelsen på rækkeniveau helt slået fra.

Tea og følsomme data. Appen Tea (anonyme anmeldelser af personer) mistede omkring 72.000 billeder i juli 2025, herunder 13.000 selfies og billeder af dokumenter, og derefter mere end en million private beskeder. Den tekniske årsag var åben lagring og svage adgangskontroller. Sikkerhedsmiljøet nævner Tea som et tydeligt eksempel: Når en hurtig lancering er vigtigere end at kontrollere tilladelser, er følsomme data det første, der lækker.

Et andet praktisk eksempel. I en sag beskrevet af den oprindelige forfatter blev en vibe-koders app hacket, fordi AI'en satte en standardadgangskode, da databasen blev oprettet – en adgangskode, der kunne gættes automatisk. Derefter fulgte det sædvanlige forløb: De kom ind, installerede kryptominere og overskrev projektet. Serveren måtte slettes fuldstændigt. En standardadgangskode er en ulåst dør med et skilt, hvor der står ”kom bare ind”.

To sikkerhedsfronter: Hvor er du præcis sårbar?#

Når folk taler om ”sikkerhed ved vibe coding”, blander de ofte to helt forskellige bekymringer sammen. Lad os skille dem ad, for du beskytter dig mod dem på forskellige måder.

Første front – selve agenten. Du kører en AI-agent på din computer og giver den adgang til dine filer, terminalen, nøglerne og databasen. Risikoen er, at en agent ikke er et menneske: Den følger instruktioner bogstaveligt og finder den korteste vej, selv hvis den er farlig. Hertil hører også risikoen for, at en andens kommando bliver ”injiceret” i agenten gennem tekst, den læser (det kaldes prompt injection).

Anden front – den færdige app. Det er det, du har udgivet, og som folk bruger. Målet er dit offentliggjorte websted eller din tjeneste: Angribere kommer ind i en åben database, sender falske forespørgsler eller gætter andres konti. Agenten har intet med dette at gøre – hullet blev efterladt tidligere, og andre udnytter det.

Anthropic, virksomheden bag Claude, udtrykker det vigtigste beskyttelsesprincip sådan – og det virker på begge fronter:

I praksis betyder det: Stol ikke på, at AI ”selv lader være med at gøre noget dårligt”. Begræns først, hvad den rent fysisk kan gøre, og bed den derefter om at opføre sig ordentligt. Når dens adfærd svigter – og det vil den gøre – er det kun en hård grænse, du har fastsat på forhånd, der beskytter dig.

Vil du have, at AI arbejder forudsigeligt og holder op med at skyde dig i foden i hvert nyt projekt? Sikkerhedsregler er en del af din Second Brain: Skriv dem én gang i CLAUDE.md, så følger agenten dem i hver forespørgsel.

Hvad kan en AI-agent gøre med adgang til din computer?#

Den mest undervurderede risiko er din egen agent med alt for brede tilladelser. Du behøver ikke engang en ekstern hacker. Her er et nyligt eksempel fra slutningen af maj 2026. En Codex-agent havde brug for administratorrettigheder, som brugeren ikke havde. Agenten gav ikke op – den undersøgte situationen, så at brugeren tilhørte gruppen docker, som i praksis svarer til root, og brugte den adgang.

Der var ingen ondsindede hensigter her. Det er bare sådan, at en agent, der får besked på at ”løse opgaven”, finder en strukturel svaghed hurtigere end et menneske. Og hvis den svaghed giver adgang til dine nøgler eller produktionen, vil den bruge den. Derfor er regel nummer ét mindst mulige privilegium. Giv en agent præcis så meget adgang, som den behøver til en bestemt opgave, og ikke en smule mere.

Hvad kan du gøre i praksis, selvom du ikke er programmør?

1. Kør ikke agenten i tilstanden ”tillad alt” på en produktionsmaskine

   En tilstand, hvor agenten ikke beder om bekræftelse (ofte kaldet bypass eller yolo), er kun til en sandkasse eller et testprojekt, ikke en maskine med aktive nøgler og produktionsadgang.

2. Forbyd agenten at læse hemmeligheder

   I Claude Code gør du det med en regel, der nægter adgang til filer med nøgler. Så selv hvis agenten vil åbne .env, tillader værktøjet det ikke.

3. Hold produktionsnøgler adskilt

   Nøgler til produktionsdatabasen og betalingstjenesten bør ikke ligge i den samme mappe, hvor agenten skriver kode. Hold miljøerne adskilt: Brug testnøgler, når du eksperimenterer.

4. Brug værktøjets sandkasse

   Moderne AI-værktøjer kan køre kommandoer isoleret (i en sandkasse), hvor de ikke har adgang til resten af systemet. I Claude Code reducerer det antallet af tilladelsesanmodninger med omkring 84 procent – så det er også mere praktisk.

En regel, der nægter læseadgang til hemmeligheder i Claude Code, ser omtrent sådan ud – indsæt den i tilladelsesindstillingerne:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Hvor må du aldrig placere API-nøgler og adgangskoder?#

Den billigste og mest almindelige fejl er at lægge nøgler i koden. En API-nøgle til en betalingstjeneste, en databaseadgangskode, et bot-token – alt dette er hemmeligheder. De hører hjemme i en separat .env-fil, og filen skal være angivet i .gitignore, så den ikke kommer med i git sammen med koden.

Derfor er det kritisk: En nøgle overlever ikke længe i et offentligt repository. Bots scanner nye commits døgnet rundt. Det sædvanlige forløb følger: De finder en cloud-nøgle, starter servere til kryptomining på din regning, og om morgenen står du med en regning på titusinder. Udviklere fortæller jævnligt den slags historier, og regningerne løber op i femcifrede dollarbeløb.

Problemets omfang i 2025: 28,65 millioner nye hardkodede hemmeligheder i offentlige repositories, en stigning på 34 procent fra året før. Lækager af nøgler specifikt til AI-tjenester steg med 81 procent. Vibe coding hælder benzin på bålet, fordi agenten committer uden at se sig for.

Det kan du kontrollere manuelt lige nu:

1. Åbn projektets .gitignore-fil

   Sørg for, at den har en .env-linje. Hvis ikke, så tilføj en før den første commit.

2. Gå til dit GitHub-repository

   Kontrollér, at .env-filen ikke ligger der. En hurtig måde at kontrollere det på er at søge i repositoryet efter .env eller en del af din nøgle.

3. Hvis en nøgle er lækket, skal du tilbagekalde og udstede en ny

   Det er ikke nok at slette committen: Nøglen kan allerede være blevet stjålet. Gå til tjenesten (betalingsudbyderen, cloudtjenesten eller AI-udbyderen), tilbagekald den gamle nøgle, og udsted en ny. Det kaldes rotation.

4. Giv nøgler mindst mulige tilladelser

   Hvis en nøgle kun skal bruges til læsning, skal den være skrivebeskyttet. Så kan der stjæles mindre, selv hvis den lækker.

Hvorfor kan alle se din database uden RLS?#

Hvis du bygger en app på Supabase eller en lignende database, er dette det vigtigste afsnit. RLS står for Row Level Security. Enkelt sagt er det en regel, der bestemmer, hvilke rækker i en tabel der vises for en bestemt bruger. Uden den returnerer tabellen ”orders” alle kunders ordrer til alle.

Sådan formulerer Supabase-dokumentationen det selv, helt enkelt:

Og her er den største faldgrube for en vibe-koder. Når du opretter en tabel ved at klikke dig gennem Supabase-dashboardet, slås beskyttelsen automatisk til. Men når AI opretter tabellen – og den næsten altid skriver SQL-kommandoer direkte – forbliver RLS slået fra som standard. Det betyder, at en tabel oprettet af en agent næsten helt sikkert er åben for hele internettet. Det var præcis sådan, de 170 Lovable-apps lækkede.

Gør følgende:

1. Spørg agenten direkte

   Skriv: ”vis mig alle tabeller, hvor RLS er slået fra”. AI'en laver en liste – det er din opgaveliste.

2. Slå RLS til på alle tabeller med brugerdata

   Tilføj også mindst én adgangspolitik – for eksempel ”en bruger kan kun se sine egne rækker”.

3. Kontrollér dashboardet

   I Supabase-dashboardet skal der stå ”RLS enabled” for hver tabel. Hvis markeringen er grå eller rød, betyder det, at tabellen er åben.

4. Test det i praksis

   Log ind som en almindelig bruger, og prøv at hente en andens data. Hvis adgangen afvises, virker politikken.

Hvorfor beskytter tilladelseskontroller i brugerfladen dig ikke?#

En almindelig illusion er: ”Jeg har sørget for, at almindelige brugere ikke kan se administrator-knappen.” Problemet er, at en knap bare er et billede i browseren. En forespørgsel kan sendes direkte til serveren uden at bruge knappen. Hvis serveren ikke kontrollerer tilladelserne igen, udfører den en andens kommando.

Et klassisk eksempel kaldes IDOR. Forestil dig, at du åbner din ordre på en adresse med id=123. Ændr det til id=124, og så kan du se en andens ordre, fordi serveren ikke kontrollerede, om det faktisk var din ordre. Det er et af de mest almindelige huller i vibe-kodede apps, og svage tilladelseskontroller var årsagen til Tea-lækagen.

Reglen er enkel: Gentag alle kontroller af ”må denne bruger gøre dette?” på serveren. Brugerfladen er til bekvemmelighed; beskyttelsen hører hjemme i backend. En instruktion, du kan give agenten: ”tilføj tilladelseskontroller på serversiden for hvert endpoint, der læser eller ændrer brugerdata; stol ikke på, at et element er skjult i brugerfladen.”

Hvordan kan du kontrollere kode for huller, hvis du ikke er programmør?#

Den gode nyhed er, at du i dag kan bede den samme AI om at kontrollere sikkerheden – den gør et rimeligt godt stykke arbejde med at finde almindelige huller. Her er tre værktøjer til forskellige opgaver.

1. Kommandoen /security-review i Claude Code. En engangskontrol af den aktuelle branch for SQL-injektion, XSS, autorisationshuller, datalækager og problemer med afhængigheder. Jeg har forklaret trin for trin, hvordan det fungerer, og hvordan du knytter en automatisk kontrol til hver ændring i en separat guide om sikkerhedsgennemgang i Claude Code. Hovedpointen her: Det er den første forsvarslinje, som startes med én kommando.

2. Det officielle plugin til sikkerhedsvejledning. Installér det fra den officielle pluginmarkedsplads med /plugin install security-guidance@claude-plugins-official (Claude Code version 2.1.144 eller nyere kræves). Det kontrollerer koden på tre tidspunkter: ved hver redigering, ved afslutningen af hver tur og på commit-tidspunktet. Det opdager omgåelse af tilladelser, IDOR, injektioner og svag kryptografi. Men Anthropic er åben om begrænsningerne:

npx skills add <author>/<repo>

Bed derefter blot agenten om at ”kontrollere mit projekt for sårbarheder”. Men der er en vigtig reservation ved denne samling, og derfor har jeg givet den et særskilt afsnit nedenfor.

Til orientering er store aktører også begyndt at tage sikkerheden i AI-kode alvorligt. Som del af Project Glasswing, der blev udvidet den 2. juni 2026 til at omfatte 150 organisationer, fandt partnerne mere end 10.000 kritiske sårbarheder på kort tid ved hjælp af Anthropic-modeller. Indsatsen er tydelig:

Kan du stole på skills og udvidelser fra GitHub?#

Her bliver det særligt vanskeligt, fordi faren kommer fra et værktøj, du installerer af hensyn til sikkerheden. Når du kører npx skills add ... eller installerer en udvidelse, henter du andres kode, som agenten derefter kører med dine tilladelser. Hvis forfatteren er blevet hacket, eller pakken var ondsindet fra starten, har du et problem.

Tag samlingen af skills fra det foregående afsnit. Navnet indeholder ”Anthropic”, hvilket får dig til at sænke paraderne. Men i dens egen beskrivelse står der tydeligt:

Med andre ord er navnet misvisende. Samlingen er i øjeblikket gennemarbejdet og ren, men princippet gælder stadig: Du installerer den på eget ansvar. Og truslen er ikke teoretisk. I maj 2026 var en ondsindet udvidelse til en editor kun på markedspladsen i 18 minutter – og i løbet af den tid nåede den at stjæle adgangskoder fra adgangskodeadministratorer, GitHub-tokens, cloudadgang og endda Claude Code-konfigurationer fra dem, der installerede den. En anden ubehagelig detalje: Sådan malware overlever ofte almindelig fjernelse af pakken og kører igen i næste session.

Jeg har udviklet en enkel vane, som jeg også anbefaler dig: Kontrollér selv alle skills fra GitHub, før du installerer dem. Forfattere kan blive hacket, konti kan kapres, og malware kan ende i et repository. Kontrol er din sikkerhed.

Det praktiske minimum før installation: Se på forfatteren og antallet af stjerner, læs beskrivelsen af skillen, installér ikke et værktøj ”fordi nogen anbefalede det i et opslag”, og prøv ukendte værktøjer først i et separat testmiljø – ikke på en maskine med produktionsnøgler.

Hvad redder dig efter et brud: sikkerhedskopier og tilbagerulning#

Sikkerhed handler ikke kun om at ”holde uvedkommende ude”, men også om at ”komme tilbage til normalen, når noget går galt”. For noget vil gå galt. I det beskrevne praktiske tilfælde slettede en AI-agent en aktiv database i et produktionsprojekt under en rutineopgave. Der var en sikkerhedskopi, men den var tre dage gammel – og tre dages data forsvandt ganske enkelt.

Det fører til to regler.

Tag sikkerhedskopier ofte. Hvis din app indeholder data, du ville hade at miste, er en kopi hver tredje dag en falsk tryghed. Sæt automatiske sikkerhedskopier op mindst hver 30. minut. For de fleste databaser, herunder Supabase, kan det aktiveres med et par klik.

Git er en forsikring mod agenten. Git gemmer din kodehistorik: Du kan gendanne enhver fungerende tilstand. Når en agent overskriver noget, der virkede, ruller du tilbage til den seneste fungerende version i stedet for at rette det manuelt. Hvis AI slettede eller ødelagde projektet, og du ikke ved, hvordan du får det tilbage, kan du læse den separate gennemgang: hvad du skal gøre, hvis AI slettede databasen. Se guiden sådan beskytter du Claude Code mod nedbrud for at lære, hvordan du forebygger, at projektet går i stykker.

Sikkerhedstjekliste før udgivelse#

Gennemgå denne liste lige før udgivelse. I rækkefølge.

1. Hemmeligheder i .env og .env i .gitignore. Ingen nøgler i koden. Ingen .env-fil i et offentligt repository.

2. Nøgler med mindst mulige tilladelser. Hver nøgle kan kun gøre det, der er nødvendigt. Produktionsnøgler holdes adskilt fra agentens miljø.

3. RLS er slået til på alle tabeller med brugerdata, og adgangspolitikker er på plads.

4. Tilladelseskontroller på serversiden for hver datahandling. Det er ikke nok at skjule en knap i brugerfladen. Test manuelt ved at ændre id i adressen.

5. Verifikation af webhook-signaturer. Hver handler for eksterne meddelelser (betalinger, formularer) verificerer signaturen.

6. Begrænsning af anmodningsfrekvens for indgående forespørgsler og dyre operationer, så adgangskoder ikke kan gættes ved brute force, og regningen ikke løber løbsk.

7. Agenten kører ikke i tilstanden ”tillad alt” på en maskine med produktionsnøgler. Læsning af .env er nægtet.

8. Sikkerhedskopier tages ofte og testes – du har faktisk prøvet at gendanne fra dem i stedet for blot at tro, at kopierne ”er et sted”.

9. Koden er blevet kontrolleret med /security-review eller pluginet til sikkerhedsvejledning. Fundene er blevet rettet.

10. Andres skills og udvidelser er kontrolleret før installation. Intet blev installeret ”i blinde”.

Hvor skal du starte i dag?#

Forsøg ikke at gennemføre alt i denne guide på én aften – så ender du med ikke at gøre noget. Tag de tre vigtigste skridt i dag:

1. Kontrollér dine hemmeligheder. Åbn .gitignore, sørg for, at .env er angivet, og kontrollér, at der ikke ligger nøgler i det offentlige repository. Hvis nogen er lækket, skal du tilbagekalde dem og udstede nye.
2. Spørg om RLS. Sig til agenten: ”vis mig de tabeller, hvor RLS er slået fra” – og slå det til alle steder, hvor folks data opbevares.
3. Sæt hyppige sikkerhedskopier op. Så du mister minutter i stedet for dage, hvis noget går galt.

Følg derefter tjeklisten ovenfor, efterhånden som dit projekt vokser og begynder at håndtere penge og andre menneskers data.

En sidste ting. Sikkerhed ved vibe coding handler om ejerens ansvar. Du behøver ikke blive sikkerhedsekspert. AI byggede dit produkt på en aften – godt, men du har ansvaret for det. Det grundlæggende niveau i denne guide viser, hvordan det ansvar ser ud i praksis.

Du kan gå til Ailoot for at arbejde videre med modeller.