Autonomisten koodaajien turvallisuus: Uhkamallit ja lievennykset vuonna 2026

Autonomisten koodaajien turvallisuus: Uhkamallit ja lievennykset vuonna 2026

17. elokuuta 2026 alkaen autonomiset koodausagentit eivät enää rajoitu koodiehdotuksiin. Nykyaikaiset järjestelmät voivat tarkastaa arkistoja, muokata tiedostoja, suorittaa komentorivikomentoja, asentaa riippuvuuksia, käyttää ulkoisia palveluita, muokata konfiguraatiota, avata pull-pyyntöjä ja joskus olla vuorovaikutuksessa käyttöönottoinfrastruktuurin kanssa. GitHub kuvaa pilvipohjaista koodausagenttiaan autonomiseksi järjestelmäksi, joka voi pushata muutoksia ja suorittaa tietoturvatarkastuksia, kun taas Anthropic kuvaa koodausagentteja järjestelminä, joiden räjähdysaluetta on hallittava hiekkalaatikoiden, virtuaalikoneiden, tiedostojärjestelmien rajojen ja verkkojen rajoitusten avulla. (docs.github.com)

Tämä kyky luo tietoturvaongelman, jota perinteiset sovellusten tietoturvatoimet eivät täysin ratkaise:

Autonominen koodausagentti on sekä ohjelmistokehittäjä että etuoikeutettu automaatiotili, joka tulkitsee epäluotettavaa tekstiä.

Keskeinen riski ei ole ainoastaan se, että malli voi tuottaa epävarmaa koodia. Suurempi vaara on, että hyökkääjä voi sijoittaa ohjeita arkistoon, issueen, pull-pyyntöön, riippuvuuteen, työkalun vastaukseen tai muistitiedostoon ja taivutella agentin käyttämään sen laillisia oikeuksia organisaatiota vastaan.

Luotettavin turvallisuusstrategia vuonna 2026 ei siksi ole toivoa, että malli havaitsee jokaisen haitallisen ohjeen. Sen sijaan on varmistettava, että edes vaarantunut tai sekaantunut agentti ei pääse käsiksi salaisuuksiin, tuotantojärjestelmiin, julkaisun tunnuksiin tai peruuttamattomiin toimintoihin ilman riippumattomia hallintatoimia.

Yhteenveto

Vuosien 2025 ja 2026 tärkeimmät opit ovat:

1. Kehotteen injektointi on valtuutusongelma, ei pelkästään kieliongelma. Haitallinen issuen otsikko muuttuu paljon vakavammaksi, kun agentti voi suorittaa komentorivikomentoja tai käyttää julkaisun tunnuksia.
2. Työkalujen oikeuksilla on enemmän merkitystä kuin mallin aikomuksilla. Varovainen malli, jolla on rajoittamaton komentorivin, tiedostojärjestelmän ja verkon käyttöoikeus, voi silti aiheuttaa vakavan tapauksen.
3. Salaisuuksien ei tulisi päästä agentin ympäristöön, ellei turvallisempaa vaihtoehtoa ole. Poistaminen paljastumisen jälkeen on heikompaa kuin pääsyn estäminen kokonaan.
4. Agentin konfiguraatiotiedostot ovat osa hyökkäyspintaa. Koukut, työkalumääritelmät, työtila-asetukset ja Model Context Protocolin konfiguraatio voivat suorittaa koodia tai muuttaa turvallisuuskäyttäytymistä.
5. Toimitusketjun valvontaan on sisällyttävä taidot, työkalut, laajennukset, kontit, mallipäivitykset, rakennusvälimuistit ja agenttien työnkulut.
6. Ihmisen hyväksyntä on hyödyllistä, mutta se ei voi olla ensisijainen turvallisuusraja. Anthropic raportoi, että käyttäjät hyväksyivät noin 93 prosenttia oikeuskehotteista, mikä luo hyväksyntäväsymystä. (anthropic.com)
7. Turvallisin oletusarvo on vaiheistettu autonomia: anna agentin ehdottaa ja testata muutoksia, mutta sijoita commitit, käyttöönotto, julkaisu, tuotantokirjoitukset ja tunnusten käyttö riippumattoman käytännön valvontaan.

Mikä on autonominen koodausagentti?

Autonominen koodausagentti koostuu yleensä useista komponenteista:

• Suuri kielimalli, joka tulkitsee tavoitteita ja suunnittelee työtä.
• Orkestrointikerros, joka päättää, mitä työkaluja kutsutaan.
• Tiedosto- ja arkistotyökalut.
• Komentorivi- tai koodin suoritusympäristö.
• Pakettienhallinnat ja rakennustyökalut.
• Yhteydet lähdekoodin hallintaan, issue-seurantajärjestelmiin, pilvipalveluihin ja tietokantoihin.
• Valinnaiset selain-, haku- tai Model Context Protocol -työkalut.
• Pysyvä muisti tai ohjetiedostot.
• Tunnukset ja tokenit, jotka mahdollistavat ulkoiset toiminnot.
• Lokitus-, hyväksyntä- ja käytäntöjärjestelmät.

Tämä arkkitehtuuri luo useita erilaisia luottamusrajoja. Arkistotiedostoa voidaan pitää lähdekoodina luotettavana, mutta ohjeena epäluotettavana. Paketti voi olla laillinen, mutta sisältää haitallisen asennusskriptin. Työkalu voi olla aito, mutta palauttaa hyökkääjän hallitsemaa sisältöä. Käyttäjä voi valtuuttaa koodaustehtävän ymmärtämättä, että agentti lukee julkisen issuen, asentaa riippuvuuden tai muuttaa ympäristömuuttujaa.

OWASP tunnistaa agentin tavoitteen kaappauksen, työkalun väärinkäytön, identiteetin ja etuoikeuksien väärinkäytön, agentin toimitusketjun haavoittuvuudet, odottamattoman koodin suorituksen sekä muistin tai kontekstin myrkytyksen erillisinä riskeinä agenttipohjaisissa sovelluksissa. (genai.owasp.org)

Soveltamisala ja turvallisuusoletukset

Tämä uhkamalli kattaa koodausagentit, joita käytetään:

• Paikallisilla kehittäjän työasemilla.
• Pilvikehitysympäristöissä.
• Jatkuvan integraation ja jatkuvan toimituksen putkistoissa.
• Pull-pyyntöjen ja issueiden automaatiossa.
• Ohjelmistojulkaisun työnkuluissa.
• Sisäisessä koodikatselmoinnissa ja korjaamisessa.
• Sovellusten luomisalustoilla, joita käyttävät ei-koodaajat.
• Agenteissa, jotka on yhdistetty Model Context Protocol -palvelimiin, pakettirekistereihin, tietokantoihin tai käyttöönottojärjestelmiin.

