Sikkerhet ved vibe coding: Slik beskytter du en app bygget med AI

Flere instruksjoner for hvordan du arbeider med Ailoot, finner du i dokumentasjonen.

Hvorfor blir apper bygget med AI oftere hacket?#

Jeg bygger selv produkter med AI, og blir ikke paranoid når det gjelder sikkerhet, i den grad at jeg «låser alt maksimalt». Men det finnes et grunnleggende sikkerhetsnivå du ikke må gå under. Ellers kan du våkne en dag til en tom database og andres kryptoutvinnere på serveren din. Denne veiledningen handler om dette grunnleggende nivået. Ikke «bli sikkerhetsekspert», men «ikke skyt deg selv i foten uten grunn».

Roten til problemet er enkel. Når du ber en AI-agent om å «lage en app der kunder kan bestille timer», får den appen til å fungere så raskt som mulig. Sikkerhet er ekstraarbeid som ikke synes i en demo. Dermed settes databasen opp som åpen, betalingsnøkkelen legges rett inn i koden, og kontrollen av «har denne brukeren tilgang?» finnes bare i nettleseren, der den kan omgås på et sekund.

Den andre grunnen er plattformene selv.

Med andre ord oppstår hullet av seg selv, som standard. Du gjorde ikke noe galt. Du gjorde bare ingenting — og innen sikkerhet betyr passivitet nettopp «åpent for alle».

Det finnes også et tredje lag. AI lekker oftere hemmeligheter enn mennesker gjør. Ifølge GitGuardians rapport fra 2026 publiserer AI-assisterte commits nøkler og passord til offentlige repositorier i omtrent 3,2 prosent av tilfellene — dobbelt så ofte som vanlig. Logikken er tydelig: Agenten kjører git add . og git push uten å se seg for, og .env-filen din med nøklene blir offentlig sammen med alt annet.

Hva har vibe codere allerede lært på den harde måten?#

Den beste vaksinen mot skjødesløshet er å lære av andres feil. Her er fire gjennomganger det er verdt å se på før du publiserer prosjektet ditt.

Lovable og avslått RLS. Plattformen Lovable bygger apper fra tekstbeskrivelser. I 2025 ble det funnet et systemisk sikkerhetshull i appene deres, og det fikk nummeret CVE-2025-48757. Årsaken: De genererte appene hadde ingen regler for tilgang til enkeltrader i databasen (RLS, forklart nedenfor). En forsker undersøkte et utvalg og fant 303 eksponerte tilgangspunkter i 170 apper. Navn, telefonnumre, betalingsstatuser, andres API-nøkler og til og med hjemmeadresser var eksponert. I rundt 70 prosent av appene som ble undersøkt, var beskyttelse på radnivå slått helt av.

Tea og sensitive data. Tea-appen (anonyme anmeldelser av mennesker) mistet rundt 72 000 bilder i juli 2025, blant annet 13 000 selfier og bilder av dokumenter, og senere over én million private meldinger. Den tekniske årsaken var åpen lagring og svake tilgangskontroller. Sikkerhetsmiljøet viser til Tea som et tydelig eksempel: Når rask lansering er viktigere enn å kontrollere tilgang, er det sensitive data som lekker først.

Et annet praktisk eksempel. I et tilfelle som den opprinnelige forfatteren beskriver, ble en vibe coders app hacket fordi AI satte et standardpassord da den opprettet databasen — et passord som kunne gjettes automatisk. Deretter fulgte det vanlige hendelsesforløpet: De kom seg inn, installerte kryptoutvinnere og skrev om prosjektet. Serveren måtte slettes fullstendig. Et standardpassord er en ulåst dør med et skilt der det står «kom inn».

To sider av sikkerheten: Hvor er du sårbar?#

Når folk snakker om «sikkerhet ved vibe coding», slår de gjerne sammen to helt forskjellige bekymringer. La oss skille dem fra hverandre, for du beskytter deg mot dem på ulike måter.

