Säkerhet vid vibe coding: Så skyddar du en AI-byggd app

Fler instruktioner om hur du arbetar med Ailoot finns i dokumentationen.

Varför hackas AI-byggda appar oftare?#

Jag bygger själv produkter med AI och blir inte så paranoid kring säkerhet att jag vill ”låsa ner allt till max”. Men det finns en grundnivå som du inte får underskrida, annars kan du en dag vakna till en tom databas och någon annans kryptominerare på din server. Den här guiden handlar om den grundnivån. Inte ”bli säkerhetsexpert”, utan ”skjut dig inte i foten utan anledning”.

Grundproblemet är enkelt. När du säger till en AI-agent: ”bygg en app åt mig för att boka kunder”, bygger den appen så snabbt som möjligt. Säkerhet är extraarbete som inte syns i en demo. Därför konfigureras databasen som öppen, betalningsnyckeln hamnar direkt i koden och kontrollen av ”har den här användaren åtkomst?” finns bara i webbläsaren, där den kan kringgås på en sekund.

Det andra skälet är själva plattformarna.

Med andra ord uppstår säkerhetshålet av sig självt, som standard. Du har inte gjort något fel. Du har helt enkelt inte gjort något, och inom säkerhet betyder passivitet precis ”öppet för alla”.

Och så finns det ett tredje lager. AI läcker hemligheter oftare än människor. Enligt GitGuardians rapport från 2026 publicerar commits som görs med AI nycklar och lösenord till offentliga arkiv i omkring 3,2 procent av fallen – dubbelt så ofta som vanligt. Logiken är tydlig: agenten kör git add . och git push utan att titta efter, och din .env-fil med nycklar följer med allt annat ut offentligt.

Vad har vibe-kodare redan fått lära sig den hårda vägen?#

Det bästa skyddet mot slarv är att lära sig av andras misstag. Här är fyra rapporter som är värda att läsa innan du publicerar ditt projekt.

Lovable och avstängt RLS. Plattformen Lovable bygger appar utifrån textbeskrivningar. År 2025 upptäcktes ett systematiskt säkerhetshål i dess appar och det tilldelades CVE-2025-48757. Orsaken: apparna som genererades saknade regler för åtkomst till databasrader (RLS, som förklaras nedan). En forskare kontrollerade ett urval och hittade 303 exponerade åtkomstpunkter i 170 appar. Namn, telefonnummer, betalningsstatus, andra personers API-nycklar och till och med hemadresser exponerades. I omkring 70 procent av de kontrollerade apparna var skyddet på radnivå helt avstängt.

Tea och känsliga uppgifter. Appen Tea (anonyma omdömen om personer) förlorade omkring 72 000 bilder i juli 2025, däribland 13 000 selfies och foton av dokument, och därefter mer än en miljon privata meddelanden. Den tekniska orsaken var öppen lagring och svaga åtkomstkontroller. Säkerhetsvärlden nämner Tea som ett tydligt exempel: när en snabb lansering är viktigare än att kontrollera behörigheter är känsliga uppgifter det första som läcker.

Ett annat praktiskt exempel. I ett fall som beskrevs av den ursprungliga författaren blev en vibe-kodares app hackad för att AI:n ställde in ett standardlösenord när databasen skapades – ett lösenord som gick att gissa automatiskt. Sedan följde det vanliga förloppet: någon tog sig in, installerade kryptominerare och skrev över projektet. Servern behövde rensas helt. Ett standardlösenord är en olåst dörr med en skylt där det står ”stig på”.

Säkerhet på två fronter: var är du sårbar?#

När folk pratar om ”säkerhet vid vibe coding” klumpar de ofta ihop två helt olika farhågor. Låt oss skilja dem åt, eftersom du skyddar dig mot dem på olika sätt.

