Sean Blanchfield, Jenticin perustaja ja toimitusjohtaja – Haastattelusarja

Sean Blanchfield, Jenticin perustaja ja toimitusjohtaja, on sarjayrittäjä, jolla on vuosikymmenten kokemus suurten ohjelmistojen ja infrastruktuurien kehittämisestä. Dublinissa toimiva Blanchfield johtaa Jenticiä ja toimii myös Irlannin tekoälyneuvostossa, jossa hän neuvoo hallitusta tekoälypolitiikassa. Uran alkuvaiheessa hän perusti DemonWare-nimisen yhtiön, joka kehitti suurten videopelijulkaisijoiden verkkopalveluita ja myytiin myöhemmin Activision Blizzardille (ATVI ) . Hän perusti myös PageFair-nimisen startupin, joka kehitti mainonnan estoanalytiikkaa ja myytiin Blockthroughille. Hän on perustanut tai johtanut useita muita startup-yhtiöitä ja tukee edelleen Irlannin startup-ekosysteemiä aloilla kuten Techpreneurs.

Jentic kehittää yleistä integraatiokerrosta, joka auttaa tekoälyjärjestelmiä turvallisesti vuorovaikuttamaan yritysten järjestelmien ja rajapintojen kanssa. Alusta mahdollistaa yritysten yhdistää tekoälymallit sisäisiin työkaluihin, ulkoisiin palveluihin ja toimintaprosesseihin säilyttäen hallinnan, todennuksen ja valvonnan. Muuttamalla sirpaleiset rajapinnat järjestelmien luotettavasti käytettäviksi rajapinnoiksi Jentic pyrkii auttamaan yrityksiä käyttämään tekoälyyn perustuvaa automaatiota laajasti monimutkaisissa ohjelmistoympäristöissä.

Olet perustanut ja johtanut useita teknologiayhtiöitä, kuten DemonWare (joka myytiin Activision Blizzardille) ja PageFair, ja nyt Jentic. Lisäksi olet jäsenenä Irlannin tekoälyneuvostossa. Mikä sai sinut palaamaan infrastruktuurin kehittämiseen Jenticin kanssa, ja mikä aukko näit tekoälyjärjestelmien ekosysteemissä, jota muut eivät huomioineet?

Kolmannella kerralla kun huomaat mallin, sinun on otettava se tosissaan. DemonWarella kaikki puhuvat verkkomonoista, mutta vaikea ongelma on verkkoinfrastruktuuri alla. Sama tapahtuu tekoälyjärjestelmien kanssa. Mallit ovat hämmästyttäviä. Pulma on integraatiokerros – aina on ollut. Tekoälyjärjestelmät toimivat rajapinnoilla, ja nämä rajapinnat on rakennettu ihmisille: dokumentoitu ihmisille, turvattu ihmisille ja rakennettu ihmisille. Osoita tekoälyjärjestelmä tähän infrastruktuuriin, ja se hajoaa nopeasti. Yritysten tekoälypilotit eivät epäonnistu, koska malli ei ymmärtänyt tehtävää; ne epäonnistuvat, koska järjestelmä ei voinut luotettavasti yhdistää järjestelmiin, joita se tarvitsi. Generatiivinen tekoäly tarjoaa uuden tavan ratkaista tämä ongelma – kohdella integraatiota tietona, ei koodaamisongelmana. Tämä oivallus veti minut mukaan.

Kun aloitit Jenticin vuonna 2024, oli agenttien turvallisuus ensisijainen teesi alusta alkaen, vai tarkentuiko fokus, kun havainnoit, miten yritykset olivat todella käyttämässä autonomisia agentteja tuotannossa?

Ensimmäinen lanka, jota vedin, oli tunnistautuminen. Olin kuvitellut agenttien lisääntyvän, kullekin tarvitsi tunnistautumistietoja kymmenille järjestelmille, ja kaikki nämä salaisuudet virtaavat LLM:n kontekstiuuniin, josta ne voidaan varastaa – kuuma sotku. Vastaus on sama kuin olisi ollut kaksikymmentä vuotta sitten: keskitetyn todennuksen ja valvonnan. Mutta kun vedin tätä lankaa, se johti suoraan seuraavaan ongelmaan: jos keskitetään perinteisillä integraatiotyökaluilla, päädytään takaisin kiinteiden liitäntäjen maahan, ja agentit eivät ole staattisia. Se, mikä vakiinnutti vision, oli ymmärtäminen, että kykyjen löytäminen tulisi olla tiiviisti kytköksissä pääsyoikeuksiin – että agentti tulisi saada vain sellaiset kyvyt, joita se on valtuutettu käyttämään, ja että järjestelmä, joka tarjoaa löytämisen, voi myös olla yksittäinen pääsyrajoitus- ja valvontapiste.

Viimeaikaiset paljastukset suurista määristä internetiin näkyvistä agenttien esiintymistä ovat korostaneet, miten orkestraatio ja tunnistautuminen usein jakavat saman luottamuksen rajan. Miten arvioit arkkitehtonisen virheen tässä mallissa?