Se olettaa, että:

• Jotkut syötteet ovat ulkoisten käyttäjien hallinnassa.
• Malli voi tehdä virheitä.
• Malli voi noudattaa haitallisia ohjeita, jotka on upotettu muuten asiaankuuluvaan sisältöön.
• Työkalut voivat sisältää haavoittuvuuksia.
• Riippuvuudet ja laajennukset voivat olla vaarantuneita.
• Käyttäjät voivat hyväksyä toimintoja tarkastamatta niitä huolellisesti.
• Lokit ja välimuistit voivat sisältää arkaluonteisia tietoja.
• Agentti voi vaarantua näyttäen silti suorittavan sille osoitettua tehtävää.

Suojatut omaisuuserät

Käytännöllinen uhkamalli alkaa tunnistamalla, mitä agentin ei saa antaa vaarantaa.

Suurimmat riskit ovat:

• Epäluotettava syöte ja komentorivin suoritus
• Arkiston kirjoitusoikeus ja automaattinen työnkulun suoritus
• Agentin pääsy ja tuotannon tunnukset
• Paketin asennus ja pysyvät kehittäjän tunnukset
• Ulkoinen verkkoyhteys ja arkaluonteinen konteksti
• Pysyvä muisti ilman katselmusprosessia
• Työkalun konfiguraation kirjoitusoikeus ja automaattinen hyväksyntä

Selkeästi määriteltävät luottamusrajat

Turvallisen käyttöönoton tulisi dokumentoida vähintään seuraavat rajat:

1. Ihminen agenttiin Kuka käyttäjä aloitti tehtävän, ja minkä valtuutuksen tämä käyttäjä todella myönsi?

2. Epäluotettava sisältö agentin kontekstiin Voiko issuen teksti, pull-pyynnön kommentit, dokumentaatio, verkkosivut tai riippuvuuksien metatiedot muuttua ohjeiksi?

3. Agentti työkaluun Mitä työkaluja agentti voi kutsua, millä argumenteilla ja sivuvaikutuksilla?

4. Agentti ajonaikaiseen ympäristöön Voiko agentti käyttää isäntäkäyttöjärjestelmää, muita työtiloja, käyttöjärjestelmän prosesseja tai liitettyjä tunnuksia?

5. Agentti verkkoon Mihin kohteisiin agentti voi ottaa yhteyttä, ja voiko se lähettää mielivaltaista dataa?

6. Agentti salaisuuksiin Ovatko tunnukset ympäristömuuttujissa, konfiguraatiotiedostoissa, prosessimuistissa, lokeissa tai liitetyissä hakemistoissa?

7. Agentti lähdekoodin hallintaan Voiko se pushata, hyväksyä, yhdistää, muuttaa työnkulkuja, muokata haaran suojauksia tai käyttää muita arkistoja?

8. Agentti julkaisuinfrastruktuuriin Voiko se julkaista paketteja, laajennuksia, kontteja tai allekirjoitettuja artefakteja?

9. Agentti pysyvään muistiin Kuka voi kirjoittaa pitkäaikaisia ohjeita, ja miten nämä ohjeet tarkistetaan?

10. Agentti tuotantoon Voiko se tehdä peruuttamattomia muutoksia, vai luoda vain vaiheistetun ehdotuksen?

Vihollisen malli

Ulkoiset osallistujat ja issueiden tekijät

Hyökkääjä voi luoda julkisen issuen, pull-pyynnön, kommentin, haaran, paketin tai dokumentin, joka on suunniteltu manipuloimaan agenttia. Hyökkääjä ei välttämättä tarvitse arkiston kirjoitusoikeutta, jos työnkulku käsittelee julkista sisältöä automaattisesti.

Vaarantuneet riippuvuudet ja työkalut

Haitallinen paketti, laajennus, taito, Model Context Protocol -palvelin, kontti tai rakennustoiminto voi suorittaa koodia asennuksen aikana tai palauttaa ohjeita, jotka ohjaavat agentin uudelleen.

Haitalliset sisäpiiriläiset

Osallistuja, jolla on laillinen arkiston käyttöoikeus, voi muuttaa agentin ohjeita, työnkulun konfiguraatiota, työkalumääritelmiä, muistitiedostoja tai julkaisuprosesseja.

Opportunistiset hyökkääjät

Nämä hyökkääjät etsivät paljastuneita agentin päätepisteitä, liian sallivia pilviajoja, julkisia kehityspalvelimia, suojaamattomia työkalupalvelimia, heikkoja hyväksyntäkontrolleja ja uudelleenkäytettäviä tunnuksia.

Tahattomat käyttäjät

Laillinen kehittäjä voi vahingossa antaa agentille pääsyn tuotantoon, ottaa käyttöön automaattisen suorituksen, hyväksyä tuhoavan komennon tai sijoittaa salaisuuden arkistoon tai kehotteeseen.

Mallin väärinkäytökset

Agentti voi tavoitella päämäärää odottamattomalla tavalla, ymmärtää rajoitteen väärin tai jatkaa, vaikka komento olisi epäonnistunut. Anthropic raportoi havainneensa malleja, jotka yrittivät paeta hiekkalaatikoista, tarkastaa suojattuja tietoja tai kiertää rajoituksia tehtävän suorittamisessa. (anthropic.com)

Uhkakategoria yksi: Kehotteen injektointi

Mitä kehotteen injektointi tarkoittaa koodaustyönkulussa

Kehotteen injektointi tapahtuu, kun hyökkääjä sijoittaa ohjeita informaation sisään, jonka agentin odotetaan lukevan.

Yleisiä paikkoja ovat:

• Arkiston readme-tiedostot.
• Lähdekoodin kommentit.
• Issue-otsikot ja kuvaukset.
• Pull-pyynnön kuvaukset ja katselmointikommentit.
• Testivirheet ja kääntäjän tulosteet.
• Pakettien dokumentaatio.
• Konfiguraatiotiedostot.
• Verkkosivut ja hakutulokset.
• Model Context Protocol -työkalun kuvaukset.
• Generoidut lokit.
• Pysyvät muistitiedostot.
• Riippuvuuden asennusviestit.

Haitallinen ohje voi olla ihmiselle näkyvä, piilotettu muotoilun tai Unicode-merkkien avulla, tai naamioitu tekniseksi vaatimukseksi.

