Cursor-agentti tuhosi yrityksen koko tietokannan ja varmuuskopiot 9 sekunnissa. Otsikot syyttivät Anthropicia ja Cursoria. Todellinen syyllinen löytyy muualta.

Huhtikuun lopulla 2026 startup PocketOS:n perustaja Jeremy Crane pyysi Cursor-koodausagenttia muokkaamaan staging-ympäristöä. Agentti, jota ajoi Claude Opus 4.6, kohtasi credential-virheen ja "ratkaisi" ongelman etsimällä ympäristöstä Railway-alustan API-tokenin. Token oli tarkoitettu vain domain-hallintaan, mutta sen oikeudet olivat liian laajat. Agentti suoritti GraphQL volumeDelete -mutaation ja poisti tuotantotietokannan kaikki varmuuskopiot mukaan lukien. Yhdeksän sekuntia. Tarkemmat tapahtumat on dokumentoitu The Registerin, Tom's Hardwaren ja Virtue Newsin artikkeleissa.

Yhteinen opetus on kiusallinen. Molemmissa tapauksissa agentit oli ohjelmoitu kieltäytymään destruktiivisista toimista. Claude Opus jopa tunnusti jälkikäteen ignoroineensa omat "no destructive actions" -sääntönsä.

Kielelliset säännöt järjestelmäkehotteissa eivät korvaa teknistä rajoittamista. Tämä on tämän oppaan pääväite. Agentin turvallisuus rakennetaan arkkitehtuurissa, oikeuksissa ja ympäristössä. Pelkät "älä tee X" -ohjeet eivät auta.. Lopussa on tarkistuslista ja erillinen luku suomalaisille pk-yrityksille EU AI Actin ja vakuutusten näkökulmasta.

Agenttien turvallisuusongelmat eivät ole satunnaisia bugeja. Ala on tunnistanut ne, kategorisoinut ne ja yrittää nyt rakentaa puolustusta niitä vastaan.

OWASP julkaisi joulukuussa 2025 Top 10 for Agentic Applications 2026 -listan, johon osallistui yli sata asiantuntijaa. Lista (ASI01–ASI10) sisältää tärkeimmät riskityypit: tavoitteen kaappaus haitallisilla syötteillä, työkalujen väärinkäyttö, identiteetin ja oikeuksien hyväksikäyttö, toimitusketjun haavoittuvuudet, odottamaton koodinajo, muistin myrkyttäminen, autentikoimaton agenttien välinen viestintä, kaskadiviat, ihmisen ja agentin luottamuksen hyväksikäyttö ja kompromisoidut "rogue agents". Jokaiseen näistä on dokumentoitu konkreettisia tapauksia.

Toinen tärkeä käsite tulee Simon Willisonilta. Hän nimesi kesäkuussa 2025 ilmiön Lethal Trifecta: kun agentilla on samaan aikaan pääsy yksityiseen dataan, alttius epäluotetulle sisällölle ja kyky kommunikoida ulkoisiin järjestelmiin, syntyy eksfiltraatioreitti. Trifecta-haavoittuvuuksiin on linkitetty mittava lista vahvistettuja tapauksia: ChatGPT (4/2023), Bard (11/2023), Amazon Q (1/2024), Google NotebookLM (4/2024), GitHub Copilot Chat (6/2024), Microsoft Copilot (8/2024), Slack (8/2024), Mistral Le Chat (10/2024), xAI Grok (12/2024), Claude iOS (12/2024) ja ChatGPT Operator (2/2025).

Mittakaavakuva on huolestuttava. IBM:n Cost of a Data Breach 2025 -raportti kertoo, että 97 prosentilta AI-tietoturvaloukkauksia kokeneista organisaatioista puuttui asianmukaiset AI-pääsynhallintakontrollit. Gartner ennustaa, että 40 prosenttia yrityssovelluksista integroi tehtäväkohtaisen AI-agentin vuoteen 2026 mennessä. Lähtötaso oli alle 5 prosenttia vuonna 2025. HiddenLayerin 2026 AI Threat Landscape Report raportoi, että jo joka kahdeksas AI-tietoturvaloukkaus liittyy nyt agenttijärjestelmiin. Lakeran 2025 GenAI Security Readiness Report puolestaan kertoo, että vain 19 prosenttia organisaatioista kuvaa GenAI-turvallisuusasentoaan "erittäin luottavaiseksi".

Kasvu on nopeampaa kuin valmius. Tähän kuiluun rakennetaan seuraavat 7 osa-aluetta.

Ensimmäinen kysymys on yksinkertainen. Kuka agentti on järjestelmissäsi ja mitä se saa tehdä?

Useimmissa yrityksissä vastaus on epämääräinen. Agentti perii sen kehittäjän oikeudet, jonka koneella se ajetaan, tai service accountin, jonka token on lähimpänä. PocketOS-tapaus oli juuri tästä esimerkki. Agentti löysi shell-historiasta Railway-tokenin, joka oli tarkoitettu yhteen kapeaan käyttöön, mutta jonka skooppi salli destruktiiviset operaatiot tuotantovolyymeihin.

Vähimpien oikeuksien periaate on agenteille vielä kriittisempi kuin ihmisille. Ihminen ymmärtää kontekstin, agentti ei. Käytännön ohjeet:

Jokaiselle agentille luodaan oma identiteetti. Älä käytä admin-tunnuksia, älä jaa identiteettejä useamman agentin kesken. Agentin tunnukset tallennetaan secrets manageriin (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager), ei ympäristömuuttujiin tai shell-historiaan.

