Vibe coding -tietoturva: Näin suojaat tekoälyllä rakennetun sovelluksen

Lisää Ailootin käyttöohjeita on dokumentaatiossa.

Miksi tekoälyllä rakennettuja sovelluksia hakkeroidaan useammin?#

Rakennan itsekin tuotteita tekoälyn avulla enkä suhtaudu tietoturvaan niin vainoharhaisesti, että ”lukitsisin kaiken viimeisen päälle”. On kuitenkin olemassa perustaso, jonka alapuolelle ei pidä mennä, tai jonakin päivänä heräät tyhjään tietokantaan, ja palvelimellasi louhii joku muu kryptovaluuttaa. Tämä opas käsittelee tuota perustasoa. Tarkoitus ei ole ”ryhtyä tietoturva-asiantuntijaksi”, vaan ”olla ampumatta itseään jalkaan ilman syytä”.

Ongelman ydin on yksinkertainen. Kun pyydät tekoälyagenttia ”rakentamaan minulle sovelluksen asiakkaiden varaamiseen”, se saa sovelluksen toimimaan mahdollisimman nopeasti. Tietoturva on ylimääräistä työtä, joka ei näy demossa. Siksi tietokanta määritetään avoimeksi, maksupalvelun avain päätyy suoraan koodiin ja ”onko tällä käyttäjällä käyttöoikeus?” -tarkistus on vain selaimessa, jossa sen voi ohittaa sekunnissa.

Toinen syy ovat itse alustat. Monet alustat tekevät uusista projekteista oletusarvoisesti julkisesti saatavilla olevia, eivätkä muut kuin ohjelmoijat aina tiedä, että tämä asetus pitäisi muuttaa.

Toisin sanoen aukko syntyy itsestään oletusarvoisesti. Et tehnyt mitään väärin. Et vain tehnyt mitään – ja tietoturvassa toimettomuus tarkoittaa juuri sitä, että ”kaikilla on pääsy”.

Mitä vibe-koodaajat ovat jo oppineet kantapään kautta?#

Paras keino torjua huolimattomuutta on oppia muiden virheistä. Tässä on neljä raporttia, joihin kannattaa tutustua ennen projektin julkaisemista.

Lovable ja käytöstä poistettu RLS. Lovable-alusta rakentaa sovelluksia tekstikuvausten perusteella. Vuonna 2025 sen sovelluksista löydettiin järjestelmätason aukko, jolle annettiin tunnus CVE-2025-48757. Syy: luoduissa sovelluksissa ei ollut tietokannan rivitason käyttöoikeussääntöjä (RLS, josta kerrotaan alla). Tutkija tarkisti otoksen ja löysi 303 paljastunutta käyttöoikeuspistettä 170 sovelluksesta. Nimet, puhelinnumerot, maksutilat, muiden ihmisten API-avaimet ja jopa kotiosoitteet paljastuivat. Noin 70 prosentissa tarkistetuista sovelluksista rivitason suojaus oli kokonaan pois käytöstä.

Tea ja arkaluonteiset tiedot. Tea-sovellus (ihmisten anonyymit arviot) menetti noin 72 000 kuvaa heinäkuussa 2025, niiden joukossa 13 000 selfietä ja asiakirjakuvaa, ja myöhemmin yli miljoona yksityistä viestiä. Tekninen syy oli avoin tallennustila ja heikot käyttöoikeustarkistukset. Tietoturvayhteisö pitää Teaa havainnollisena esimerkkinä: kun nopea julkaisu on tärkeämpää kuin käyttöoikeuksien tarkistaminen, arkaluonteiset tiedot vuotavat ensimmäisinä.

Toinen käytännön esimerkki. Alkuperäisen kirjoittajan kuvaamassa tapauksessa vibe-koodaajan sovellus hakkeroitiin, koska tekoäly asetti oletussalasanan tietokantaa luodessaan. Salasana oli mahdollista arvata automaattisesti. Sitten seurasi tavanomainen tapahtumaketju: järjestelmään murtauduttiin, sinne asennettiin kryptolouhijoita ja projekti kirjoitettiin uudelleen. Palvelin täytyi tyhjentää kokonaan. Oletussalasana on lukitsematon ovi, jossa on kyltti ”tervetuloa sisään”.

