1. Älä luota yhteen kielimalliin
Käytä kahta mallia ristiin: yksi tekee suunnitelman ja koodin, toinen reviewaa sen ennen toteutusta. Ideana on sama kuin kysyisit myyjältä, miten viikko meni — "ihan mahtavasti" on eri asia kuin "soititko kenellekään". Kielimallit eivät oma-aloitteisesti kyseenalaista omaa työtään, mutta ne kyllä haastavat toisensa, jos niiden annetaan tehdä niin.
Käytännössä: yksi malli kirjoittaa suunnitelman ja koodin, toinen malli saa tehtäväksi vain reviewata suunnitelman ennen kuin yhtään riviä kirjoitetaan. Tämä lisää muutaman minuutin per tehtävä, mutta vähentää korjauskierroksia — ja korjauskierrokset ovat se, mikä oikeasti syö tokenit ja ajan.
2. Valitse malli tehtävän mukaan, ei tottumuksen mukaan
Mallien välillä on aitoja eroja erikoisosaamisessa. Suomenkielisessä sisällössä ja koodikommenteissa erot näkyvät selvästi mallista toiseen. Sama pätee koodaukseen: yksi malli on parempi arkkitehtuurissa, toinen debuggauksessa. Yhden mallin pakottaminen kaikkeen on kuin vaatisi kirjanpitäjää tekemään myös myyntityön — onnistuu, muttei parhaalla mahdollisella tavalla.
3. Älä koskaan altista API-avaimia tai .env-tiedostoja terminaalille
Tämä on se kohta, jossa suurin osa vahingoista tapahtuu. Kun agentti ajetaan terminaalissa ja se lukee ympäristömuuttujia tai .env-tiedostoja suoraan, jokainen avain on periaatteessa agentin — ja kaikkien sen kautta kulkevien pyyntöjen — käsissä. Jos joku onnistuu injektoimaan agenttiin haitallisia ohjeita (katso kohta 6), se ei tarvitse murtautua mihinkään: se pyytää kohteliaasti, ja avain on jo siellä.
Oletusarvoisesti mikään malli ei varoita sinua etukäteen siitä, että se on käyttämässä lisenssejäsi tai avaimiasi tavalla, josta et pidä.
4. Käytä salasananhallintaa + SSH-agenttia — älä avaimia paljaana levyllä
Ratkaisu kohtaan 3 on yksinkertainen: salasanaholvi (esim. 1Password tai vastaava) yhdistettynä SSH-agenttiin CLI:n yli. Käytännössä terminaali ei koskaan näe salasanaa tai API-avainta selkokielisenä — agentti pyytää holvilta valtuutuksen, holvi antaa sen kertakäyttöisesti, eikä mitään jää lojumaan levylle tai komennon historiaan.
Tämä ratkaisee myös toisen ongelman: kun avaimet ovat keskitetysti holvissa eikä hajallaan muistiinpanoissa tai Google Drivessa, sinulla on audit trail siitä, kuka käytti mitä ja milloin — sama periaate kuin tilinpäätöksen tositteilla.
5. Vie kaikki GitHubiin — myös konteksti, ei vain koodi
Agents.md-tiedosto, työloki ja commit-historia GitHubissa tarkoittavat, että jokainen muutos on jäljitettävissä: kuka teki, mitä teki, ja missä avaimet sillä hetkellä olivat. Tämä ei ole vain devaajan mukavuus — se on myös se, mitä tarvitset, jos joudut selvittämään jälkikäteen mitä tapahtui.
6. Älä käytä autoapprove- tai YOLO-tilaa lukematta koodia
Jos agentti committaa tai suorittaa komentoja ilman että kukaan lukee diffiä, huomaat prompti-injektion vasta kun on liian myöhäistä. Tämä ei ole teoreettinen riski. Kesällä 2026 piilotettu prompti-injektio verkkosisällössä sai yhden meidän tuntemamme käyttäjän agentin yrittämään päästä käsiksi Google-tunnuksiin — pelkästään siksi, että sivun tekstin seassa oli agentille suunnattu ohje, jota kukaan ihminen ei nähnyt ennen kuin agentti oli jo toiminut sen mukaan.
Jos agentti pyytää yhtäkkiä lupaa johonkin, mitä et ole pyytänyt — pysäytä, älä hyväksy.
7. Muista, ettei muisti synkkaa mallien välillä
Agents.md tai vastaava kontekstitiedosto ei siirry automaattisesti mallista toiseen, kun vaihdat kesken projektin. Tämä on tekninen yksityiskohta, mutta sillä on liiketoiminnallinen seuraus: kontekstin katoaminen tarkoittaa hitaampaa työtä ja suurempaa riskiä, että agentti tekee jotain mitä se ei "muista" olleen jo kielletty. Pidä konteksti keskitetysti versionhallinnassa, älä yhden mallin muistissa.
8. Pidä perusasiat kunnossa — ne ovat yhä suurin riski
Noin 95 % WordPress-sivustojen murroista tapahtuu vanhentuneiden lisäosien kautta, ei mitenkään eksoottisten AI-hyökkäysten kautta. Automaattiset varmuuskopiot, kaksivaiheinen tunnistautuminen, kirjautumisyritysten rajoitus ja ajantasaiset päivitykset estävät edelleen suurimman osan yrityksistä. Murtoyrityksiä tehdään päivittäin sadoittain per sivusto — riippumatta siitä onko sivustolla liikennettä vai ei.
Sama koskee sääntelyä: jos yrityksesi on osa toimitusketjua johonkin huoltovarmuuskriittiseen toimijaan, NIS2 koskee sinua epäsuorasti alihankkijana, vaikka et itse olisikaan suoraan lain piirissä. Kirjoitimme tästä tarkemmin NIS2-direktiivin perusteet -artikkelissa.
Miksi tämä ei ole vain devaajien ongelma
AI-agentit ovat tehneet koodauksesta nopeampaa kuin koskaan, mutta ne ovat myös tehneet yhdestä väärin konfiguroidusta terminaalista koko yrityksen tietoturvan heikoimman lenkin. Sama logiikka pätee verkkosivustoon: halvassa webhotellissa päivitykset, varmuuskopiot ja valvonta jäävät sinun vastuullesi — täsmälleen niiden riskien varaan, joita edellä listattiin.
Kun analysoimme asiakkaidemme sivustoja ennen siirtoa meille, löydämme säännöllisesti samat asiat: vanhentuneita lisäosia, julkisesti näkyviä admin-käyttäjätunnuksia ja kuukausien takaisia varmuuskopioita. Katso audit-tutkimuksemme 2026, jossa kävimme läpi 209 auditiraporttia ja kokosimme niistä 20 tilastohavaintoa siitä, missä kunnossa suomalaiset sivustot todellisuudessa ovat. Sama työ kuuluu WordPress-ylläpitoon ja palomuuriin ja valvontaan, ei terminaalin YOLO-tilaan.
Yhteenveto
AI nopeuttaa työtä radikaalisti, mutta jokainen avain, jonka annat agentille ilman valvontaa, on avain jonka annat myös kaikille sille pääsyn saaville. Rakenna prosessi niin, ettei yksikään yksittäinen virhe — oma tai mallin — johda katastrofiin: kahden mallin ristiinreview, avaimet holviin, autoapprove pois, ja perusasiat (päivitykset, varmuuskopiot, palomuuri) kuntoon riippumatta siitä kuinka moderni työkalupakki muuten on.
Onko sivustosi ylläpito ja tietoturva kunnossa riippumatta siitä kuka koodaa — ihminen vai agentti? Tarkista sivustosi maksutta tai katso pakettimme.