Første side — selve agenten. Du kjører en AI-agent på datamaskinen din og gir den tilgang til filer, terminal, nøkler og database. Risikoen er at en agent ikke er et menneske: Den følger instruksjoner bokstavelig og finner den korteste veien, selv om den er farlig. Dette omfatter også risikoen for at andres kommando blir «injisert» i agenten gjennom tekst den leser (dette kalles prompt injection).

Andre side — den ferdige appen. Dette er det du har publisert, og som folk bruker. Målet er nettstedet eller tjenesten du har publisert: Angripere kommer inn i en åpen database, sender falske forespørsler eller prøver å gjette andres kontoer. Agenten har ingenting med dette å gjøre — hullet ble etterlatt tidligere, og andre utnytter det.

Anthropic, selskapet bak Claude, formulerer det viktigste beskyttelsesprinsippet slik — og det gjelder på begge sider:

I praksis betyr dette at du ikke må regne med at AI «unngår å gjøre dumme ting på egen hånd». Begrens først hva den fysisk kan gjøre, og be den deretter om å oppføre seg bra. Når atferden svikter — og det vil den gjøre — er det bare en fast grense du har satt på forhånd, som beskytter deg.

Vil du at AI skal arbeide forutsigbart og slutte å skyte deg i foten i hvert nye prosjekt? Sikkerhetsregler er en del av Second Brain: Skriv dem én gang i CLAUDE.md, så følger agenten dem for hver forespørsel.

Hva kan en AI-agent gjøre med tilgang til datamaskinen din?#

Den mest undervurderte risikoen er din egen agent med altfor omfattende tillatelser. Du trenger ikke engang en ekstern hacker. Her er et nylig eksempel fra slutten av mai 2026. En Codex-agent trengte administratorrettigheter som brukeren ikke hadde. Agenten ga seg ikke — den undersøkte omgivelsene, så at brukeren tilhørte gruppen docker, som i praksis tilsvarer root, og brukte den tilgangen.

Det var ingen ondsinnet hensikt her. En agent som blir bedt om å «løse oppgaven», finner bare en strukturell svakhet raskere enn et menneske. Og hvis den svakheten gir tilgang til nøklene eller produksjonsmiljøet ditt, vil agenten bruke den. Derfor er regel nummer én minste privilegium. Gi agenten nøyaktig den tilgangen den trenger for en bestemt oppgave, og ikke mer.

Dette er ikke bare noe jeg innbiller meg.

Hva kan du gjøre i praksis, selv om du ikke er programmerer?

1. Ikke kjør agenten i modusen «tillat alt» på en produksjonsmaskin

   En modus der agenten ikke ber om bekreftelse (ofte kalt bypass eller yolo), er bare for en sandkasse eller et testprosjekt — ikke en maskin med aktive nøkler og tilgang til produksjon.

2. Forby agenten å lese hemmeligheter

   I Claude Code gjør du dette med en regel som nekter tilgang til filer som inneholder nøkler. Da får ikke verktøyet åpnet .env, selv om agenten prøver.

3. Hold produksjonsnøkler adskilt

   Nøkler til produksjonsdatabasen og betalingstjenesten skal ikke ligge i samme mappe som agenten skriver kode i. Hold miljøene adskilt: Bruk testnøkler når du eksperimenterer.

4. Bruk verktøyets sandkasse

   Moderne AI-verktøy kan kjøre kommandoer isolert (i en sandkasse), uten tilgang til resten av systemet. I Claude Code reduserer dette forespørsler om tillatelse med rundt 84 prosent — så det er også mer praktisk.

En regel som nekter Claude Code å lese hemmeligheter, ser omtrent slik ut — legg den inn i tillatelsesinnstillingene:

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

Hvor bør du aldri legge API-nøkler og passord?#

Den billigste og vanligste feilen er å legge nøkler i koden. En API-nøkkel til en betalingstjeneste, et databasepassord, et bot-token — alt dette er hemmeligheter. De hører hjemme i en separat .env-fil, og filen må stå i .gitignore slik at den ikke havner i git sammen med koden.

