Se for deg en markedskoordinator i en mellomstor bedrift. Hun har ikke programmert én linje i sitt liv, men hun er lei av å eksportere Excel-filer manuelt til CRM-systemet hver mandag morgen. En kollega tipser henne om Lovable. En time senere har hun et lite webgrensesnitt som kobler seg mot HubSpot-APIet, leser kundedata og sender automatiske oppdateringer. Det fungerer perfekt.

Det hun ikke vet: API-nøkkelen til HubSpot ligger hardkodet i kildekoden. Appen er publisert uten passordbeskyttelse. Og fordi hun brukte en gratis-plan, kjører koden på en delt server hun ikke kontrollerer.

Dette er ikke et hypotetisk scenario. Det skjer daglig, i bedrifter av alle størrelser.

Den demokratiske siden av AI-koding

Verktøy som Lovable, Replit, Cursor, Bolt og Claude har gjort noe bemerkelsesverdig: De har gjort programmering tilgjengelig for folk som ikke er utviklere. Du beskriver hva du vil ha på naturlig språk, og du får fungerende kode tilbake, komplett med grensesnitt, logikk og integrasjoner.

For bedrifter kan dette virke som en drøm. IT-køen krymper. Ansatte løser egne problemer. Interne verktøy dukker opp på dager i stedet for måneder. Produktiviteten stiger.

Men det er en kostnad gjemt bak den enkle brukeropplevelsen. Den som bygger appen forstår ikke nødvendigvis hva som skjer under panseret.

4 ting som typisk går galt:

1. API-nøkler i kildekoden

Det er teknisk krevende å håndtere tilgangsnøkler riktig. Erfarne utviklere gjør det feil innimellom. En ikke-teknisk ansatt som ber en AI-assistent om å koble appen mot Stripe, får tilbake kode som fungerer. Det hun ikke ser, er at tilgangsnøkkelen (API nøkkelen) som er et digitalt nøkkelkort som gir en app automatisk tilgang til et system uten brukernavn eller passord. Det ligger synlig i koden for alle som måtte få tak i filen.

Tenk deg at noen skriver passordet til bedriftens nettbank direkte inn i et Word-dokument og deler det med hele avdelingen. Det er i praksis det som skjer når en tilgangsnøkkel havner i kildekoden.

Konsekvensene er konkrete: Stripe-nøkkelen gir tilgang til alle betalingstransaksjoner. Google-nøkkelen gir tilgang til Drive. Slack-tokenet lar noen lese alle meldinger i hele arbeidsrommet.

2. Manglende autentisering

«Lag en intern portal der selgerne kan se pipeline-status» høres uskyldig ut. Men hvis portalen ikke krever innlogging, eller bruker et enkelt passord som deles i en Slack-melding, er den i praksis offentlig. Søkemotorer indekserer ikke alltid slike apper, men de er søkbare for den som vet hva de leter etter.

Shodan og lignende verktøy brukes av sikkerhetsforskere, og angripere, til å finne eksponerte tjenester på internett. En intern salgsportal uten autentisering er ikke «intern» bare fordi ingen har fortalt deg at den er tilgjengelig utenfra.

3. Usikker håndtering av brukerinput

AI-generert kode er gjerne funksjonell, men sjelden defensiv. Spørringen mot databasen validerer kanskje ikke input. Filveiledningene sjekker kanskje ikke om brukeren prøver å navigere seg til /etc/passwd. Skjemaet aksepterer kanskje JavaScript som kjøres i neste brukers nettleser.

SQL-injeksjon, XSS og directory traversal er ikke eksotiske angrep. De er blant de mest brukte teknikkene i verden, nettopp fordi de treffer kode som er skrevet uten sikkerhet i tankene.

4. Data som forlater bedriften

Mange AI-kodeverktøy sender koden din og, viktigere, konteksten du oppgir, til modeller som kjøres på eksterne servere. «Her er kundelisten vår, lag en app som sorterer dem etter omsetning» er kanskje en prompt som inneholder sensitiv forretningsinformasjon.