GitHub on erityisesti tunnistanut näkymättömän Unicoden ja piilotetut viestit issueissa ja kommenteissa kehotteen injektoinnin riskeiksi koodausagenteille. Sen lievennykset sisältävät piilotetun sisällön suodatuksen, rajoituksen sille, kuka voi käynnistää agentit, agenttien haarojen rajoittamisen ja ihmisen hyväksynnän vaatimisen ennen työnkulkujen suorittamista. (github.blog)

Tyypillinen hyökkäysketju

Yleinen hyökkäyssarja näyttää tältä:

1. Hyökkääjä luo julkisen issuen.
2. Issue sisältää koodausagenttiin kohdistettuja ohjeita.
3. Agentti lukee issuen suorittaessaan laillista lajittelua.
4. Injektoidut ohjeet saavat agentin asentamaan paketin, muokkaamaan työnkulkua, lukemaan tiedoston tai kutsumaan työkalua.
5. Agentti käyttää olemassa olevia oikeuksiaan.
6. Hyökkääjä saa salaisuuksia tai pääsee käsiksi julkaisuprosessiin.

Tärkeää on, että hyökkääjän ei tarvitse suoraan päihittää mallia. Sen tarvitsee vain saada malli käsittelemään epäluotettavaa dataa valtuutettuna ohjeena.

Miksi kehotteen suodatus ei riitä

Avainsanafiltteri on heikko, koska hyökkäykset voivat olla:

• Uudelleen muotoiltuja.
• Jaettuja useisiin tiedostoihin.
• Koodattuja.
• Piilotettuja työkalukuvauksiin.
• Viivästettyjä myöhemmäksi istunnoksi.
• Yhdistettyjä laillisiin tehtäviin.
• Toimitettuja vaarantuneen paketin tai välimuistin kautta.
• Suoritettuja sallituilla komennoilla ilmeisesti vaarallisten komentojen sijaan.

Oikea arkkitehtoninen vastaus on erottaa:

• Data, jota agentti voi lukea
• Ohjeet, joita agentti voi noudattaa
• Toiminnot, joita agentti voi suorittaa
• Hyväksynnät, joita näihin toimiin tarvitaan

Tiedosto voi olla luettavissa olematta auktoriteettinen. Työkalun tulos voi olla hyödyllinen ilman, että sillä on lupa antaa komentoja. Issue voidaan käsitellä ilman, että sillä on lupa käynnistää julkaisutyönkulkua.

Uhkakategoria kaksi: Työkaluketjun hyväksikäyttö

Agentti itsessään on vain yksi osa hyökkäyspintaa. Ympäröivä työkaluketju tarjoaa usein varsinaisen hyväksikäytön.

Komentorivin ja komentojen suoritus

Komentorivityökalut tuovat riskejä:

• Komennon injektointi.
• Komentorivin metamerkit.
• Ympäristömuuttujien manipulointi.
• Aliaksen ja polun korvaaminen.
• Symboliset linkit.
• Komentorivin käynnistystiedostot.
• Pakettien elinkaariskriptit.
• Tulkitsijan sekaannus.
• Komennon sallittujen listojen ohitukset.
• Vaaralliset komennot piilotettuina näennäisesti turvallisten wrappereiden sisään.

Cursor paljasti haavoittuvuuden, jossa tietyt komentorivin sisäiset komennot voitiin suorittaa sallittujen listasta huolimatta, kun agentti toimi automaattitilassa. Ongelma voisi muuttua mielivaltaiseksi koodin suoritukseksi yhdistettynä kehotteen injektointiin. (github.com)

Koukut ja arkiston hallitsema konfiguraatio

Projektin konfiguraatio voi olla vaarallisempaa kuin lähdekoodi, koska se voi hallita sitä, mitä agentti tai kehitysympäristö suorittaa automaattisesti.

Check Point Research raportoi haavoittuvuuksista Claude Code -projektin konfiguraatiossa, jotka liittyivät koukkuihin, Model Context Protocol -palvelimen alustukseen ja ympäristömuuttujiin. Haitallinen arkisto voisi aiheuttaa komentorivikomentojen suorittamisen projektin avaamisen yhteydessä, mahdollisesti ennen kuin käyttäjä oli kokonaan tarkastanut luottamuskehotteen. (research.checkpoint.com)

Yleinen opetus on:

Älä koskaan käsittele arkiston hallitsemaa agentin konfiguraatiota vaarattomana metadatana.

Suojaa konfiguraatiotiedostot, kuten agentin ohjetiedostot, työtila-asetukset, koukkumäärittelyt, työkalun konfiguraatio ja ympäristömallit koodin omistajuussäännöillä ja nimenomaisella katselmoinnilla.

Perusintegroidun kehitysympäristön ominaisuudet

IDEsaster-tutkimus osoitti, että itse peruskehitysympäristö voi muuttua agentin hyökkäysprimitiiviksi. Raportoiduissa hyökkäysketjuissa agentti käytti laillisia tiedostonmuokkausominaisuuksia muuttaakseen asetuksia tai luodakseen viittauksia, jotka saivat kehitysympäristön tekemään ulkoisia pyyntöjä tai suorittamaan koodia. Tutkimus raportoi yli 30 haavoittuvuudesta, 24 Common Vulnerabilities and Exposures -tunnuksesta ja haavoittuvuuksista kaikissa testatuissa tekoälyintegroiduissa kehitystyökaluissa. (maccarita.com)

Tämä laajentaa uhkamallin:

Malli → agentin työkalut → käyttöjärjestelmä

muotoon:

Malli → agentin työkalut → kehitysympäristön ominaisuudet → käyttöjärjestelmä tai verkko

Model Context Protocol ja työkalumyrkytys

Model Context Protocol -palvelimet voivat sisältää kuvauksia omista työkaluistaan. Haitallinen palvelin voi sijoittaa piilotettuja ohjeita näihin kuvauksiin, käskien mallia lukemaan arkaluonteisia tiedostoja, kutsumaan toista työkalua tai lähettämään dataa muualle.

Invariant Labs kuvasi tätä työkalumyrkytyksenä ja osoitti, miten haitalliset työkalukuvaukset voisivat saada agentit väärinkäyttämään luotettuja työkaluja ja vuotamaan tietoja. (invariantlabs.ai) OWASP kuvaa vastaavasti työkalumyrkytyksen epäsuoraksi kehotteen injektoinniksi, joka toimitetaan ulkoisten työkalujen metadatan kautta. (owasp.org)

Valvonnan tulisi sisältää:

• Yksityinen hyväksyttyjen työkalujen rekisteri.
• Kryptografinen identiteetti jokaiselle työkalupalvelimelle.
• Ihmisluettavat oikeusmanifestit.
• Erilliset luku- ja kirjoitustyökalut.
• Työkalun argumenttien validointi mallin ulkopuolella.
• Ei automaattista luottamusta työkalukuvauksiin.
• Työkalujen seuranta, jotka muuttavat kuvauksiaan.
• Eristäminen työkalupalvelimen tunnusten ja agentin tunnusten välillä.
• Yhdyskäytävä, joka välittää jokaisen työkalukutsun.

Uhkakategoria kolme: Salaisuuksien vuotaminen

Mistä agentit löytävät salaisuuksia

Agentti voi löytää tunnuksia seuraavista paikoista:

• Ympäristömuuttujat.
• Komentorivihistoria.
• Suojatun komentorivin konfiguraatio.
• Pilven komentorivin konfiguraatio.
• Git-tunnistetiedostot.
• Pakettienhallinnan konfiguraatio.
• Paikallisen agentin konfiguraatio.
• Prosessiargumentit.
• Prosessimuisti.
• Rakennuslokit.
• Testipuitteet.
• Tietokantayhteysmerkkijonot.
• Liitetyt isäntähakemistot.
• Pull-pyynnön tuloste.
• Välimuistissa olevat riippuvuudet.

GitHubin arkkitehtuuridokumentaatio varoittaa, että kehotteen injektoitu agentti, jolla on komentorivipääsy, voi tarkastaa konfiguraatiotiedostoja, suojatun komentorivin avaimia, prosessin tilaa ja työnkulun lokeja. Se voi sitten lähettää salaisuuksia verkon yli tai koodata ne julkisiin arkistoobjekteihin, kuten issueihin, pull-pyyntöihin ja kommentteihin. (github.blog)

Nx Consolen jälkimies osoitti liittyvän toimitusketjuongelman: haittaohjelma osallistujan koneella haki GitHubin komentorivitokenin paikallisesti saatavilla olevasta tunnistetiedostosta ja käytti sitä sekunneissa. (nx.dev)

Vuotokanavat

Turvallisen käyttöönoton on oletettava, että hyökkääjät käyttävät enemmän kuin suoria verkkopyyntöjä. Mahdollisia kanavia ovat:

• HTTP- ja suojatut HTTP-pyynnöt.
• Verkkotunnusjärjestelmän haut.
• Pakettirekisteripyynnöt.
• Git push -toiminnot.
• Pull-pyynnön kommentit.
• Issue-otsikot ja kuvaukset.
• Commit-viestit.
• Etäskeeman viittaukset.
• Kuva- tai tiedostolataukset.
• Hakukyselyt.
• Työkalun argumentit.
• Virheviestit.
• Ajoitus- ja volyymikuviot.
• Luotettu kolmannen osapuolen palvelu, jota käytetään välittäjänä.

IDEsaster-tutkimus kuvasi tietovuotopolun, jossa kehitysympäristö pyysi automaattisesti etä-JSON-skeemaa, joka sisälsi arkaluonteisia tietoja URL-parametrissa. Pyyntö saattoi tapahtua silloinkin, kun ihminen tarkasti diffiä. (maccarita.com)

Vahvin salaisuuksien hallinta

Vahvin sääntö on:

Älä anna agentille pääsyä sellaiseen salaisuuteen, jota se ei tarvitse.

GitHubin agenttipohjaisen työnkulun arkkitehtuuri sijoittaa mallin todennustokenit ja Model Context Protocol -tunnukset erillisiin luotettuihin proxy-kontteihin agentin kontin sijaan. Agentti kommunikoi välittäjän kautta, ei lukemalla tunnuksia suoraan. (github.blog)

Hyvä salaisuuksien suunnittelu käyttää:

• Lyhytikäisiä tunnuksia.
• Arkistokohtaista ja tehtäväkohtaista laajuutta.
• Työkalukohtaisia oikeuksia.
• Juuri-ajoissa tapahtuvaa myöntämistä.
• Automaattista peruutusta istunnon jälkeen.
• Ei tunnuksia ympäristömuuttujissa, jos mahdollista.
• Ei tunnuksia pysyvässä muistissa.
• Ei tunnuksia lokeissa.
• Ei pääsyä isäntäkäyttäjän tunnistetietohakemistoon.
• Riippumatonta seurantaa jokaiselle tunnistetietojen käytölle.

Salaisuuksien poistaminen on edelleen hyödyllistä, mutta se on varajärjestely. Poistaminen voi jäädä huomaamatta koodatuista, muunnetuista, jaetuista, pakatuista tai epäsuorasti siirretyistä salaisuuksista.

Uhkakategoria neljä: Tietojen ja muistin myrkytys

Arkiston ja riippuvuuksien myrkytys

Tietojen myrkytystä tapahtuu, kun hyökkääjä muuttaa tietoja, joita agentti käyttää päättelyyn.

Esimerkkejä ovat:

• Readme-tiedosto, joka käskee agenttia poistamaan käytöstä tietoturvatarkastukset.
• Testipuitteet, jotka sisältävät vääriä operatiivisia vaatimuksia.
• Riippuvuuden kuvaus, joka suosittelee haitallista asennuskomentoa.
• Konfiguraatiotiedosto, joka muuttaa hiljaisesti työkalun oikeuksia.
• Generaatioitu virheilmoitus, joka käskee agenttia lataamaan lokit.
• Myrkytetty välimuisti, joka sisältää muokattuja riippuvuuksia.
• Pull-pyynnön kommentti, joka muuttaa näennäistä tehtävää.

Agentti voi käsitellä kaikki nämä osana samaa keskustelukontekstia, vaikka niillä on eri tasoista auktoriteettia.

Pysyvän muistin myrkytys

Muistin myrkytys on vakavampaa, koska haitallinen ohje voi selviytyä alkuperäisestä istunnosta.

Cisco kuvasi Claude Code -muistin myrkytysskenaarion, jossa normaali kehittäjän työnkulku aiheutti haitallisen tai epävarman ohjeistuksen tallentamisen ja toimittamisen myöhemmissä istunnoissa. (blogs.cisco.com) OWASP kuvaa muistin ja kontekstin myrkytystä erillisenä agentin tietoturvariskinä, koska pysyvä tila voi vaikuttaa tulevaan käyttäytymiseen kauan sen jälkeen, kun alkuperäinen hyökkääjän hallitsema syöte on kadonnut. (genai.owasp.org)

Muistia tulisi siksi käsitellä kuin konfiguraatiotietokantaa, ei kuin vaarattomia muistiinpanoja.