Tietoturvan kaksi rintamaa: missä tarkalleen olet haavoittuvainen?#

Kun ihmiset puhuvat ”vibe codingin tietoturvasta”, he niputtavat usein yhteen kaksi aivan erilaista pelkoa. Erotellaan ne, koska niiltä suojaudutaan eri tavoin.

Ensimmäinen rintama – itse agentti. Käytät tekoälyagenttia tietokoneellasi ja annat sille pääsyn tiedostoihin, terminaaliin, avaimiin ja tietokantaan. Riskinä on, ettei agentti ole ihminen: se noudattaa ohjeita kirjaimellisesti ja etsii lyhimmän reitin, vaikka se olisi vaarallinen. Tähän kuuluu myös riski siitä, että joku ujuttaa agenttiin komennon sen lukeman tekstin kautta (tätä kutsutaan prompt injectioniksi).

Toinen rintama – valmis sovellus. Tämä on julkaisemasi ja ihmisten käyttämä sovellus. Kohteena on julkaistu sivustosi tai palvelusi: hyökkääjät pääsevät avoimeen tietokantaan, lähettävät väärennettyjä pyyntöjä tai arvaavat muiden tilejä. Agentilla ei ole tämän kanssa mitään tekemistä – aukko jäi jäljelle aiemmin, ja muut käyttävät sitä hyväkseen.

Anthropic, Claudea kehittävä yritys, ilmaisee tärkeimmän suojausperiaatteen näin – ja se pätee molempiin rintamiin:

Käytännössä tämä tarkoittaa, ettet luota siihen, että tekoäly ”välttää itse tekemästä pahoja asioita”. Rajoita ensin, mitä se voi konkreettisesti tehdä, ja pyydä sitä vasta sitten käyttäytymään hyvin. Kun sen toiminta pettää – ja niin käy – sinua suojaa vain ennalta asettamasi tiukka raja.

Haluatko, että tekoäly toimii ennakoitavasti eikä ammu sinua jalkaan jokaisessa uudessa projektissa? Tietoturvasäännöt ovat osa Second Brainia: kirjoita ne kerran CLAUDE.md-tiedostoon, niin agentti noudattaa niitä jokaisessa pyynnössä.

Mitä tekoälyagentti voi tehdä, kun sillä on pääsy tietokoneeseesi?#

Vähiten huomioitu riski on oma agenttisi, jolla on liian laajat oikeudet. Et tarvitse edes ulkopuolista hakkeria. Tässä on tuore esimerkki toukokuun 2026 lopulta. Codex-agentti tarvitsi järjestelmänvalvojan oikeuksia, joita käyttäjällä ei ollut. Agentti ei luovuttanut – se tarkasteli ympäristöä, huomasi käyttäjän kuuluvan docker-ryhmään, joka vastaa käytännössä root-oikeuksia, ja käytti tätä pääsyä.

Tässä ei ollut pahantahtoista tarkoitusta. Kun agenttia pyydetään ”ratkaisemaan tehtävä”, se vain löytää rakenteellisen heikkouden ihmistä nopeammin. Ja jos heikkous antaa sille pääsyn avaimiisi tai tuotantoympäristöön, se käyttää sitä. Siksi sääntö numero yksi on vähimmän oikeuden periaate. Anna agentille täsmälleen sen verran pääsyä kuin se tarvitsee tiettyyn tehtävään – ei yhtään enempää.

Mitä voit tehdä käytännössä, vaikka et olisi ohjelmoija?

1. Älä käytä agenttia tuotantokoneella ”salli kaikki” -tilassa

   Tila, jossa agentti ei pyydä vahvistusta (usein nimeltään bypass tai yolo), sopii vain hiekkalaatikkoon tai testiprojektiin, ei koneelle, jolla on aktiivisia avaimia ja tuotantoympäristön käyttöoikeuksia.