Virhe on yksinkertainen: agentti – järjestelmä, joka suorittaa LLM:n ohjeita – on myös järjestelmä, joka pitää tunnistautumistietoja ja tekee API-kutsuja. Jos agentti menee väärään käsiin, se saa kaiken, minkä se voi koskaan tehdä. Se on sama virhe, jonka teimme varhaisessa web-ajan – sovelluspalvelimet, joilla on superkäyttäjän tasoisia tietokantaoikeuksia, koska se oli kätevää. Jentic toimii kerroksena agentin ja sen kutsuessa olevien API-rajapintojen välissä. Agentti ei koskaan pidä tunnistautumistietoja. Se lähettää pyynnöt hallitun suorituskerroksen kautta, joka lisää tunnistautumistiedot palvelimella, pakottaa käytännön ja kirjaa jokaisen kutsun. Ja kun jotain menee pieleen, on yksi yksinkertainen sammutuspainike – yksi toiminto lopettaa agentin pääsyn kaikkiin yhdistetyihin järjestelmiin samanaikaisesti.

Olet puhunut orkestraation ja suorituksen erottamisesta räjähdysalueen rajoittamiseksi. Voitko selittää käytännöllisissä termeissä, miten tämä erottelu muuttaa riskiprofiilia, kun esiintymä menee väärään käsiin?

Tasaisessa mallissa LLM päättelee, mitä tehdä, ja kutsuu suoraan API:ja käyttäen tunnistautumistietoja, joita se pitää. Jos LLM menee väärään käsiin, se ohjaa suorituskerrosta. Erottamalla ne, LLM lähettää aikeen – “kutsu Stripe-billing-API:lle näillä parametreilla” – hallittu suorituskerros tarkistaa pyynnön käytäntöä vasten, lisää tunnistautumistiedot palvelimella ja tekee kutsun. LLM ei koskaa koske tunnistautumistietoihin. Käytännössä: sivusuuntaisen liikkumisen saa paljon vaikeammaksi, räjähdysalue on rajattu siihen, mitä suorituskerros sallii kyseiselle agentin identiteetille, ja saat sammutuspainikkeen. Yksi vipu ja agentin pääsy loppuu kaikissa yhdistetyissä järjestelmissä. Agentti voidaan edelleen manipuloida – mutta manipulointi ei enää automaattisesti tarkoita täydellistä tunnistautumistietojen kompromissia.

Miten keskitetty tunnistautumisjohto ja välitön peruutus näyttäytyy käytännössä yritysten todellisissa käyttökohteissa, ja miten se eroaa siitä, miten useimmat tiimit käsittelevät tällä hetkellä API-avaimia ja -tokenia agentteja varten?

Tällä hetkellä useimmat tiimit ovat kehittäneet API-avaimia, tallentaneet ne .env-tiedostoon ja lataaneet ne agentin käynnistyksessä – usein suoraan LLM:n kontekstiuuniin. Kukaan ei ole täydellistä kuvaa siitä, mitkä agentit pitävät mitäkin tunnistautumistietoja. Kun joku lähtee, avaimet, joita he olivat määritelleet, eivät vaihdu. Kun agentti käyttäytyy epäilyttävästi, ei ole audit-reittiä, jota voisi jäljittää, mitä tapahtui. Jenticillä kehittäjä ei koskaan käsittele raakaa tunnistautumistietoja. He ilmoittavat, mitä pääsyä agentti tarvitsee, alusta määrittää rajatun pääsyn, ja agentti kutsuu suorituskerroksen kautta ilman, että se näkee koskaan perustiedon avainta. Se tarkoittaa, että saat välittömän agentikohtaisen peruutuksen, mahdollisuuden keskeyttää pääsy, kun tutkit, ja aikaleimatun audit-reitin jokaisesta API-kutsusta. Ero tämän ja “API-avain .env-tiedostossa” on merkittävä.

Monet tiimit kokeilevat agenttikehyksiä myynti-, insinööri- ja data-analytiikkaosastoissa. Mitkä ovat yleisimmät turvallisuusvirheet, joita näet, kun organisaatiot siirtyvät kokeilusta tuotantoon?

Samaa mallia toistuu: yliedustetut agentit, jotka edelleen toimivat hallinnon tunnistautumistiedoilla, joita ne oli prototyyppiinä; tunnistautumistiedot, jotka annetaan ohjeissa tai kontekstiuunissa, jonne ne päätyvät lokitiedostoihin, telemetriaan ja mahdollisesti koulutusdataan; jaettu tunnistautuminen useiden agenttien esiintymien välillä, jolloin et voi erottaa yksittäistä pahaa toimijaa; ei sammutuspainiketta, jolla voisi lopettaa agentin ilman, että koko järjestelmä menee alas; ei arvokasta audit-reittiä; ja ohjeiden injektio, jota ei oteta tosissaan – vaikka mikä tahansa agentti, joka lukee sähköposteja, prosessoi asiakirjoja tai selaa internetiä, kohtaa vihamielisesti luotuja sisältöjä. Yhteinen säie on, että nämä tiimit rakensivat onnellisen polun ja ovat nyt löytämässä, että tuotanto on pääasiassa epäonnellinen polku.