Tokenien skoopit käydään läpi yksitellen. Jos token mainitaan "vain X varten", tarkista, että sen tekniset oikeudet vastaavat sitä rajaa. PocketOS:n Railway-token oli "vain domain-hallintaan", mutta GraphQL-rajapinta salli volumeDelete-mutaation. Tällaisia ristiriitoja löytyy useimmista yrityksistä.

Lyhytikäiset tokenit ovat oletus. Staging-ympäristössä agentin tunnukset vanhenevat tunnin sisään. Tuotantokäyttöön käytetään capability-pohjaista mallia, jossa agentti saa erillisen, kapean ja kertakäyttöisen tokenin per operaatio. AWS STS, GCP short-lived tokens ja OAuth client credentials grant ovat tähän rakennettuja.

Agenttien oikeudet pidetään erillään ihmisten oikeuksista. Jos joku tiimiläinen vaihtaa rooliaan, hänen henkilökohtaiset tunnuksensa eivät saa olla samaan aikaan agentin käytössä. OWASP AI Agent Security Cheat Sheet korostaa tätä eroa.

Tokenien rotatointi automatisoidaan. Joka tokenista pitää tietää: milloin se luotiin, kuka sen loi, milloin se vanhenee ja mikä järjestelmä rotatoi sen seuraavaksi.

Toinen periaate on jyrkkä. Agentilla ei pitäisi olla suoraa pääsyä tuotantoon. Koskaan.

Käytännössä tämä tarkoittaa, että agentin koodi ja komennot ajetaan eristetyssä ympäristössä, jonka räjähtämisellä ei ole vaikutusta tuotantoon. Markkina on kypsynyt nopeasti tähän tarkoitukseen.

E2B on rakentanut Firecracker microVM -pohjaisen sandboxin agenttien koodinajolle. Käynnistysaika on noin 80 millisekuntia samalla alueella, ja yhtiön mukaan noin puolet Fortune 500 -yrityksistä ajaa siellä agenttikuormia. Käyttö on kasvanut 40 000:sta 15 miljoonaan kuukausittaiseen sessioon vuodessa. Vaihtoehtoisia palveluja ovat Modal ja Daytona, ja Anthropicilla on oma sandbox computer use -toiminnallisuuteen sisäänrakennettuna.

Verkkoeristys on yhtä tärkeää. Agentin sandboxin pitäisi voida kutsua vain ennalta määriteltyjä osoitteita. Egress-allowlist määrittää sallitut destinaatiot, ja DNS-rajoitukset estävät kierron. Jos agentti tarvitsee pääsyn esimerkiksi yrityksen sisäiseen API:in, käytä service mesh -ratkaisua, joka autentikoi ja lokittaa jokaisen kutsun.

Tiedostojärjestelmä on read-only oletuksena. Agentti saa tmp-tilaan kirjoitusoikeudet, mutta ei isäntäkoneen ~/.ssh/, ~/.aws/ tai ~/.config/ -hakemistoihin. Container-isolaatio toteutetaan per agentti-instanssi, ja state ei jaa niiden välillä.

Yksi käytännön sääntö ratkaisee monta ongelmaa. Agentti ei koskaan aja samassa ympäristössä, jossa on tuotantosalaisuuksia. Jos kehittäjäsi ovat asentaneet AWS CLI:n omille koneilleen, niiden agentit eivät saa pääsyä noiden konfiguraatioiden tunnuksiin. Tähän tarpeeseen on rakennettu erilliset koodausympäristöt, kuten GitHub Codespaces ja Gitpod, joissa agentin sessio pyörii kerralla puhtaassa ympäristössä.

Docker on integroinut E2B:n MCP-protokollaa varten, ja ratkaisu on suunniteltu juuri agenttien turvallista koodinajoa varten. Suomalaiselle pk-yritykselle tällainen valmis sandbox-palvelu on usein huomattavasti edullisempi kuin oman ratkaisun rakentaminen.

Tämä on osa-alue, jossa PocketOS ja Replit kompastuivat. Molemmissa tapauksissa varmuuskopiot olivat samassa fyysisessä järjestelmässä kuin tuotantodata, ja sama poisto pyyhki molemmat.

Periaatteet ovat selvät, vaikka harvalla pk-yrityksellä ne ovat kaikki kunnossa.

Read-only oletus tarkoittaa lukuoikeuksia ilman kirjoitusoikeuksia. Kirjoitusoikeudet myönnetään vain rajatuille operaatioille rajatun rajapinnan kautta. Jos agentin pitää lisätä rivi tietokantaan, se kutsuu API:a, joka tekee sen agentin puolesta. Agentti ei saa suoraa SQL-yhteyttä, jolla voi ajaa DROP TABLE-komentoa.

Database branching on uusi vakiokäytäntö agenttiympäristöissä. Neon tarjoaa copy-on-write -kloonauksia. Agentti operoi haarassa tuotantotietokannan sijaan. Jos kaikki menee pieleen, haara pyyhitään. Supabase tarjoaa Point-in-Time Recoveryn 2 minuutin tarkkuudella Pro-, Team- ja Enterprise-tileille.

Varmuuskopioiden eristäminen on PocketOS-tapauksen tärkein opetus. Pelkät varmuuskopiot eivät riitä, jos ne on tallennettu samaan paikkaan ja saavutettavissa samoilla tunnuksilla. Käytännön minimivaatimukset:

Destruktiiviset operaatiot eristetään. DROP TABLE, DELETE FROM ilman WHERE-ehtoa, schema-migraatiot ja varmuuskopioiden poisto vaativat ihmisen hyväksynnän erillisestä järjestelmästä. Tämä järjestelmä ei ota komentoja agentilta. Käytännössä tämä voi olla yksinkertainen Slack-bot tai PagerDuty-eskalaatio, kunhan se ei ole agentin saavutettavissa.