2. Kiellä agenttia lukemasta salaisuuksia

   Claude Codessa tämä tehdään säännöllä, joka estää pääsyn avaimia sisältäviin tiedostoihin. Silloin työkalu ei anna agentin avata edes .env-tiedostoa, vaikka agentti haluaisi.

3. Pidä tuotantoavaimet erillään

   Tuotantotietokannan ja maksupalvelun avainten ei pitäisi olla samassa kansiossa, jossa agentti kirjoittaa koodia. Pidä ympäristöt erillään: käytä kokeiluissa testiavainia.

4. Käytä työkalun hiekkalaatikkoa

   Nykyaikaiset tekoälytyökalut voivat suorittaa komentoja eristetyssä ympäristössä (hiekkalaatikossa), jossa niillä ei ole pääsyä muuhun järjestelmään. Claude Codessa tämä vähentää käyttöoikeuspyyntöjä noin 84 prosenttia, joten se on myös kätevämpää.

Claude Coden salaisuuksien lukemisen estävä sääntö näyttää suunnilleen tältä – lisää se käyttöoikeusasetuksiin:

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

Mihin API-avaimia ja salasanoja ei pidä koskaan laittaa?#

Halvin ja yleisin virhe on avainten laittaminen koodiin. Maksupalvelun API-avain, tietokannan salasana, botin tunniste – kaikki nämä ovat salaisuuksia. Ne kuuluvat erilliseen .env-tiedostoon, joka on merkittävä .gitignore-tiedostoon, jotta se ei päädy git-repositorioon koodin mukana.

Ongelman mittakaava vuonna 2025: julkisissa repositorioissa oli 28,65 miljoonaa uutta kovakoodattua salaisuutta, 34 prosenttia enemmän kuin vuotta aiemmin. Erityisesti tekoälypalveluiden avainten vuodot lisääntyivät 81 prosenttia. Vibe coding pahentaa tilannetta, koska agentti tekee committeja tarkistamatta mitään.

Tarkista nämä itse heti:

1. Avaa projektin .gitignore-tiedosto

   Varmista, että siinä on .env-rivi. Jos sitä ei ole, lisää se ennen ensimmäistä committia.

2. Siirry GitHub-repositorioon

   Tarkista, ettei .env-tiedostoa ole siellä. Voit tarkistaa asian nopeasti etsimällä repositoriosta .env-merkintää tai osaa avaimestasi.

3. Jos avain on vuotanut, mitätöi se ja luo uusi

   Commitin poistaminen ei riitä: avain on voitu jo varastaa. Siirry palveluun (maksupalvelun tarjoaja, pilvipalvelu tai tekoälypalvelun tarjoaja), mitätöi vanha avain ja luo uusi. Tätä kutsutaan kierrätykseksi.

4. Anna avaimille vähimmät tarvittavat oikeudet

   Jos avainta tarvitaan vain lukemiseen, määritä se vain luku -tilaan. Silloin vuodon seurauksena voidaan varastaa vähemmän.

Miksi kaikki voivat nähdä tietokantasi ilman RLS:ää?#

Jos rakennat sovellusta Supabasella tai vastaavalla tietokannalla, tämä on tärkein osio. RLS on lyhenne sanoista Row Level Security. Yksinkertaisesti sanottuna se on sääntö, joka määrittää, mitkä taulukon rivit näytetään tietylle käyttäjälle. Ilman sitä ”orders”-taulukko palauttaa kaikkien asiakkaiden tilaukset kaikille.

Näin Supabasen dokumentaatio itse kuvaa asian suoraan:

Tässä on vibe-koodaajan suurin sudenkuoppa. Kun luot taulukon napsauttamalla Supabase-hallintapaneelia, suojaus otetaan automaattisesti käyttöön. Kun taulukon luo tekoäly – ja se kirjoittaa lähes aina SQL-komennot suoraan – RLS pysyy oletusarvoisesti pois käytöstä. Agentin luoma taulukko on siis lähes varmasti avoin koko internetille. Juuri näin ne 170 Lovable-sovellusta vuotivat tietoja.