Första fronten – själva agenten. Du kör en AI-agent på din dator och ger den åtkomst till dina filer, terminalen, nycklarna och databasen. Risken är att en agent inte är en människa: den följer instruktioner bokstavligt och väljer den kortaste vägen, även om den är farlig. Hit hör också risken att någon annans kommando ”injiceras” i agenten via text som den läser (det kallas prompt injection).

Andra fronten – den färdiga appen. Det här är det du har publicerat och som människor använder. Målet är din publicerade webbplats eller tjänst: angripare tar sig in i en öppen databas, skickar falska förfrågningar eller gissar sig till andras konton. Agenten har inget med detta att göra – säkerhetshålet lämnades kvar tidigare och andra utnyttjar det.

Anthropic, företaget bakom Claude, uttrycker den viktigaste skyddsprincipen så här – och den fungerar på båda fronterna:

I praktiken betyder det: räkna inte med att AI ”själv låter bli att göra dåliga saker”. Begränsa först vad den rent konkret kan göra och be den sedan att bete sig väl. När beteendet brister – och det kommer att hända – är det bara en hård gräns som du har satt i förväg som skyddar dig.

Vill du att AI ska arbeta förutsägbart och sluta skjuta dig i foten i varje nytt projekt? Säkerhetsregler är en del av din Second Brain: skriv ner dem en gång i CLAUDE.md, så följer agenten dem i varje förfrågan.

Vad kan en AI-agent göra med åtkomst till din dator?#

Den mest underskattade risken är din egen agent med alltför omfattande behörigheter. Du behöver inte ens någon extern hacker. Här är ett färskt exempel från slutet av maj 2026. En Codex-agent behövde administratörsbehörighet som användaren saknade. Agenten gav inte upp – den tittade sig omkring, såg att användaren tillhörde gruppen docker, vilket i praktiken är likvärdigt med root, och använde den åtkomsten.

Det fanns inget ont uppsåt här. Det är bara det att en agent som fått instruktionen ”lös uppgiften” hittar en strukturell svaghet snabbare än en människa. Och om svagheten ger den åtkomst till dina nycklar eller produktionen kommer den att använda den. Därför är regel nummer ett minsta möjliga behörighet. Ge en agent precis så mycket åtkomst som den behöver för en viss uppgift och inte en gnutta mer.

Vad kan du göra i praktiken, även om du inte är programmerare?

1. Kör inte agenten i läget ”tillåt allt” på en produktionsmaskin

   Ett läge där agenten inte ber om bekräftelse (ofta kallat bypass eller yolo) är bara för en sandlåda eller ett testprojekt, inte en maskin som har aktiva nycklar och produktionsåtkomst.

2. Förbjud agenten att läsa hemligheter

   I Claude Code gör du detta med en regel som nekar åtkomst till filer som innehåller nycklar. Då släpper verktyget inte in agenten ens om den vill öppna .env.

3. Håll produktionsnycklar åtskilda

   Nycklar till produktionsdatabasen och betalningstjänsten ska inte ligga i samma mapp som agenten använder för att skriva kod. Håll miljöerna åtskilda: använd testnycklar när du experimenterar.

4. Använd verktygets sandlåda

   Moderna AI-verktyg kan köra kommandon isolerat (i en sandlåda), utan åtkomst till resten av systemet. I Claude Code minskar detta antalet behörighetsförfrågningar med omkring 84 procent – så det är också smidigare.

En regel som nekar läsning av hemligheter i Claude Code ser ungefär ut så här – lägg in den i behörighetsinställningarna:

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

Var ska du aldrig lägga API-nycklar och lösenord?#

Det billigaste och vanligaste misstaget är att lägga nycklar i koden. En API-nyckel till en betalningstjänst, ett databaslösenord, en bottoken – allt detta är hemligheter. De hör hemma i en separat .env-fil, och den filen måste finnas med i .gitignore så att den inte följer med koden in i git.