Hvorfor dette er kritisk: En nøkkel blir ikke lenge i et offentlig repository uten å bli oppdaget. Boter skanner nye commits døgnet rundt. Det vanlige hendelsesforløpet følger: De finner en skynøkkel, starter servere for kryptoutvinning på din regning, og om morgenen sitter du med en regning på flere titalls tusen dollar. Utviklere forteller regelmessig slike historier, og regningene er på femsifrede beløp i dollar.

Problemets omfang i 2025: 28,65 millioner nye hardkodede hemmeligheter i offentlige repositorier, en økning på 34 prosent fra året før. Lekkasjer av nøkler til AI-tjenester steg med 81 prosent. Vibe coding gjør problemet verre fordi agenten committer uten å se seg for.

Dette bør du kontrollere manuelt nå:

1. Åpne prosjektets .gitignore-fil

   Kontroller at den har en .env-linje. Hvis ikke, legg den til før første commit.

2. Gå til GitHub-repositoriet ditt

   Kontroller at .env-filen ikke ligger der. Et raskt søk etter .env eller deler av nøkkelen din i repositoriet gjør det enkelt å sjekke.

3. Hvis en nøkkel har lekket, tilbakekall den og utsted en ny

   Det er ikke nok å slette commiten: Nøkkelen kan allerede ha blitt hentet. Gå til tjenesten (betalingstilbyder, skytjeneste, AI-tilbyder), tilbakekall den gamle nøkkelen og utsted en ny. Dette kalles rotasjon.

4. Gi nøklene minst mulig tilgang

   Hvis en nøkkel bare trengs for lesing, gjør den skrivebeskyttet. Da er det mindre som kan stjeles hvis den lekker.

Hvorfor kan alle se databasen din uten RLS?#

Hvis du bygger en app på Supabase eller en lignende database, er dette den viktigste delen. RLS står for Row Level Security. Enkelt sagt er det en regel som bestemmer hvilke rader i en tabell en bestemt bruker får se. Uten den returnerer «orders»-tabellen alle kundenes bestillinger til alle.

Slik formulerer Supabase-dokumentasjonen det selv, helt tydelig:

Og her er hovedfellen for en vibe coder. Når du oppretter en tabell ved å klikke deg gjennom Supabase-dashbordet, slås beskyttelsen på automatisk. Men når AI oppretter tabellen — og den skriver nesten alltid SQL-kommandoer direkte — forblir RLS avslått som standard. Det betyr at en tabell opprettet av en agent nesten helt sikkert er åpen for hele internett. Det var akkurat slik de 170 Lovable-appene lekket data.

Dette bør du gjøre:

1. Spør agenten direkte

   Skriv: «vis meg alle tabellene der RLS er slått av». AI lager en liste — det blir arbeidslisten din.

2. Slå på RLS for hver tabell med brukerdata

   Legg også til minst én tilgangspolicy — for eksempel «en bruker kan bare se sine egne rader».

3. Kontroller dashbordet

   I Supabase-dashbordet skal det stå «RLS enabled» ved hver tabell. Hvis det er grått eller rødt, betyr det at tabellen er åpen.

4. Test det i praksis

   Logg inn som en vanlig bruker og prøv å hente data som tilhører noen andre. Hvis tilgangen nektes, fungerer policyen.

Hvorfor beskytter ikke tilgangskontroller i grensesnittet deg?#

En vanlig misforståelse er: «Jeg har sørget for at vanlige brukere ikke kan se admin-knappen.» Problemet er at en knapp bare er et bilde i nettleseren. En forespørsel kan sendes rett til serveren uten å bruke knappen. Hvis serveren ikke kontrollerer tillatelsene på nytt, utfører den andres kommando.

Et klassisk eksempel kalles IDOR. Se for deg at du åpner bestillingen din på en adresse med id=123. Endrer du den til id=124, kan du se noen andres bestilling fordi serveren ikke kontrollerte om det faktisk var din bestilling. Dette er et av de vanligste sikkerhetshullene i apper bygget med vibe coding, og svake tilgangskontroller lå bak Tea-lekkasjen.