Toimi näin:

1. Kysy agentilta suoraan

   Kirjoita: ”näytä kaikki taulukot, joissa RLS on pois käytöstä”. Tekoäly tuottaa luettelon – se on työjonosi.

2. Ota RLS käyttöön jokaisessa käyttäjätietoja sisältävässä taulukossa

   Lisää myös vähintään yksi käyttöoikeuskäytäntö – esimerkiksi ”käyttäjä näkee vain omat rivinsä”.

3. Tarkista hallintapaneeli

   Supabase-hallintapaneelissa jokaisen taulukon kohdalla pitäisi näkyä ”RLS enabled”. Jos merkintä on harmaa tai punainen, taulukko on avoin.

4. Testaa oikeasti

   Kirjaudu sisään tavallisena käyttäjänä ja yritä pyytää jonkun muun tietoja. Jos pääsy evätään, käytäntö toimii.

Miksi käyttöliittymän käyttöoikeustarkistukset eivät suojaa sinua?#

Yleinen harhaluulo kuuluu: ”Estin tavallisia käyttäjiä näkemästä ylläpitopainiketta.” Ongelma on siinä, että painike on vain kuva selaimessa. Pyynnön voi lähettää suoraan palvelimelle käyttämättä painiketta. Jos palvelin ei tarkista käyttöoikeuksia uudelleen, se suorittaa jonkun toisen komennon.

Klassinen esimerkki on IDOR. Kuvittele, että avaat tilauksesi osoitteessa, jossa on id=123. Muuta se muotoon id=124, niin näet jonkun toisen tilauksen, koska palvelin ei tarkistanut, oliko tilaus todella sinun. Tämä on yksi vibe codingilla rakennettujen sovellusten yleisimmistä aukoista, ja heikot käyttöoikeustarkistukset aiheuttivat myös Tea-vuodon.

Sääntö on yksinkertainen: tee jokainen ”saako tämä käyttäjä tehdä tämän?” -tarkistus uudelleen palvelimella. Käyttöliittymä on käyttömukavuutta varten; suojaus kuuluu backendille. Agentille annettava valmis ohje: ”lisää palvelinpuolen käyttöoikeustarkistukset jokaiseen endpointiin, joka lukee tai muuttaa käyttäjätietoja; älä luota siihen, että elementti on piilotettu käyttöliittymässä.”

Miten voit etsiä koodista aukkoja, jos et ole ohjelmoija?#

Hyvä uutinen on, että nykyään voit pyytää samaa tekoälyä tarkistamaan tietoturvan – se löytää melko hyvin tavallisia aukkoja. Tässä on kolme työkalua eri tehtäviin.

1. Claude Coden /security-review-komento. Se tarkistaa nykyisestä branchista kertaalleen SQL-injektiot, XSS:n, valtuutusaukot, tietovuodot ja riippuvuusongelmat. Olen selittänyt vaihe vaiheelta, miten se toimii ja miten automaattinen tarkistus liitetään jokaiseen muutokseen erillisessä oppaassa, joka käsittelee tietoturvakatselmointia Claude Codessa. Tärkein asia tässä: se on ensimmäinen puolustuslinja, joka käynnistetään yhdellä komennolla.

2. Virallinen tietoturvaohjeistusliitännäinen. Asenna se virallisesta liitännäismarkkinapaikasta komennolla /plugin install security-guidance@claude-plugins-official (vaatii Claude Code -version 2.1.144 tai uudemman). Se tarkistaa koodin kolmessa vaiheessa: jokaisen muokkauksen yhteydessä, jokaisen vuoron lopussa ja commitin yhteydessä. Se tunnistaa käyttöoikeuksien ohitukset, IDOR:n, injektiot ja heikon kryptografian. Anthropic kertoo kuitenkin avoimesti sen rajoituksista:

npx skills add <author>/<repo>

Pyydä sitten agenttia yksinkertaisesti: ”tarkista projektini haavoittuvuuksien varalta”. Tähän kokoelmaan liittyy kuitenkin tärkeä varaus, minkä vuoksi käsittelen sitä omassa osiossaan alla.