Det er ikke ondsinnet fra plattformens side. Men det betyr at data kan havne i treningsdata, i logger, i systemer bedriften ikke har vurdert i sin databehandleravtale.

Hvem eier disse appene?

Her er et spørsmål IT-avdelingen sjelden stiller: Vet vi hvilke apper som er i bruk?

Shadow IT er ikke nytt. Ansatte har i årevis brukt Dropbox når bedriften insisterte på å bruke SharePoint, eller Slack, når ledelsen foretrakk e-post. Men de lagret typisk filer og sendte meldinger. De kjørte ikke kode med tilgang til produksjonssystemer.

AI-drevet shadow IT er annerledes. En ansatt kan nå bygge noe som: Kobler seg mot bedriftens CRM, ERP eller regnskapssystem, kjører automatiserte oppgaver på vegne av andre ansatte, lagrer kopier av sensitive data i en sky-database hun kontrollerer alene, og som typisk slutter å fungere, eller kjøres videre etter at hun slutter i jobben. Ingen vet at det finnes. Ingen har godkjent det. Ingen kan slå det av.

Det er ikke de ansattes feil

Det ville være enkelt å peke finger mot markedskonsulenten med HubSpot-nøkkelen i kildekoden. Men det er feil analyse. Hun løste et reelt problem, med verktøyene hun hadde tilgang til, på en måte som virket fornuftig. Ingen fortalte at API-nøkler skulle behandles som passord. Ingen forklarte hva en SQL-injeksjon er. Og ingen i organisasjonen hadde gitt henne et trygt alternativ.

Problemet er strukturelt, ikke individuelt.

4 ting organisasjoner faktisk kan gjøre:

1. Lag en sandkasse, ikke en barriere

Forby AI-kodeverktøy, og du mister produktivitetsgevinsten, og de ansatte begynner å bruke dem uansett, bare mer skjult. En bedre tilnærming er å lage et dedikert miljø der slike verktøy er tillatt, uten tilgang til produksjonsdata, uten mulighet til å koble seg mot kritiske systemer.

2. Gi ikke-tekniske brukere sikre byggeklosser

Hvis noen skal koble seg mot Salesforce-APIet, gi dem en intern gateway som allerede håndterer autentisering riktig. Gi dem templates som er ferdig konfigurert med environment variables. Gjør det enklere å gjøre det riktig enn å gjøre det galt.

3. Sett opp overvåking på API-bruk

De fleste SaaS-systemer logger hvilke nøkler som brukes og fra hvilke IP-adresser. Et uvanlig mønster, en HubSpot-nøkkel som gjør 10 000 kall midt på natten, er tegn på at noe kjører autonomt et sted. Det er mulig å fange opp dette, men bare hvis noen ser etter det.

4. Bygg en kultur der det er trygt å spørre

«Jeg har laget noe, men jeg er ikke sikker på om det er OK» bør møtes med hjelp, ikke irettesettelse. Organisasjoner der ansatte er redd for å innrømme at de har bygget noe utenfor godkjente prosesser, har akkurat den typen shadow IT som er farligst, den alle vet om, men ingen snakker høyt om.

Den egentlige risikoen

Det som gjør dette temaet viktig akkurat nå, er ikke at noen ansatte bygger usikre apper. Det har skjedd før. Det som er nytt er skalaen.

For to år siden krevde det å bygge en intern app med databaseintegrasjon og API-kall minst grunnleggende programmeringskunnskap. Det satte en naturlig terskel. I dag kan hvem som helst med nok tålmodighet og en god AI-assistent produsere funksjonell, og mulig farlig kode på noen timer.

Antall apper som kjører i bedrifter uten at IT vet om dem, er i ferd med å eksplodere. Mange av dem er trygge nok. Noen er ikke det. Vet du hvilke apper som brukes i din organisasjon?

Ikke steng verktøyene, men gi folk rammeverkene de trenger for å bruke dem ansvarlig.