Tilgangskontroll for vibe-koding: Dataprivatliv og repository-omfang

Tilgangskontroll i vibe-koding er ikke et ekstra trekk - det er grunnlaget. Når en AI genererer kode uten at noen ser på den, blir det farlig å anta at den vet hva som er trygt. Du kan ikke bare legge inn en innlogging og tro at alt er i orden. Denne typen kode har ingen naturlig forståelse av grenser. Den kan gi en vanlig bruker admin-tilgang, eksponere en database med passord, eller sende hemmelige nøkler til en ukjent server - og du vil ikke vite det før det er for sent.

Hvorfor er vibe-koding farlig for tilgangskontroll?

Vibe-koding handler om å skrive en forespørsel og få kode som fungerer. Men den får ikke en forståelse av hvorfor ting skal være trygge. Den vet ikke om du skal ha tilgang til andre brukeres data. Den vet ikke om en API-endepunkt burde være offentlig. Den vet ikke at en nøkkel i en konfigurasjonsfil er en brannmur mot kriminelle.

En AI kan generere en fullstendig brukerinnlogging - men den kan også glemme å sjekke om brukeren er logget inn før den viser en fakturabank. Den kan generere kode som tillater alle å lese alle filer i en mappe. Den kan sette CORS til *, og da er enhver nettside i verden i stand til å stjele data fra din applikasjon. Og fordi koden blir lagt inn direkte i produksjon, uten gjennomgang, blir det en skjult tidssprenger.

Autentisering må skje før kode kjører

Ikke la AI håndtere autentisering. Ikke. Aldri. AI kan generere en login-side som ser ut som den fungerer - men den kan ha en feil i logikk, en tom sjekk, eller en bakdør som ingen ser. Hva gjør du da?

Sett opp en reverse proxy som NGINX. Den skal være den første som ser alle forespørsler. Den skal kreve en gyldig sesjon, en gyldig token, eller en gyldig SAML-sesjon - før noe av din applikasjon blir lastet. Ingen forespørsel skal nå din backend uten å være autentisert. Ikke en linje kode. Ikke en enkelt databaseforespørsel.

Hvis du lar AI generere autentisering, er du som en bilfører som lar en robot styre bilen, men ikke ser på veien. Du tror du er i sikkerhet - men du er bare i en skygge.

Roller, ikke rettigheter

Du trenger ikke å gi hver bruker admin-tilgang. Du trenger ikke å gi hver utvikler tilgang til produktiv database. Du trenger rollbasert tilgangskontroll (RBAC).

La AI generere RBAC-kode - men bare hvis du gir den en presis forespørsel: "Generer kode som gir brukere med rollen "redaktør" kun tilgang til å redigere egne innlegg, ikke til å slette brukere eller endre admin-innstillinger."

Sjekk hvert endepunkt. Sjekk hver side. Sjekk hver API. Kan en vanlig bruker se en annen brukers private meldinger? Kan en redaktør endre en admin-konto? Kan en gjest laste opp en fil som kjører kode? Hvis svaret er ja - så er det ikke RBAC. Det er en sikkerhetssvikt.

Test det. Ikke bare sjekk koden. Kjør en test med en bruker som har rollen "medlem" og prøv å komme til admin-siden. Kjør en test med en ikke-logget inn bruker og se om den kan laste en databaseliste. Bruk verktøy som Invicti eller OWASP ZAP. Du trenger ikke å være en sikkerhetsekspert - du trenger bare å være nøye.

Hvor ligger koden - og hvem kan se den?

Vibe-koding skjer ofte i lokale mapper. En fil her. En mappe der. En git-repo som ikke er på GitHub. Det er ikke en DevSecOps-pipeline. Det er en tilfeldig mappe på en datamaskin.

Når du ikke vet hvor koden er, kan du ikke se hva den gjør. Og hvis du ikke kan se det, kan du ikke sjekke om den er trygg. Det er som å la noen skrive en hemmelig bok i en koffert du ikke har nøkkelen til.

Løsningen er enkelt: Alle vibe-kodede prosjekter må ligge i et senterlig repository. Ikke bare for å ha backup. Men for å ha synlighet. Når koden er i en repo, kan du:

• Sjekke endringer med pull requests
• Kjøre automatiserte sikkerhetstester før merging
• Sette opp advarsler hvis noen legger inn en nøkkel eller en farlig pakke
• Se hvem som har gjort hva, og når