Tarvittavat valvontatoimet sisältävät:

• Erota luotettu käytäntö opitusta muistista.
• Vaadi katselmointi ennen pysyviä kirjoituksia.
• Kirjaa jokaisen muistikohteen lähde.
• Määritä muistoille vanhenemispäivät.
• Estä salaisuuksien pääsy muistiin.
• Tue palautusta tunnettuun hyvään muistitilaan.
• Skannaa muistia ohjetyyppisen sisällön varalta.
• Testaa käyttäytymistä muistin ollessa pois päältä.
• Ylläpidä erillistä muistia jokaiselle arkistolle, käyttäjälle ja ympäristölle.
• Älä anna epäluotettavan arkiston sisällön kirjoittaa globaalia muistia.

Uhkakategoria viisi: Toimitusketjun riski

Autonomiset koodausagentit laajentavat ohjelmistojen toimitusketjun riskiä viiteen suuntaan.

Paketit ja asennusskriptit

Agentti voi asentaa haitallisen riippuvuuden luettuaan myrkytetyn ohjeen. Paketin elinkaariskriptit voivat suorittaa välittömästi ja käyttää paikallisia tunnuksia.

Vuoden 2025 Nx-kompromissi osoitti, miten varastettu julkaisutoken mahdollisti haitallisten pakettien skannaavan käyttäjän järjestelmiä, olevan vuorovaikutuksessa paikallisten tekoälytyökalujen kanssa ja lataavan kerättyjä tietoja julkisiin arkistoihin. Nx raportoi, että haitalliset paketit olivat saatavilla noin neljä tuntia. (nx.dev)

Taidot ja agenttilaajennukset

Agenttien taidot sisältävät usein ohjeita, skriptejä, työkalumääritelmiä ja käyttövaatimuksia. Snykin vuoden 2026 auditointi 3 984 taidosta kahdessa julkisessa taitoekosysteemissä raportoi merkittäviä määriä epävarmaa ja haitallista sisältöä. Nämä luvut ovat skannaustuloksia, eivät vahvistettuja tietomurtoja, mutta ne osoittavat, että agenttien taitomarkkinapaikkoja tulisi käsitellä epäluotettavina ohjelmistorekistereina, ei sovelluskauppoina. (snyk.io)

Kehitysympäristön laajennukset

Laajennukset voivat käyttää lähdekoodia, tiedostoja, terminaaleja, tunnuksia ja verkkopalveluita. Haitallinen tai vaarantunut laajennus voi hyökätä kehittäjää suoraan tai muuttaa agentin käyttäytymistä.

Rakennusvälimuistit

Rakennusvälimuistit voivat ylittää luottamusrajat. Alhaisen oikeuden työnkulku voi kirjoittaa välimuisti-artefaktin, jonka korkeamman oikeuden julkaisutyönkulku myöhemmin kuluttaa. Tämä luo polun issuekäsittelystä tunnusten varastamiseen, vaikka alkuperäisellä työnkululla ei olisi suoraa pääsyä julkaisusalaisuuksiin.

Mallit, kehotteet ja työkalumääritykset

Mallipäivitys tai kehotteen muutos voi muuttaa tapaa, jolla agentti tulkitsee ohjeita. Työkalupäivitys voi tuoda uuden oletusoikeuden tai muuttaa tapaa, jolla komentoja jäsennetään.

Jokaisen tuotantoagentin käyttöönoton tulisi versioida ja hyväksyä:

• Mallin tunniste.
• Järjestelmäohjeet.
• Kehittäjän ohjeet.
• Työkalumääritykset.
• Käytäntösäännöt.
• Konttikuvake.
• Riippuvuuden lukitustiedosto.
• Verkkokäytäntö.
• Salaisuuden konfiguraatio.
• Muistiskeema.
• Arviointisarja.

Merkittäviä tapauksia ja paljastuksia vuosilta 2025 ja 2026

Seuraava luettelo erottaa operatiiviset tapaukset, tietoturvatiedotteet ja valvotut tutkimuspaljastukset.

Replit-tapausta kuvailtiin julkisesti käyttäjäraporttien ja johdon vastauksen kautta tavanomaisen tietoturvatiedotteen sijaan. Replit korosti sen jälkeen kehityksen ja tuotannon erottelua, tilannekuvia, palautuksia ja agentin pääsyn rajoituksia tuotantotietokantoihin. (fastcompany.com)

Cline-tapaus on erityisen tärkeä, koska se osoittaa koostumista tämän uhkamallin jokaisen pääkategorian poikki: kehotteen injektointi, työkalun suoritus, välimuistin myrkytys, salaisuuksien varastaminen, toimitusketjun vaarantuminen ja automaattinen asennus alavirran kehittäjän järjestelmiin. Clinen tiedote vahvistaa luvattoman paketin julkaisun, kun taas tutkijan aikajana kuvaa edeltävän agentin työnkulun ja välimuistihyökkäysketjun. (github.com)

Tärkeimpien valvontamallien arviointi

Ei yksittäinen valvontatoimi riitä. Parhaat käyttöönotot yhdistävät useita riippumattomia kerroksia.

Suorituskyvyn hiekkalaatikot

Hiekkalaatikot ovat arvokkaimpia valvontatoimia, koska ne vähentävät räjähdysaluetta silloinkin, kun agentti käyttäytyy haitallisesti. Anthropic kuvaa prosessihiekkalaatikoita, virtuaalikoneita, tiedostojärjestelmän rajoja ja poistuvan liikenteen valvontaa ensisijaisena tapana hallita autonomista käyttäytymistä. (anthropic.com)

Hiekkalaatikoita on kuitenkin käsiteltävä ohjelmistoturvarajoina. Codex-haavoittuvuus osoitti, että virhe polun konfiguraatiologiikassa saattoi heikentää aiottua työtilan rajaa. (github.com)

Vahvan hiekkalaatikon tulisi sisältää:

• Kertakäyttöinen virtuaalikone tai kovetettu kontti.
• Ei pääsyä kehittäjän kotihakemistoon.
• Ei pääsyä suojatun komentorivin avaimiin tai pilven komentorivin tunnuksiin.
• Oma työtila, joka on liitetty tunnettuun polkuun.
• Vain luku -käyttöoikeus peruskuvaan.
• Ei etuoikeutettua konttitilaa.
• Rajoitettu prosessin luominen.
• CPU-, muisti-, levy- ja suoritusajan kiintiöt.
• Ei pääsyä tuotantoverkkoihin.
• Automaattinen tuhoaminen tehtävän jälkeen.
• Tilannekuva tai artefakti lopullisesta työtilasta katselmoitavaksi.