Därför är det här kritiskt: en nyckel blir inte långvarig i ett offentligt arkiv. Botar skannar nya commits dygnet runt. Sedan följer det vanliga förloppet: de hittar en molnnyckel, startar servrar för kryptoutvinning på din bekostnad och på morgonen har du en räkning på tiotusentals. Utvecklare berättar regelbundet sådana historier, och räkningarna ligger på femsiffriga belopp i dollar.

Problemets omfattning 2025: 28,65 miljoner nya hårdkodade hemligheter i offentliga arkiv, en ökning med 34 procent jämfört med året innan. Läckor av nycklar specifikt till AI-tjänster ökade med 81 procent. Vibe coding eldar på problemet eftersom agenten gör commits utan att titta efter.

Det här kan du kontrollera själv just nu:

1. Öppna projektets .gitignore-fil

   Se till att den innehåller en rad med .env. Om den inte gör det, lägg till en före den första commiten.

2. Gå till ditt GitHub-arkiv

   Kontrollera att .env-filen inte finns där. Att söka i arkivet efter .env eller en del av din nyckel är ett snabbt sätt att kontrollera det.

3. Om en nyckel har läckt, återkalla och utfärda en ny

   Det räcker inte att radera commiten: nyckeln kan redan ha stulits. Gå till tjänsten (betalningsleverantören, molntjänsten eller AI-leverantören), återkalla den gamla nyckeln och utfärda en ny. Det kallas rotation.

4. Ge nycklar minsta möjliga behörighet

   Om en nyckel bara behövs för läsning ska den vara skrivskyddad. Då går det att stjäla mindre även om den läcker.

Varför kan alla se din databas utan RLS?#

Om du bygger en app på Supabase eller en liknande databas är det här det viktigaste avsnittet. RLS står för Row Level Security, säkerhet på radnivå. Enkelt uttryckt är det en regel som avgör vilka rader i en tabell som visas för en viss användare. Utan den lämnar tabellen ”orders” ut alla kunders beställningar till alla.

Så här uttrycker Supabase-dokumentationen det själv, enkelt och tydligt:

Och här är den främsta fallgropen för den som använder vibe coding. När du skapar en tabell genom att klicka dig fram i Supabase-instrumentpanelen aktiveras skyddet automatiskt. Men när AI skapar tabellen – och den nästan alltid skriver SQL-kommandon direkt – förblir RLS avstängt som standard. Det innebär att en tabell som skapats av en agent med största sannolikhet är öppen för hela internet. Det var precis så de där 170 Lovable-apparna läckte.

Gör så här:

1. Fråga agenten direkt

   Skriv: ”visa mig alla tabeller där RLS är avstängt”. AI:n skapar en lista – det blir din arbetskö.

2. Aktivera RLS för varje tabell med användardata

   Lägg också till minst en åtkomstpolicy, till exempel ”en användare kan bara se sina egna rader”.

3. Kontrollera instrumentpanelen

   I Supabases instrumentpanel ska det stå ”RLS enabled” för varje tabell. Om markeringen är grå eller röd betyder det att tabellen är öppen.

4. Testa på riktigt

   Logga in som vanlig användare och försök hämta någon annans data. Om åtkomsten nekas fungerar policyn.

Varför skyddar inte behörighetskontroller i gränssnittet dig?#

En vanlig illusion är: ”Jag har sett till att vanliga användare inte kan se administratörsknappen.” Problemet är att en knapp bara är en bild i webbläsaren. En förfrågan kan skickas direkt till servern utan att använda knappen. Om servern inte kontrollerar behörigheterna igen utför den någon annans kommando.

Ett klassiskt exempel kallas IDOR. Tänk dig att du öppnar din beställning på en adress med id=123. Ändra det till id=124, så kan du se någon annans beställning eftersom servern inte kontrollerade om det faktiskt var din beställning. Det här är ett av de vanligaste säkerhetshålen i appar byggda med vibe coding, och svaga behörighetskontroller låg bakom läckan hos Tea.