Hvis du ikke har et repo - har du ingen kontroll. Og uten kontroll, er du bare på vent til en brann.

Hva gjør AI-agentene - og hvem gir dem tillatelse?

GitHub Copilot, Claude Code, og andre AI-verktøy kjører nå direkte i GitHub Actions. De har GITHUB_TOKEN. De kan lage grener. De kan pushe endringer. De kan installere pakker. De kan sende data til eksterne servere - og du ser ikke hva de gjør.

Du tror kanskje de bare skriver kode. Men de kan laste ned en pakke som sender din API-nøkkel til en server i Russland. De kan lage en pull request som endrer en sikkerhetsinnstilling. De kan skrive en forespørsel som henter alle brukere fra din database.

Du må sette opp egress-policy. Blokkér utgående trafikk. Bare tillat forbindelser til de domene du vet at du trenger. Hvis AI-agenten prøver å kontakte api.dataexfiltration.ru - blokker den. Hvis den prøver å laste ned en pakke som ikke er i din liste - nekter den.

Claude Code har ingen innbygd firewall. Den har ingen innbygd sikkerhet. Den har bare en API. Og den vil gjøre hva du sier - selv om det er farlig.

Datakryptering og hemmeligheter

AI kan generere kode som bruker AES-256-kryptering. Men den kan også generere kode som lagrer passord i en tekstfil. Den kan generere kode som sender data over HTTP - ikke HTTPS. Den kan sette en nøkkel i en konfigurasjonsfil som alle kan se.

Bruk ikke .env-filer som ligger i repoet. Bruk ikke hardkodet API-nøkler. Bruk ikke en shared secret i en kommentar.

Bruk en hemmelighetsbehandlingstjeneste. HashiCorp Vault. AWS Secrets Manager. Azure Key Vault. Noe som ikke er i koden. Noe som krever en ekstra sjekk. Noe som kan logge hver gang en nøkkel blir brukt.

Og krypter data både i bevegelse og i ro. Hvis du har brukerdata - krypter dem. Ikke bare fordi du skal. Men fordi hvis noen stjeler din database, så vil de ikke kunne lese det.

Policyer som er del av AIens kontekst

Du kan ikke vente på at folk leser en Confluence-side. Du kan ikke forvente at de finner en sikkerhetsveileder på SharePoint. De har ikke tid. De har ikke motivasjon. De vil bare kode.

Løsningen er å gjøre sikkerhetspolicyer del av AIens kontekst. Legg dem i README-filer. Legg dem i .coderules. Legg dem i en fil som AIen leser før den genererer kode.

Eksempel:

.coderules
- Ingen autentisering skal genereres i applikasjonen. Bruk NGINX.
- Ingen CORS-tilstander med *. Bruk kun eksplisitte domener.
- Alle hemmeligheter må komme fra Vault, ikke .env.
- Ingen database-tilgang uten rollbasert autorisasjon.
- Alle endepunkter må testes for BOLA.

Når AIen ser denne filen før den skriver en linje kode - blir sikkerheten en del av koden. Ikke en ettertanke. Ikke en feil. En regel.

Hva hvis du ikke har tid til dette?

Du har tid. Du har bare ikke valgt å bruke den.

Vibe-koding er ikke om å skrive raskt. Det er om å skrive trygt. Og trygghet krever struktur. Ikke bare kode. Ikke bare AI. Men systemer.

Start med tre ting:

1. Sett opp en reverse proxy med autentisering - NGINX eller liknende.
2. Legg alle kodeendringer i et repo - ikke lokale mapper.
3. Legg en .coderules-fil i roten av repoet med dine tre viktigste regler.

Det er ikke komplekst. Det er ikke dyrt. Det er ikke nødvendig med nye verktøy. Det er bare nødvendig med disiplin.

Den enkle regelen

Hvis du ikke kan se det, kan du ikke beskytte det.

Hvis du ikke kan kontrollere det, kan du ikke stole på det.

Hvis du ikke vet hva AIen gjør - så er du ikke en utvikler. Du er en tilfeldig person som holder en brann i en kasse.

Sikkerhet i vibe-koding er ikke et verktøy. Det er en holdning. Og den begynner når du legger ned maskinen og sier: "Nei. Ikke bare fordi det fungerer. Fordi det er trygt."