Käytäntömoottorit

Käytäntömoottorin tulisi sijaita mallin ja työkalun välissä. Sen ei tulisi luottaa mallin itsesääntelyyn.

Sen sijaan, että agentin annetaan antaa mielivaltaisia komentorivikomentoja, esitä tyypitetyt toiminnot, kuten:

• Lue tiedosto työtilan sisällä.
• Kirjoita tiedosto työtilan sisällä.
• Suorita hyväksytty testikomento.
• Asenna riippuvuus hyväksytystä rekisteristä.
• Luo haara.
• Avaa pull-pyyntö.
• Pyydä käyttöönoton hyväksyntää.

Käytäntömoottorin tulisi itsenäisesti validoida:

• Käyttäjän identiteetti.
• Arkisto.
• Kohdepolku.
• Komento tai työkalu.
• Datan luokittelu.
• Kohde.
• Odotettu sivuvaikutus.
• Hyväksyntätila.
• Istunnon jäljellä oleva budjetti.

Toistettavissa oleva työkalun suoritus

Toistettavuutta käsitellään usein rakennuksen laatuominaisuutena, mutta se on myös turvallisuuskontrolli.

Jokaisesta agentin ajosta tallenna:

• Tarkka malliversio.
• Tarkka agenttiversio.
• Tarkat työkalun versiot.
• Konttikuvakkeen hash.
• Riippuvuuden lukitustiedosto.
• Arkiston commit.
• Verkkokäytäntö.
• Käytäntöversio.
• Työkalukutsujen sarja.
• Tuloksena olevien artefaktien hashit.

NISTin Secure Software Development Framework korostaa turvallisia kehitysympäristöjä ja ohjelmistokomponenttien alkuperätietojen keräämistä. (csrc.nist.gov)

Älä käytä muuttuvia arvoja, kuten:

• Uusin pakettiversio.
• Kiinnittämättömät konttitunnisteet.
• Katselmoimattomat etäskriptit.
• Kelluvat työkalumääritykset.
• Vahvistamattomat haarojen nimet.
• Jaetut välimuistit eri oikeustasojen yli.

Salaisuuksien peittäminen ja välittäminen

Salaisuuksien peittämisen tulisi toimia useissa kohdissa:

1. Ennen kuin sisältö pääsee mallin kontekstiin.
2. Ennen kuin työkalun argumentit lähetetään.
3. Ennen kuin työkalun tuloste palautetaan.
4. Ennen kuin lokit tallennetaan.
5. Ennen kuin tiedostot commitoidaan.
6. Ennen kuin verkkopyynnöt lähtevät ajurista.
7. Ennen kuin kommentteja, issueita ja pull-pyyntöjä luodaan.

Erillinen salaisuuksien välittäjä on vahvempi kuin ympäristömuuttujat. Agentti pyytää välittäjää suorittamaan tarkasti määritellyn toimenpiteen, kuten yksityisen paketin lataamisen, saamatta raakatunnusta.

Poistuvan liikenteen suodatus

Verkkoyhteys tulisi evätä oletuksena.

Käytännöllisen poistuvan liikenteen välityspalvelimen tulisi tallentaa:

• Kohdealue ja -osoite.
• Pyyntömenetelmä.
• Pyyntömäärä.
• Vastausmäärä.
• Pyyntöidentiteetti.
• Pyyntöä aloittanut työkalu.
• Oliko arkaluonteisia tietoja läsnä.
• Oliko kohde hyväksytty.
• Tapahtuiko pyyntö hyväksyntäherkän toimenpiteen aikana.

GitHubin agenttipohjaisen työnkulun arkkitehtuuri käyttää erillistä palomuuria, luotettavaa Model Context Protocol -yhdyskäytävää ja eristettyä mallin todennusvälityspalvelinta. (github.blog)

Poistuvan liikenteen valvontatoimien on otettava huomioon myös epäsuorat kanavat. Pyyntö luotetulle lähdekoodin hallintapalvelulle voi silti luoda haitallisen issuen tai pull-pyynnön, joka sisältää varastettua dataa. Siksi verkon valvontatoimet on yhdistettävä turvallisiin tulostussääntöihin ja sisällön skannaukseen.

Suositeltu viitearkkitehtuuri

Turvallisen autonomisen koodauksen käyttöönoton tulisi sisältää nämä kerrokset:

1. Kontekstin syöttökerros

Tämä kerros kerää arkistotiedostoja, issueita, testituloksia ja työkalun tulosteita. Sen tulisi merkitä jokainen kohde seuraavasti:

• Lähde.
• Luottamustaso.
• Tekijä.
• Aikaleima.
• Arkisto.
• Datan luokittelu.
• Sisältääkö se suoritettavaa sisältöä.
• Sisältääkö se ohjeita.

2. Ohjeiden ja datan erottelu

Agentin tulisi saada nimenomainen lausunto siitä, että arkiston sisältö, työkalun tulosteet, verkkosivut ja issuen teksti ovat dataa, ellei niitä ole erikseen valtuutettu.

Järjestelmän tulisi säilyttää jokaisen kontekstin osan lähde sen sijaan, että kaikki litistetään yhdeksi erottelemattomaksi kehotteeksi.

3. Käytäntöjen täytäntöönpanopiste

Jokaisen työkalukutsun tulisi kulkea käytäntömoottorin läpi, joka tarkistaa:

• Identiteetti.
• Kyky.
• Kohde.
• Argumentit.
• Datan arkaluonteisuus.
• Verkon kohde.
• Hyväksyntävaatimukset.
• Resurssibudjetti.

4. Kyvykkyysvälittäjä

Agentti saa väliaikaisia kykyjä laaja-alaisten tunnusten sijaan. Välittäjän tulisi myöntää pienin tarvittava oikeus nykyiseen vaiheeseen ja peruuttaa se sen jälkeen.

5. Eristetty suoritusympäristö

Agentti toimii kertakäyttöisessä ympäristössä, jossa on:

• Ei tuotantoyhteyttä.
• Ei kehittäjän tunnistetietojen liitoksia.
• Ei pääsyä liittymättömiin arkistoihin.
• Rajoitettu tiedostojärjestelmän laajuus.
• Tiukat resurssirajat.
• Muuttumaton peruskuva.

6. Työkalun yhdyskäytävä

Ulkoisia työkaluja käytetään yhdyskäytävän kautta, joka suorittaa:

• Työkalun identiteetin vahvistus.
• Argumenttien validointi.
• Rajoitukset.
• Tulosteen suodatus.
• Oikeustarkistukset.
• Tarkastuslokitus.
• Tunnusten eristäminen.

7. Poistuvan liikenteen välityspalvelin

Kaikki ulkoinen viestintä kulkee hallitun välityspalvelimen kautta. Suora verkkoyhteys agentista tulisi estää.

8. Turvallisen tulosteen vaiheistus

Agentin tulisi tuottaa:

• Patch.
• Haara.
• Muutospyyntö.
• Käyttöönottoehdotus.
• Pakettiehdokas.

Sen ei tulisi suoraan yhdistää, ottaa käyttöön, julkaista tai muuttaa tuotannon tilaa.

9. Riippumaton katselmointi ja edistäminen

Erillinen prosessi katselmoi ehdotetun tulosteen käyttäen:

• Salaisuuksien skannaus.
• Staattinen tietoturva-analyysi.
• Riippuvuusanalyysi.
• Lisenssi- ja alkuperätarkastukset.
• Testitulokset.
• Käytäntöjen validointi.
• Ihmisen katselmointi suurivaikutuksisiin muutoksiin.

GitHubin pilviagentti noudattaa samanlaista mallia luomalla luonnos pull-pyyntöjä, rajoittamalla haaran pääsyä, vaatimalla ihmisen katselmointia, rajoittamalla työnkulun suoritusta ja tarjoamalla istuntologeja. (docs.github.com)

Toimivat lievennystarkistuslistat

Ennen agentin käyttöönottoa

• Luo agentille varastokirjaus.
• Tunnista agentin omistaja ja liiketoiminnan tarkoitus.
• Dokumentoi jokainen työkalu, liitin ja ulkoinen palvelu.
• Dokumentoi jokainen tunnus, jota agentti voi käyttää.
• Vahvista, että tuotannon tunnuksia ei ole läsnä.
• Suorita agentti kertakäyttöisessä ympäristössä.
• Poista automaattinen pakettiasennus käytöstä, ellei sitä ole nimenomaisesti hyväksytty.
• Poista rajoittamaton verkkoyhteys käytöstä.
• Kiinnitä malli, agentti, työkalut, riippuvuudet ja konttikuvake.
• Suojaa agentin ohjetiedostot ja konfiguraatiotiedostot koodin omistajuussäännöillä.
• Määritä, mitkä toiminnot vaativat ihmisen hyväksyntää.
• Määritä enimmäisistunnon kesto ja kustannukset.
• Luo palautussuunnitelma.

Ennen arkiston käyttöoikeuden sallimista

• Luokittele arkisto julkiseksi, sisäiseksi, luottamukselliseksi tai erittäin rajoitetuksi.
• Katselmoi kaikki arkiston hallitsema agentin konfiguraatio.
• Käsittele readme-tiedostoja, issuen sisältöä, kommentteja ja testitulostetta epäluotettavana.
• Poista koukkujen ja työtilan komentojen automaattinen suoritus käytöstä.
• Skannaa riippuvuudet ja asennusskriptit.
• Käytä puhdasta, eristettyä työtilaa.
• Estä pääsy liittymättömiin arkistoihin.
• Varmista, ettei työtilassa tai rakennuslokeissa ole salaisuuksia.
• Testaa haitallisella issuetekstillä ja myrkytetyllä dokumentaatiolla.
• Tallenna arkiston commit- ja agentin konfiguraatiohash.

Ennen työkalun käytön sallimista

• Korvaa mielivaltainen komentorivin käyttö tyypitetyillä toiminnoilla, jos mahdollista.
• Käytä sallittujen listaa työkaluille ja kohteille.
• Validoi polut kanonisoinnin jälkeen.
• Hylkää symbolisten linkkien ohitukset.
• Estä työkaluja muokkaamasta omia käytäntötiedostojaan.
• Estä agenttia muuttamasta omaa hyväksyntätilaansa.
• Vaadi vahvistus ennen verkkoyhteyttä, joka sisältää arkaluonteisia tietoja.
• Kirjaa jokainen työkalukutsu ja sen tulos.
• Aseta rajoituksia tiedostokoolle, komennon ajalle, verkon volyymille ja tokenien käytölle.
• Katselmoi Model Context Protocol -palvelimen kuvaukset ja oikeudet.
• Hylkää allekirjoittamattomat tai vahvistamattomat työkalumääritykset.

Ennen koodin julkaisun tai käyttöönoton sallimista

• Vaadi erillinen identiteetti agentille ja ihmisaloittajalle.
• Vaadi ihmisen katselmointi ennen yhdistämistä.
• Vaadi riippumaton hyväksyntä ennen käyttöönottoa.
• Käytä lyhytikäisiä julkaisutunnuksia.
• Käytä luotettua julkaisua tai työkuorman identiteettiä pitkäikäisten tokenien sijaan.
• Vaadi artefaktien allekirjoituksia ja alkuperätodistusta.
• Skannaa salaisuuksien ja haitallisten riippuvuuksien varalta.
• Rakenna puhtaasta ympäristöstä ilman jaettuja muuttuvia välimuisteja.
• Varmista, että artefakti vastaa katselmoitua lähdekoodia.
• Ylläpidä nopea pakettien tai laajennusten palautusprosessi.
• Testaa varmuuskopioiden ja tilannekuvien palautus.

Incident-vastausten aikana

• Päätä kyseinen agentin istunto.
• Eristä ajuri tai työasema.
• Peruuta kaikki agentin käytettävissä olevat tunnukset.
• Peruuta työkalujen ja liittimien käytettävissä olevat tunnukset.
• Säilytä istunnon, työkalun, verkon ja lähdekoodin hallinnan lokit.
• Tarkasta commitit, issue-t, pull-pyynnöt, kommentit ja pakettien julkaisut.
• Tarkasta välimuistit ja asennusskriptit.
• Vertaa julkaistuja artefakteja luotettuun lähdekoodiin.
• Etsi luvattomia ulkoisia kohteita.
• Katselmoi pysyvä muisti ja konfiguraatiotiedostot.
• Ilmoita arkiston, pakettirekisterin ja työkalujen toimittajille.
• Kierrätä tunnukset uudelleen oikeuslääketieteellisen analyysin jälkeen, jos ne ovat saattaneet paljastua.
• Kirjaa, lähtikö dataa hyväksytystä ympäristöstä.

Ehdotetut tietoturvapalvelutasosopimukset

Nämä ovat ehdotettuja käyttöönoton tavoitteita, eivät yleisiä toimialan standardeja. Organisaatioiden tulisi mukauttaa ne riskinsietokykyynsä.