Jentic asettaa itsensä hallitun suorituskerroksen agenttikehyksiä ja ulkoisia järjestelmiä erottavana kerroksena. Miten tämä välittävä kerros pakottaa hallintoa hidastamatta kehittäjiä tai vähentämättä agenttien joustavuutta?

Sen sijaan, että agentti yhdistettäisiin viiteenkymmenen eri API:hin, kullekin omalla todennusjärjestelmällään, rajoituksilla ja ominaisuuksilla, kehittäjä yhdistää yhteen päätepisteeseen. Tämä päätepiste tarjoaa työkaluja etsiä koko API-kykyjen luetteloa, ladata tietoja ja suorittaa mitä tahansa kutsua. Tämä maksimoi joustavuuden yhden yhdistetyn rajapinnan kautta, joka antaa pääsyn rajattomaan määrään API:hin, mahdollistaen hallinnon – järjestelmien pääsyä, ehtoja, rajoituksia – kaikki hallitaan alustassa, ei asiakasohjelmassa. Suorituskerros on läpiajova; agentit voivat edelleen koostaa monivaiheisia työprosesseja, ketjuttaa kutsuja ja käsitellä virheitä dynaamisesti. Hallinto ilman kitkaa on vaikeaa. Pikaniska on siirtää taakka kehittäjille. Infrastruktuuri tulisi tehdä vastakkaisesti – se tulisi omaksua monimutkaisuuden, jotta kehittäjien ei tarvitse.

Näetkö hyökkääjien siirtävän fokuksensa kohti tekoälyinfrastruktuuria uutena arvokkaana hyökkäyspintana, kun tietovarkausmallit kohdistavat nyt aktiivisesti agenttien konfiguraatiotiedostoihin ja tallennettuihin tunnistautumistietoihin?

Ehdottomasti – ja logiikka on ilmeinen. Agenttien konfiguraatiotiedosto on käytännössä monipalvelun superavain: tunnistautumistiedot sähköpostijärjestelmille, CRM-järjestelmille, laskutuspalveluille, sisäisille API:ille ja GitHub-tilille. Yksi onnistunut tietovarkausoperaatio antaa kuukausien ajan pääsyn koko yrityksen ulkoisiin järjestelmiin. Se on dramaattisesti suurempi tuotto kuin kohdistaa yksittäistä palvelua erikseen. Toinen ulottuvuus on, että agentit, jotka toimivat jatkuvasti tuotannossa, ovat pysyviä, todennettuja läsnäoloja – eivät käyttäjiä, jotka kirjautuvat sisään ja ulos. Kompromissi agentti voi toimia pitkäaikaisena jalansijana, toimien havaitsemisen kynnyksen alapuolella. Epämukava totuus on, että hyökkäyspinta on kehittymässä nopeammin kuin puolustusvälineet. Jentic voi vähentää merkittävästi tunnistautumistietojen hyökkäyspintaa, mutta emme voi estää agenttia väärinkäyttämästä niitä oikeuksia, joita sille on annettu. Se vaikeampi ongelma on ratkaistava mallitasolla, varusteilla ja ohjeiden injektion havaitsemisella.

Mikä on laajempia turvallisuusperiaatteita, joita organisaatioiden tulisi omaksua, jos ne haluavat käyttää agenteja turvallisesti laajassa mittakaavassa?

Useimmat hallinnoitavat organisaatiot eivät voi käyttää epädeterministisiä järjestelmiä arvokkaimpiin liiketoimintaprosesseihin. Pankki tai vakuutusyhtiö ei voi osoittaa autonomista agenttia laskutusjärjestelmäänsä ja sanoa “selvitä itse”. Miten innovoida ilman, että riskiasenne muuttuu jarruksi? Vastaus on simulaatio. Luo digitaalinen klooni API-omaisuudestasi, samalla rakenteella ja prosesseilla, mutta ilman tuotannon tunnistautumistietoja tai seuraamuksia. Käytä agentteja siellä, anna niiden tutkia, katso, mitä tapahtuu. Onnistuneet polut voidaan kaapata strukturoituna, deterministisenä työprosessiautomaationa, joka on auditoitu, toistettavissa ja katseltavissa millä tahansa yhdenmukaisuustiimillä – käyttäen Arazzo-avointa työprosessimäärittelyä, joka on kehitetty OpenAPI-alustalla. Tämä tarkoittaa, että voit liikkua tekoälyn nopeudella simulaatiossa ja yrityksen nopeudella tuotannossa, ja nämä kaksi tilaa coexist. Muut periaatteet edelleen pätevät – vähimmäisoikeudet, audit-reitit, sammutuspainikkeet, orkestraation ja suorituksen erottaminen. Mutta simulaatio on rakenteellinen vastaus siihen, mihin yritysten tiimit usein jäävät kiinni: miten kokeilla epädeterminististä tekoälyä ilman, että uhraa yhdenmukaisuusasennetta? Et käytä epädeterminismiä. Sinä haet arvoa siitä kontrolloiduissa olosuhteissa ja käytät ainoastaan deterministisiä tulosteita.

Kiitos haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla Jentic-sivustolla.