Taustaksi: myös suuret toimijat ovat alkaneet suhtautua tekoälyn tuottaman koodin tietoturvaan vakavasti. Project Glasswingin laajentamisen yhteydessä 2. kesäkuuta 2026 niin, että se kattoi 150 organisaatiota, kumppanit löysivät lyhyessä ajassa yli 10 000 kriittistä haavoittuvuutta Anthropicin malleilla. Panokset ovat selvät:

Voiko GitHubista ladattuihin taitoihin ja laajennuksiin luottaa?#

Tämä on erityisen hankalaa, koska vaara tulee työkalusta, jonka asennat tietoturvan parantamiseksi. Kun suoritat npx skills add ... -komennon tai asennat laajennuksen, haet jonkun muun koodia, jota agentti sitten suorittaa sinun oikeuksillasi. Jos tekijän tili on hakkeroitu tai paketti oli haitallinen alusta asti, sinulla on ongelma.

Otetaan esimerkiksi edellisen osion taitokokoelma. Sen nimessä on ”Anthropic”, mikä saa sinut laskemaan suojauksiasi. Mutta sen omassa kuvauksessa sanotaan selvästi:

Nimi on siis harhaanjohtava. Kokoelma on tällä hetkellä kypsä ja puhdas, mutta periaate pätee silti: asennat sen omalla vastuullasi. Uhka ei ole teoreettinen. Toukokuussa 2026 haitallinen editorilaajennus oli markkinapaikalla vain 18 minuuttia – ja siinä ajassa se ehti varastaa salasananhallintasovellusten salasanoja, GitHub-tokeneita, pilvipalvelujen käyttöoikeuksia ja jopa Claude Code -kokoonpanoja sen asentaneilta ihmisiltä. Toinen ikävä yksityiskohta: tällainen haittaohjelma selviää usein tavallisesta paketin poistamisesta ja käynnistyy uudelleen seuraavassa istunnossa.

Olen ottanut tavaksi tehdä yhden yksinkertaisen asian ja suosittelen sitä sinullekin: tarkista itse kaikki GitHubista asennettavat taidot. Tekijöiden tilejä voidaan hakkeroida, tilejä kaapata ja haittaohjelmia lisätä repositorioon. Tarkistaminen on suojasi.

Käytännön vähimmäistoimet ennen asentamista: katso tekijä ja tähtien määrä, lue taidon kuvaus, älä asenna työkalua ”koska joku suositteli sitä yhdessä julkaisussa”, ja kokeile tuntematonta työkalua ensin erillisessä testiympäristössä, älä koneella, jolla on tuotantoavaimia.

Mikä auttaa tietomurron jälkeen: varmuuskopiot ja palautus#

Tietoturvassa ei ole kyse vain siitä, että ”ulkopuoliset pidetään loitolla”, vaan myös siitä, että ”palataan normaaliin, kun jokin menee pieleen”. Jokin menee pieleen ennemmin tai myöhemmin. Kuvatussa käytännön tapauksessa tekoälyagentti poisti tuotantoprojektin käytössä olevan tietokannan rutiinitehtävää hoitaessaan. Varmuuskopio oli olemassa, mutta se oli kolme päivää vanha – ja kolmen päivän tiedot katosivat kokonaan.

Tästä seuraa kaksi sääntöä.

Ota varmuuskopioita usein. Jos sovelluksessasi on tietoja, joiden menettämistä et kestäisi, kolmen päivän välein otettava kopio on vain näennäistä suojaa. Aseta automaattiset varmuuskopiot vähintään 30 minuutin välein. Useimmissa tietokannoissa, myös Supabasessa, tämän voi ottaa käyttöön muutamalla napsautuksella.