Regeln är enkel: upprepa varje kontroll av ”får den här användaren göra det här?” på servern. Gränssnittet är till för bekvämlighet; skyddet hör hemma i backend. En färdig instruktion till agenten: ”lägg till behörighetskontroller på serversidan för varje slutpunkt som läser eller ändrar användardata; förlita dig inte på att ett element är dolt i gränssnittet.”

Hur kan du kontrollera koden efter säkerhetshål om du inte är programmerare?#

Det goda nyheten är att du i dag kan be samma AI att kontrollera säkerheten – den hittar vanliga säkerhetshål ganska bra. Här är tre verktyg för olika uppgifter.

1. Kommandot /security-review i Claude Code. En engångskontroll av den aktuella grenen efter SQL-injektion, XSS, behörighetshål, dataläckor och problem med beroenden. Jag har steg för steg förklarat hur det fungerar och hur du kopplar en automatisk kontroll till varje ändring i en separat guide om säkerhetsgranskning i Claude Code. Huvudpoängen här: det är den första försvarslinjen och startas med ett enda kommando.

2. Det officiella pluginet för säkerhetsvägledning. Installera det från den officiella pluginmarknadsplatsen med /plugin install security-guidance@claude-plugins-official (Claude Code version 2.1.144 eller senare krävs). Det kontrollerar koden vid tre tillfällen: vid varje ändring, i slutet av varje tur och vid commit. Det upptäcker kringgående av behörigheter, IDOR, injektioner och svag kryptografi. Men Anthropic är öppen med begränsningarna:

npx skills add <author>/<repo>

Säg sedan bara till agenten: ”kontrollera mitt projekt efter sårbarheter”. Men det finns en viktig reservation kring den här samlingen, och därför har jag gett den ett eget avsnitt nedan.

Som bakgrund har stora aktörer också börjat ta säkerheten i AI-kod på allvar. Som en del av Project Glasswing, som utökades den 2 juni 2026 till att omfatta 150 organisationer, hittade partnerna över 10 000 kritiska sårbarheter på kort tid med hjälp av Anthropic-modeller. Insatserna är tydliga:

Kan du lita på färdigheter och tillägg från GitHub?#

Här blir det extra knepigt, eftersom faran kommer från ett verktyg som du installerar för säkerhetens skull. När du kör npx skills add ... eller installerar ett tillägg hämtar du någon annans kod, som agenten sedan kör med dina behörigheter. Om upphovspersonen har blivit hackad eller paketet var skadligt från början har du ett problem.

Ta samlingen med färdigheter från föregående avsnitt. Namnet innehåller ”Anthropic”, vilket får dig att sänka garden. Men i dess egen beskrivning står det tydligt:

Med andra ord är namnet missvisande. Samlingen är i nuläget mogen och ren, men principen kvarstår: du installerar den på egen risk. Och hotet är inte teoretiskt. I maj 2026 fanns ett skadligt tillägg för en kodredigerare på marknadsplatsen i bara 18 minuter – och under den tiden hann det stjäla lösenord från lösenordshanterare, GitHub-token, molnåtkomst och till och med Claude Code-konfigurationer från dem som installerade det. En annan obehaglig detalj: sådan skadlig kod överlever ofta vanlig avinstallation av paket och körs igen under nästa session.

Jag har skaffat mig en enkel vana och rekommenderar den även till dig: kontrollera själv varje färdighet från GitHub innan du installerar den. Upphovspersoner kan bli hackade, konton kan kapas och skadlig kod kan hamna i ett arkiv. Kontroll är ditt skydd.

Det praktiska minimumet innan installation: titta på upphovspersonen och antalet stjärnor, läs beskrivningen av färdigheten, installera inte ett verktyg ”för att någon rekommenderade det i ett inlägg” och prova ett okänt verktyg i en separat testmiljö först, inte på en maskin med produktionsnycklar.