Regelen er enkel: gjenta hver kontroll av «har denne brukeren lov til å gjøre dette?» på serveren. Grensesnittet er til for brukervennlighet; beskyttelsen hører hjemme i backend. En ferdig instruksjon til agenten: «legg til tilgangskontroller på serversiden for hvert endepunkt som leser eller endrer brukerdata; ikke stol på at et element er skjult i grensesnittet».

Hvordan kan du sjekke koden for sikkerhetshull hvis du ikke er programmerer?#

Den gode nyheten: I dag kan du be den samme AI-en sjekke sikkerheten — den gjør en ganske god jobb med å finne vanlige sikkerhetshull. Her er tre verktøy for ulike oppgaver.

1. Kommandoen /security-review i Claude Code. En engangssjekk av gjeldende branch for SQL-injeksjon, XSS, autorisasjonshull, datalekkasjer og problemer med avhengigheter. Jeg har forklart trinn for trinn hvordan den fungerer, og hvordan du legger til en automatisk sjekk for hver endring, i en egen veiledning om sikkerhetsgjennomgang i Claude Code. Hovedpoenget her: Dette er første forsvarslinje, startet med én kommando.

2. Det offisielle security-guidance-programtillegget. Installer det fra den offisielle markedsplassen for programtillegg med /plugin install security-guidance@claude-plugins-official (Claude Code versjon 2.1.144 eller nyere kreves). Det sjekker koden på tre tidspunkter: ved hver redigering, på slutten av hver tur og når du committer. Det finner omgåelser av tilgangskontroller, IDOR, injeksjoner og svak kryptografi. Men Anthropic er åpen om begrensningene:

npx skills add <author>/<repo>

Si deretter ganske enkelt til agenten: «sjekk prosjektet mitt for sårbarheter». Men det er et viktig forbehold ved denne samlingen, og derfor får den et eget avsnitt nedenfor.

Som bakgrunn: Store aktører har også begynt å ta sikkerheten til AI-kode på alvor. Som del av Project Glasswing, som ble utvidet 2. juni 2026 til å omfatte 150 organisasjoner, fant partnerne over 10 000 kritiske sårbarheter på kort tid ved hjelp av Anthropic-modeller. Innsatsen er tydelig:

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

Her blir det spesielt vanskelig, fordi faren kommer fra et verktøy du installerer for sikkerhetens skyld. Når du kjører npx skills add ... eller installerer en utvidelse, henter du inn kode fra noen andre, som agenten deretter kjører med dine tillatelser. Hvis forfatteren ble hacket eller pakken var ondsinnet fra starten av, har du et problem.

Se på skills-samlingen fra forrige avsnitt. Navnet inneholder «Anthropic», noe som får deg til å senke guarden. Men i beskrivelsen står det tydelig:

Med andre ord er navnet misvisende. Selve samlingen er for tiden moden og ren, men prinsippet gjelder fortsatt: Du installerer den på egen risiko. Og trusselen er ikke teoretisk. I mai 2026 var en ondsinnet utvidelse for et tekstredigeringsprogram på markedsplassen i bare 18 minutter — i løpet av den tiden klarte den å stjele passord fra passordbehandlere, GitHub-tokener, tilgang til skytjenester og til og med Claude Code-konfigurasjoner fra dem som installerte den. En annen ubehagelig detalj: Slik skadevare overlever ofte vanlig fjerning av pakken og kjører på nytt i neste økt.

Jeg har utviklet en enkel vane for min egen del, og anbefaler deg å gjøre det samme: Kontroller selv alle skills fra GitHub før du installerer dem. Forfattere kan bli hacket, kontoer kan bli kapret, og skadevare kan havne i et repository. Kontrollen beskytter deg.

Det praktiske minimumet før installering: Se på forfatteren og antall stjerner, les beskrivelsen av skillen, ikke installer et verktøy «fordi det ble anbefalt i ett innlegg», og prøv ukjente verktøy først i et eget testmiljø, ikke på en maskin med produksjonsnøkler.

Hva hjelper deg etter et innbrudd: sikkerhetskopier og tilbakerulling#