Git on vakuutus agentin varalta. Git tallentaa koodisi historian: voit palauttaa minkä tahansa toimivan tilan. Kun agentti kirjoittaa toimivan osan uudelleen, palaat viimeisimpään toimivaan versioon sen sijaan, että korjaisit kaiken käsin. Jos tekoäly poisti tai rikkoi projektin etkä tiedä, miten palauttaa se, lue erillinen selvitys: mitä tehdä, jos tekoäly poisti tietokannan. Katso oppaasta näin suojaat Claude Coden rikkoutumiselta, miten voit estää projektin rikkoutumisen ennakolta.

Tietoturvan tarkistuslista ennen julkaisua#

Käy tämä luettelo läpi juuri ennen julkaisua. Tässä järjestyksessä.

1. Salaisuudet .env-tiedostossa ja .env-merkintä .gitignore-tiedostossa. Ei avaimia koodiin. Ei .env-tiedostoa julkiseen repositorioon.

2. Avaimilla on vähimmäisoikeudet. Jokainen avain pystyy tekemään vain sen, mitä tarvitaan. Tuotantoavaimet ovat erillään agentin ympäristöstä.

3. RLS on käytössä kaikissa käyttäjätietoja sisältävissä taulukoissa, ja käyttöoikeuskäytännöt ovat paikoillaan.

4. Palvelinpuolen käyttöoikeustarkistukset jokaiselle tietoja käsittelevälle toiminnolle. Painikkeen piilottaminen käyttöliittymässä ei riitä. Testaa manuaalisesti muuttamalla osoitteen id-arvoa.

5. Webhook-allekirjoitusten varmennus. Jokainen ulkoisia ilmoituksia (maksut, lomakkeet) käsittelevä käsittelijä varmentaa allekirjoituksen.

6. Pyyntöjen nopeusrajoitus saapuville pyynnöille ja kalliille toiminnoille, jotta salasanoja ei voi arvata raakaan voimaan perustuvalla hyökkäyksellä eikä lasku kasva kohtuuttomaksi.

7. Agentti ei ole ”salli kaikki” -tilassa koneella, jolla on tuotantoavaimia. .env-tiedoston lukeminen on estetty.

8. Varmuuskopiot otetaan usein ja niiden toimivuus testataan – olet todella kokeillut palauttamista sen sijaan, että vain uskoisit kopioiden ”olevan jossain”.

9. Koodi on tarkistettu komennolla /security-review tai tietoturvaohjeistusliitännäisellä. Löydetyt ongelmat on korjattu.

10. Muiden tekemät taidot ja laajennukset on tarkistettu ennen asennusta. Mitään ei asennettu ”sokkona”.

Mistä aloittaa tänään?#

Älä yritä toteuttaa kaikkea tämän oppaan sisältöä yhden illan aikana – muuten et saa mitään tehtyä. Tee tänään nämä kolme tärkeintä asiaa:

1. Tarkista salaisuutesi. Avaa .gitignore, varmista, että siinä mainitaan .env, ja tarkista, ettei julkisessa repositoriossa ole avaimia. Jos avaimia on vuotanut, mitätöi ne ja luo uudet.
2. Kysy RLS:stä. Sano agentille: ”näytä taulukot, joissa RLS on pois käytöstä” – ja ota se käyttöön kaikkialla, missä säilytetään ihmisten tietoja.
3. Ota käyttöön usein tehtävät varmuuskopiot. Näin menetät ongelmatilanteessa minuutteja päivien sijaan.

Noudata sitten yllä olevaa tarkistuslistaa projektisi kasvaessa ja sen alkaessa käsitellä rahaa ja muiden ihmisten tietoja.

Vielä yksi asia. Vibe codingin tietoturvassa on kyse omistajan vastuusta. Sinun ei tarvitse ryhtyä tietoturva-asiantuntijaksi. Tekoäly rakensi tuotteesi yhdessä illassa – hienoa, mutta sinä olet siitä vastuussa. Tässä oppaassa kuvattu perustaso kertoo, miltä vastuu näyttää käytännössä.

Tietoturvasäännöt on sisällytettävä menetelmään, jotta tekoäly rakentaa tuotteen oikein alusta alkaen.

Voit jatkaa mallien käyttöä siirtymällä Ailootiin.