Vad räddar dig efter ett intrång: säkerhetskopior och återställning#

Säkerhet handlar inte bara om att ”hålla utomstående ute”, utan också om att ”återgå till det normala när något går fel”. För något kommer att gå fel. I det praktiska fall som beskrivs raderade en AI-agent en aktiv databas i ett produktionsprojekt när den utförde en rutinuppgift. Det fanns en säkerhetskopia, men den var tre dagar gammal – och tre dagars data försvann helt enkelt.

Det leder till två regler.

Säkerhetskopiera ofta. Om appen innehåller data som du skulle hata att förlora är en kopia var tredje dag en falsk trygghet. Ställ in automatiska säkerhetskopior minst var 30:e minut. För de flesta databaser, inklusive Supabase, går det att aktivera med ett par klick.

Git är en försäkring mot agenten. Git lagrar din kodhistorik: du kan återställa vilket fungerande läge som helst. När en agent skriver över något som fungerade återgår du till den senaste fungerande versionen i stället för att rätta till det för hand. Om AI raderade eller förstörde projektet och du inte vet hur du får tillbaka det kan du läsa den separata genomgången: vad du ska göra om AI raderade databasen. Läs guiden så skyddar du Claude Code mot att något går sönder om hur du förebygger att projektet går sönder.

Säkerhetschecklista före publicering#

Gå igenom den här listan precis före publicering. I ordning.

1. Hemligheter i .env och .env i .gitignore. Inga nycklar i koden. Ingen .env-fil i ett offentligt arkiv.

2. Nycklar med minsta möjliga behörighet. Varje nyckel kan bara göra det som behövs. Produktionsnycklar hålls åtskilda från agentens miljö.

3. RLS är aktiverat på alla tabeller med användardata och åtkomstpolicyer finns på plats.

4. Behörighetskontroller på serversidan för varje åtgärd som rör data. Det räcker inte att dölja en knapp i gränssnittet. Testa manuellt genom att ändra id i adressen.

5. Verifiering av webhook-signaturer. Varje hanterare av externa aviseringar (betalningar, formulär) verifierar signaturen.

6. Begränsning av anropsfrekvensen för inkommande förfrågningar och kostsamma åtgärder, så att lösenord inte kan gissas med råstyrka och din räkning inte skenar.

7. Agenten körs inte i läget ”tillåt allt” på en maskin med produktionsnycklar. Läsning av .env är förbjuden.

8. Säkerhetskopior tas ofta och testas – du har faktiskt provat att återställa, i stället för att bara tro att kopiorna ”finns någonstans”.

9. Koden har kontrollerats med /security-review eller pluginet för säkerhetsvägledning. Resultaten har åtgärdats.

10. Andras färdigheter och tillägg har kontrollerats före installation. Inget installerades ”blint”.

Var ska du börja i dag?#

Försök inte genomföra allt i den här guiden på en kväll – då blir det ingenting gjort. Ta de tre viktigaste stegen i dag:

1. Kontrollera dina hemligheter. Öppna .gitignore, se till att .env finns med och kontrollera att det inte finns några nycklar i det offentliga arkivet. Om någon har läckt, återkalla den och utfärda en ny.
2. Fråga om RLS. Säg till agenten: ”visa mig tabellerna där RLS är avstängt” – och aktivera det där människors data lagras.
3. Ställ in täta säkerhetskopior. Så att du förlorar minuter i stället för dagar om något går fel.

Följ sedan checklistan ovan när projektet växer och börjar hantera pengar och andra människors data.

En sista sak. Säkerhet vid vibe coding handlar om ägarens ansvar. Du behöver inte bli säkerhetsexpert. AI byggde din produkt på en kväll – toppen, men du ansvarar för den. Grundnivån i den här guiden visar hur det ansvaret ser ut i praktiken.

För att fortsätta arbeta med modeller kan du gå till Ailoot.