Sikkerhet handler ikke bare om å «holde uvedkommende ute», men også om å «komme tilbake til normalen når noe går galt». For noe kommer til å gå galt. I et praktisk tilfelle som er beskrevet, slettet en AI-agent en aktiv database i et produksjonsprosjekt mens den håndterte en rutineoppgave. Det fantes en sikkerhetskopi, men den var tre dager gammel — og dataene fra tre dager var rett og slett borte.

Det gir to regler.

Ta sikkerhetskopier ofte. Hvis appen din inneholder data du ikke vil miste, er en kopi hver tredje dag en illusjon av beskyttelse. Sett opp automatiske sikkerhetskopier minst hvert 30. minutt. For de fleste databaser, inkludert Supabase, kan dette aktiveres med noen få klikk.

Git er en forsikring mot agenten. Git lagrer historikken til koden din, slik at du kan gjenopprette enhver fungerende tilstand. Når en agent skriver om noe som fungerte, ruller du tilbake til den siste fungerende versjonen i stedet for å reparere det manuelt. Hvis AI slettet eller ødela prosjektet og du ikke vet hvordan du får det tilbake, kan du se den separate gjennomgangen: hva du gjør hvis AI slettet databasen. For å beskytte prosjektet mot skade på forhånd, se veiledningen slik beskytter du Claude Code mot skade.

Sikkerhetssjekkliste før publisering#

Gå gjennom denne listen rett før publisering, i rekkefølge.

1. Hemmeligheter i .env, og .env i .gitignore. Ingen nøkler i koden. Ingen .env-fil i et offentlig repository.

2. Nøkler med minimale tillatelser. Hver nøkkel kan bare gjøre det som trengs. Produksjonsnøkler er adskilt fra agentens miljø.

3. RLS er slått på for alle tabeller med brukerdata, og tilgangspolicyer er på plass.

4. Tilgangskontroller på serversiden for alle operasjoner på data. Det er ikke nok å skjule en knapp i grensesnittet. Du har testet manuelt ved å endre id i adressen.

5. Webhook-signaturer kontrolleres. Alle behandlere av eksterne varsler (betalinger, skjemaer) kontrollerer signaturen.

6. Frekvensbegrensning på innkommende forespørsler og ressurskrevende operasjoner, slik at passord ikke kan gjettes med rå kraft og regningen ikke kan løpe løpsk.

7. Agenten kjører ikke i modusen «tillat alt» på en maskin med produksjonsnøkler. Lesing av .env er nektet.

8. Sikkerhetskopier tas ofte og er testet — du har faktisk prøvd å gjenopprette en kopi i stedet for bare å tro at kopiene «finnes et sted».

9. Koden er kontrollert med /security-review eller security-guidance-plugin. Funnene er rettet.

10. Skills og utvidelser fra andre er kontrollert før installering. Ingenting ble installert «i blinde».

Hvor bør du begynne i dag?#

Ikke prøv å gjennomføre alt i denne veiledningen på én kveld — da ender du med å ikke gjøre noe. Ta de tre viktigste stegene i dag:

1. Kontroller hemmelighetene dine. Åpne .gitignore, sjekk at .env er oppført, og kontroller at det ikke finnes nøkler i det offentlige repositoriet. Hvis noen har lekket, tilbakekall dem og utsted nye.
2. Spør om RLS. Si til agenten: «vis meg tabellene der RLS er slått av» — og slå det på for alle tabeller der data om folk lagres.
3. Sett opp hyppige sikkerhetskopier. Da mister du minutter i stedet for dager hvis noe går galt.

Følg deretter sjekklisten ovenfor når prosjektet vokser og begynner å håndtere penger og andres data.

En siste ting. Sikkerhet ved vibe coding handler om eierens ansvar. Du trenger ikke å bli sikkerhetsekspert. AI bygde produktet ditt på én kveld — flott, men du er ansvarlig for det. Grunnnivået i denne veiledningen viser hvordan dette ansvaret ser ut i praksis.

For videre arbeid med modeller kan du gå til Ailoot.