AI-agentin tietoturva alkaa yhdestä säännöstä: AI-agenttisi ei saa koskaan säilyttää tunnuksiasi. Tässä on 38 vuotta vanha välittäjäkuvio, joka varmistaa tämän.
AI-agentit ovat hämmentyneitä sijaisia. Se on 38 vuotta vanha tietoturvakuviotermi, ja vastaus on yhtä vanha: aseta välittäjä — luotettu, havaittava, deterministinen, auditoitava, väärentämätön, rajatun laajuinen, politiikkavetoinen, ei-AI-välikerros — agentin ja sen tarvitsemien SaaS-rajapintojen väliin, säilyttämään tunnukset, joita agentin ei pitäisi saada.
Vuonna 1988 Norm Hardy julkaisi lyhyen artikkelin, jossa hän kuvasi tositapauksen ajaltaan Tymsharessa. Fortran-kääntäjä nimeltä FORT sijaitsi järjestelmäkansiossa SYSX. Käyttötilastojen keräämiseksi kääntäjän piti kirjoittaa tiedostoon (SYSX)STAT, joten käyttöjärjestelmä oli myöntänyt FORTille "kotitiedostolisenssin", joka oikeutti kirjoittamaan mihin tahansa SYSX:n tiedostoon. Myös järjestelmän laskutustiedosto, (SYSX)BILL, sijaitsi siellä. Käyttäjä, joka käynnisti kääntäjän, saattoi antaa tiedostonimen saadakseen valinnaista debug-tulostetta. Eräänä päivänä käyttäjä antoi tiedostonimen (SYSX)BILL. Kääntäjä pyysi käyttöjärjestelmää avaamaan tiedoston kirjoitusta varten; käyttöjärjestelmä, huomioiden kotitiedostolisenssin, salli sen. Laskutustiedot ylikirjoitettiin. Kääntäjä toimi täsmälleen suunnitellusti. Virhe oli arkkitehtuurissa.
Hardy nimesi tämän hämmentyneen sijaisen ongelmaksi: etuoikeutettu ohjelma (sijainen) omaa omat valtuutensa; vähemmän etuoikeutettu kutsuja pyytää sitä tekemään jotain; sijainen hämmentyy siitä, kenen valtuuksilla se toimii, ja käyttää omiaan. Korjaus on ottaa valtuudet kokonaan pois sijaiselta ja asettaa ne erillisen kerroksen taakse, joka välittää pyynnön tarpeen mukaan. Tämä kerros on välittäjä.
Kolmekymmentäkahdeksan vuotta myöhemmin jokainen yrityksesi ajama AI-agentti on hämmentynyt sijainen. Ja useimmat niistä toimivat ilman välittäjää.
Miksi AI-agentit pahentavat tietoturvaongelmaa
Hardyn FORTilla oli yksi syötekanava: komentorivi. Modernilla AI-agentilla niitä on kymmeniä: sähköpostien sisällöt, haetut verkkosivut, ladatut PDF:t, MCP-palvelimien työkalutulosteet, viestit muiden agenttien järjestelmässä. Kaikki, mikä päätyy konteksti-ikkunaan, voi antaa ohjeita, ja agentti käsittelee niitä kaikkia lähtökohtaisesti luotettavina.
Tämä rikkoo oletuksen, johon perinteinen pääsynhallinta perustuu: kutsuja hallitsee syötteen. Verkkosovelluksessa kutsuja (todennettu istunto) ja syöte (HTTP-pyynnön runko) tulevat samasta paikasta. Agentilla kutsuja on kuka tahansa, joka muotoilee kehotteen, eli hyökkääjä, joka voi kirjoittaa sähköpostin tai vaikuttaa hakutulokseen, on myös kutsuja.
Marraskuussa 2025 PromptArmorin tietoturvatutkijat osoittivat, miltä tämä näyttää tuotannossa. He piilottivat haitallisia ohjeita 1 pikselin fontilla integraatio-ohjeeseen. Kun kehittäjä ohjasi Googlen Antigravity IDE:n siihen, agentti ohitti oman .gitignore-pohjaisen tiedostosuojausmekanismin suorittamalla komentoja cat:n kautta. Sitten se vuoti .env-tiedostojen sisällön hyökkääjän hallinnoimaan webhook.site-osoitteeseen Antigravityn oman selainagentin kautta. Käyttäjä oli tehnyt kaiken oikein. Hiekkalaatikko piti. Agentti ei vain kyennyt erottamaan käyttäjän pyyntöä syötteen ohjeista.
Sama muoto kuin Hardyn FORTilla vuosikymmeniä myöhemmin: laajat valtuudet, epäluotettava syöte, ei tapaa erottaa niitä toisistaan.
Yhteisöllä on vastauksia. Ne ovat vain hajallaan.
Tämä ei ole uusi ongelma. Tietoturvayhteisö on kirjoittanut vastauksia vuosikymmeniä:
Kyvykkyyspohjainen tietoturva (Dennis & Van Horn, 1966; myöhemmin E-kieli ja Mark Millerin Caja-työ Googlessa). Periaate: älä myönnä yleisvaltuuksia identiteetin tai sijainnin perusteella; välitä eksplisiittisiä, väärentämättömiä kyvykkyyksiä jokaiseen resurssiin, johon ohjelmalla on lupa. Kyvykkyys yhdistää mitä voit tehdä ja mille voit tehdä, eikä sitä voi sekoittaa mihinkään muuhun.
Välitetyt tunnukset (määritelty OWASP LLM Top 10). Älä laita API-tunnuksia LLM:n kontekstiin. Luotettu välikerros tekee kutsun agentin puolesta; malli päättää mitä tehdään, välittäjä hoitaa miten. Kehotepistoksen, joka pyytää mallia tulostamaan tunnuksensa, tulos on hyödytön. Tunnuksia ei ole siellä.
Phantom Token Pattern (Curity, alun perin OAuthille mikropalveluissa). Agentilla on läpinäkymätön istuntotunniste, ei oikeaa bearer-tunnusta. Välityspalvelin validoi tunnisteen, vaihtaa oikean tunnuksen verkon reunalla ja välittää eteenpäin. Jos agentti vuotaa ympäristönsä, hyökkääjä saa merkkijonon, joka vanhenee istunnon päättyessä.
Kertakäyttöiset tunnukset juuri oikeaan aikaan (työkuorman identiteettijärjestelmät kuten Aembit). Luo lyhytikäinen, rajatun laajuinen tunnus jokaista kutsua varten sen sijaan, että jaetaan pitkäikäisiä tunnuksia.
Mikään tästä ei puutu kirjallisuudesta. Se puuttuu oletuksista. Useimmat agenttialustat antavat edelleen mallille OAuth-tunnuksen ilman välittäjää ja toivovat parasta.
Näin Zeron välittäjä toimii
Emme keksineet yllä olevia kuvioita. Rakensimme ne yhteen välittäjään, joka toimii oletuksena jokaiselle agentille Zerossa. Se on luotettu välikerros, jonka nämä kuviot kuvaavat, rakennettu AI-agenttialustalle. Jokainen agentin tekemä liitännäiskutsu kulkee sen kautta. Jokainen liitännäinen on yksi ulkoinen SaaS (Slack, GitHub, Notion jne.).
Välittäjä on jokaisen agentin ja liitännäisen välissä. Oikeat tunnukset ovat vain välittäjän puolella katkoviivaa.
Ajattele sitä kolmena kerroksena.
1. Tunnusten eristys
Agentin hiekkalaatikko ei koskaan säilytä oikeaa liitännäistunnusta. Kun yhdistät SaaS-palvelun Zeroon, OAuth-tunnus tai API-avain tallennetaan välittäjän puolelle. Hiekkalaatikko saa paikkamerkkijonon, joka näyttää tarpeeksi ympäristösalaisuudelta, jotta olemassa olevat työkalut toimivat, mutta mikään ulkoinen SaaS ei hyväksy sitä.
Kun agentti tekee pyynnön rekisteröityyn liitännäisisäntään, välittäjä tunnistaa pyynnön, ratkaisee liitännäisen todennuspohjan ja lisää oikean tunnuksen verkon reunalla. Pyyntö lähtee eteenpäin oikeilla tunnuksilla; agentilla ei koskaan ollut mitään hyödyllistä. Kehotepistoksen saanut agentti, joka tulostaa ympäristömuuttujansa, antaa hyökkääjälle paikkamerkin, ei SaaS-tunnusta.
Tämä on phantom token -kuvio sovellettuna AI-agentteihin.
2. Liitännäisen politiikkaportti
Liitännäinen Zerossa on enemmän kuin päälle/pois-kytkin. Jokainen liitännäinen kuvaa kattamansa API-pohjat ja miten todennus lisätään. Jos ulkoinen palvelu julkaisee vakaan laajuus–päätepiste-kartoituksen, se voi myös kuvata, mikä nimetty lupa kattaa minkäkin metodin ja polun. Slackin slack-api-ref on hyvä esimerkki.
Kun Slackiin yhdistetty agentti kutsuu chat.postMessage, välittäjä voi kartoittaa pyynnön chat:write:een. Kun se lukee audit-lokeja, kyseessä on admin.analytics:read. Jokaiselle agentille permission_policies määrittelee, miten nämä nimetyt luvat toimivat: salli, estä tai kysy. Politiikkaa valvotaan välittäjällä ennen tunnuksen lisäämistä, ei vihjeenä mallille. Jos agentti yrittää tehdä pyynnön, jonka lupa on estetty, esimerkiksi kehotepistoksen vuoksi, pyyntö ei koskaan pääse verkkoon asti.
Kaikki liitännäiset eivät vielä saa tätä tarkkuutta. Kaikki ulkoiset rajapinnat eivät julkaise vakaata laajuus–päätepiste-karttaa. GitHubin GraphQL-rajapinta on tästä esimerkki: REST-puoli voidaan kartoittaa, mutta GraphQL-puolta ei vielä. Näissä tapauksissa välittäjä silti hallitsee tunnusten lisäämistä ja verkkoreittiä, mutta lupaportti perustuu karkeampaan liitännäis- tai isäntätason politiikkaan, jonka alusta pystyy toteuttamaan. Täydennämme näitä sitä mukaa kuin ulkoista dataa saadaan. Emme väitä kattavuutta, jota emme ole rakentaneet.
Tunnukset eivät kanna yleisvaltuuksia. Valtuudet välitetään agenttikohtaisesti, sillä tarkkuudella, jonka ulkoinen palvelu mahdollistaa. Tämä on kyvykkyyspohjaisen mallin toinen puoli.
3. Operatiivinen silmukka ja auditointi
Vähimmän oikeuden periaate toimii vain, jos vikatilanne on käytettävä. Agentit kehittyvät. Kuuden viikon päästä tutkimusagentti, joka aluksi vain luki Notionista, saattaa tarvita oikeuden kirjoittaa yhteenvedon takaisin. Yleiset vikatilanteet muualla: agentti toimii hiljaisesti ilman uutta lupaa ja hajoaa, tai ylläpitäjä myöntää paniikissa liikaa oikeuksia eikä koskaan peru niitä.
Estetty liitännäispyyntö palauttaa rakenteisen 403: liitännäinen, metodi, polku, perus-URL ja vastaavat lupanimet, kun välittäjä tunnistaa ne. Agentin järjestelmäkehotteessa kerrotaan, miten eston syy diagnosoidaan ja miten pyytää täsmälleen sitä lupaa, johon törmättiin, tuottaen käyttäjälle tai ylläpitäjälle yhden klikkauksen myöntölinkin. Näin eskalaatiopolku pysyy täsmällisessä luvassa eikä muutu "myönnä kaikki" -pyynnöksi.
Lupamuutospyynnöt jäävät jonoon. Omistajat ja ylläpitäjät voivat hyväksyä tai hylätä ne hallintapaneelista; hyväksytyt pyynnöt päivittävät agentin politiikan, ja seuraava yritys onnistuu. Useimmat alustat ohittavat tämän silmukan. Ilman sitä "vähimmän oikeuden periaate" jää kalvoille, ei tuotantoon.
Sama välittäjäpolku tuottaa auditoinnin. Suorituskohtaiset verkkolokit tallentavat hiekkalaatikon verkkoliikenteen HTTP-, TCP-, DNS- ja alemman tason pakettihavainnoilla ei-TCP-liikenteelle. Liitännäispyynnöt sisältävät rakenteista välittäjämetatietoa: liitännäinen, tunnistettu lupa, salli/estä-tulos, tunnuksen ratkaisun metatieto ja laskutettava lippu. Jos myöhemmin kysytään "mitä tämä agentti teki tiistaina klo 15?", vastaus rekonstruoidaan näistä tiedoista. Estot eivät tavoita kaikkea. Audit-jälki kertoo, mitä tapahtui.
Mitä emme ole ratkaisseet
Kaikesta edellä mainitusta huolimatta agentti, jolla on oikea chat:write, voidaan silti saada lähettämään nolo viesti kanavalle, johon sillä jo on pääsy. Välittäjä kaventaa vahinkoa, mutta ei poista sitä.
Toinen puoli ratkaisua on korkean riskin toimien hyväksyntä, tulosten validointi ja työkalujen palautusten käsittely oletusarvoisesti epäluotettavina. Tämä työ on tiekartalla, ei vielä tuotteessa. Kukaan, joka väittää ratkaisseensa hämmentyneen sijaisen ongelman päästä päähän, ei puhu totta.
Tämän pitäisi olla lähtötaso, ei ominaisuus
Kyvykkyyspohjainen tietoturva on ollut olemassa 1970-luvulta. Välitetyt tunnukset ovat OWASP LLM Top 10 -listalla. Phantom tokenit edeltävät LLM-aikaa. Mikään tästä ei puutu siksi, ettei vastausta tiedetty. Se puuttuu, koska varhaiset agenttialustat optimoivat "demon toimimaan" ja siirsivät tietoturvan myöhemmäksi, joka usein ei koskaan toteutunut.
Seuraavan sukupolven alustojen tulisi tähdätä korkeammalle. Tunnukset eivät saa päätyä mallin kontekstiin. Valtuudet tulee eritellä agenttikohtaisesti. Oikeuksien laajennus tulee kulkea ihmisen kautta. Jokaisen toiminnon tulee olla auditoitavissa päästä päähän. Mikään tästä ei ole uutta. Kaiken tämän tulisi olla perustaso.
Kun valitset agenttialustaa, "onko se turvallinen?" ei vie pitkälle. Jokainen toimittaja sanoo kyllä. Parempi kysymys: näytä välittäjäsi ja kerro, mitä tapahtuu, kun agentti pyytää laajuutta, jota sillä ei ole.
Välittäjä on oletuksena jokaisen agentin edessä Zerossa. Liitännäisluettelo, laajuuskartat, lupapolitiikat ja välittäjälogiikka löytyvät kaikki Zeron lähdekoodista. Puuttuuko liitännäinen? Tee ilmoitus.
Lähteet
Perustavaa
- Norm Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review 22(4), 1988. DOI 10.1145/54289.871709
- Dennis & Van Horn, Programming Semantics for Multiprogrammed Computations, CACM 1966 (kyvykkyysjärjestelmien perustava artikkeli)
- Mark Miller et al., Caja: kyvykkyyspohjainen tietoturva webille, Google
- OWASP LLM Top 10
- Curity, Phantom Token Pattern
Mainitut tosielämän tapaukset
- PromptArmor, Google Antigravity Exfiltrates Data, marraskuu 2025
- Simon Willison, kattavuus ja analyysi, 25. marraskuuta 2025