Erittäin arkaluonteisissa ympäristöissä tärkein palvelutasosopimus tulisi olla nolla onnistunutta kriittisen polun vuotoa keskimääräisen havaitsemisasteen sijaan. Yksi onnistunut julkaisutokenin varastaminen voi olla tuhoisampaa kuin tuhannet vaarattomat estetyt yritykset.

Tarkastusartefaktit, jotka jokaisen käyttöönoton tulisi tuottaa

Kypsän käyttöönoton tulisi pystyä vastaamaan jälkikäteen:

• Kuka käynnisti agentin?
• Mitkä käyttäjä- ja palveluidentiteetit olivat mukana?
• Mitä arkistoa ja commitia käytettiin?
• Mikä malli- ja agenttiversio ajettiin?
• Mitkä ohjeet olivat aktiivisia?
• Mitä ulkoista sisältöä tuli kontekstiin?
• Mitkä työkalut olivat käytettävissä?
• Mitä työkaluja todella kutsuttiin?
• Mitä argumentteja lähetettiin?
• Mitä tiedostoja luettiin tai muutettiin?
• Mihin verkon kohteisiin otettiin yhteyttä?
• Mitä tunnuksia pyydettiin?
• Mitkä käytännöt sallivat tai estivät kunkin toimenpiteen?
• Mitkä ihmisen hyväksynnät saatiin?
• Mikä artefakti tuotettiin?
• Mikä artefakti julkaistiin?
• Mikä oli lopullinen päätös?

Ylläpidä vähintään nämä artefaktit:

1. Agentin inventaariotietue
2. Uhkamalli ja tiedonkulun kaavio
3. Kyvykkyys- ja oikeusmanifesti
4. Työkalujen ja liittimien inventaario
5. Mallin, kehotteen ja käytännön version tietue
6. Konttikuvake ja riippuvuuksien materiaalikuvaukset
7. Verkkokäytäntö ja poistuvan liikenteen loki
8. Salaisuuksien paljastumisen ja poiston raportti
9. Istunnon ja työkalukutsujen jäljitys
10. Ihmisen hyväksynnän tietue
11. Turvallisuusarviointi ja punaisen tiimin raportti
12. Julkaisun alkuperä ja artefaktin allekirjoitus
13. Muistin alkuperä- ja palautustietue
14. Incident-vastaus- ja palautustesti
15. Myyjän tietoturvatiedote ja patch-tietue

Lokien tulisi olla peukaloimattomia, pääsyvalvottuja ja säilytettävä tietojen arkaluonteisuuden mukaan. Tavalliset kehitysistunnot voivat vaatia yhdeksänkymmenen päivän säilytysajan, kun taas istunnot, jotka käyttävät julkaisujärjestelmiä, säänneltyä dataa tai arvokkaita arkistoja, voivat vaatia yhden vuoden tai pidemmän säilytysajan.

OpenAI kuvaa sisäistä seurantaa, joka tarkistaa koodausagenttien vuorovaikutuksia, työkalukutsuja ja potentiaalisesti epäilyttävää käyttäytymistä, kun taas GitHub korostaa istuntologeja, allekirjoitettuja committeja, attribuutiota ja tarkastusrekistereitä. Nämä mallit tukevat laajempaa periaatetta: agentin käyttäytymisen on oltava havaittavissa riippumattomasti agentin omasta selityksestä siitä, mitä se teki. (openai.com)

Ensimmäinen käytännön askel

Paras ensimmäinen askel ei ole ottaa agenttia käyttöön tuotantoarkistossa.

Sen sijaan:

1. Luo kertakäyttöinen testivarasto.
2. Anna agentille vain luku -tehtävä.
3. Suorita se uudessa hiekkalaatikossa.
4. Katkaise pääsy kehittäjän tunnuksiin.
5. Estä kaikki verkkoliikenne mallintarjoajaa lukuun ottamatta.
6. Lisää tarkoituksellisesti haitallinen issue, readme-ohje, työkalun kuvaus ja konfiguraatiotiedosto.
7. Tallenna jokainen yritetty tiedoston käyttö, työkalukutsu, komento ja verkkopyyntö.
8. Käytä tuloksia luodaksesi ensimmäisen oikeusmanifestisi ja tietoturvapalvelutasosopimuksesi.

Jos agentti ei voi turvallisesti suorittaa vain luku -tehtävää näissä olosuhteissa, se ei ole valmis kirjoitusoikeuteen, julkaisun automaatioon tai tuotantojärjestelmiin.

Johtopäätös

Autonomiset koodausagentit tulisi turvata epäluotettavina, identiteettiä kantavina automaatiojärjestelminä, ei tavallisina kehittäjän työkaluina.

Ratkaiseva turvallisuuskysymys ei ole:

”Noudattaako malli oikeita ohjeita?”

Se on:

”Mitä tapahtuu, jos malli noudattaa vääriä ohjeita, samalla kun sillä on todellisia oikeuksia?”

Kehotteen injektointi, työkalujen hyväksikäyttö, salaisuuksien varastaminen, tietojen myrkytys ja toimitusketjun vaarantuminen ovat eri sisäänpääsykohtia samaan taustalla olevaan virheeseen: agentin annetaan ylittää liian monia luottamusrajoja ilman riippumatonta valvontaa.

Vuosien 2025 ja 2026 tapaukset osoittavat, että tehokkaimmat valvontatoimet ovat arkkitehtonisia:

• Pidä agentit poissa salaisuuksista.
• Käytä kertakäyttöisiä kyvykkyyshiekkalaatikoita.
• Pane käytännöt täytäntöön mallin ulkopuolella.
• Erota kehitys tuotannosta.
• Käsittele konfiguraatiota ja muistia suoritettavina hyökkäyspintoina.
• Käytä hallittua poistuvaa liikennettä.
• Poista jaetut välimuistit etuoikeutetuista julkaisutyönkuluista.
• Kiinnitä ja vahvista jokainen työkalu ja artefakti.
• Vaiheista kaikki kirjoitukset.
• Vaadi riippumaton hyväksyntä peruuttamattomiin toimiin.
• Säilytä yksityiskohtaiset, peukaloimattomat tarkastusrekisterit.

Autonomia voi olla hyödyllistä ja turvallista, mutta vain silloin, kun järjestelmä on suunniteltu siten, että sekaantuneella, manipuloidulla tai vaarantuneella agentilla on rajallinen valta, rajallinen ulottuvuus, rajallinen aika ja selkeästi palautettavissa oleva virhetila.