Sean Blanchfield, medgrunnlegger og CEO av Jentic – Intervju-serie

Sean Blanchfield, medgrunnlegger og CEO av Jentic, er en seriell teknologi-entrepreneur med tiårs erfaring med å bygge store skala programvare- og infrastruktur-selskaper. Basert i Dublin, leder han for tiden Jentic, samt også tjener på Irlands AI-rådgivende råd, hvor han rådgir regjeringen om kunstig intelligens-politikk. Tidligere i sin karriere var han medgrunnlegger av DemonWare, et høyskala online-tjeneste-plattform for store videospill-utgivere som senere ble kjøpt av Activision Blizzard (ATVI ), og PageFair, et venture-backed startup fokusert på ad-blocking-analyser som ble kjøpt av Blockthrough. Han har også grunnlagt eller ledet flere startup-selskaper og fortsetter å støtte Irlands startup-økosystem gjennom initiativer som Techpreneurs.

Jentic utvikler en universell integrasjonslag som skal hjelpe kunstig intelligens-agenter å samhandle med bedriftssystemer og API-er på en sikker måte. Plattformen muliggjør at organisasjoner kan koble kunstig intelligens-modeller med interne verktøy, eksterne tjenester og operative arbeidsflyter samtidig som de opprettholder styring, autentisering og tilsyn. Ved å omforme fragmenterte API-er til strukturerte grensesnitt som kunstig intelligens-agenter kan bruke på en pålitelig måte, har Jentic som mål å hjelpe bedrifter å distribuere kunstig intelligens-drevet automatisering i stor skala over komplekse programvare-miljøer.

Du har grunnlagt og ledet flere teknologiselskaper, fra DemonWare (kjøpt av Activision Blizzard) til PageFair og nå Jentic, og du tjener også på Irlands AI-rådgivende råd. Hva var det som dro deg tilbake til å bygge på infrastruktur-laget igjen med Jentic, og hva var det som du så som et hull i den fremvoksende kunstig intelligens-agens-økosystemet som andre gikk glipp av?

Når du for tredje gang legger merke til et mønster, må du ta det alvorlig. Hos DemonWare snakket alle om online multiplayer – men det harde problemet var nettverks-infrastrukturen under det. Det samme skjer med kunstig intelligens-agenter. Modellene er bemerkelsesverdige. Flaskehalsen er integrasjons-laget – alltid har vært. Kunstig intelligens-agenter kjører på API-er, og disse API-ene ble bygget for mennesker: dokumentert for mennesker, sikret for mennesker og strukturert for mennesker. Peke en autonom agent mot denne infrastrukturen, og den faller fra hverandre raskt. Enterprise AI-piloter mislykkes ikke fordi modellen misforstod oppgaven; de mislykkes fordi agenten ikke kunne kobles til systemene det trengte på en pålitelig måte. Generativ kunstig intelligens tilbyr en ny måte å løse dette på – ved å behandle integrasjon som et kunnskapsproblem, ikke et kodeproblem. Denne innsikten trakk meg inn.

Når du startet Jentic i 2024, var agent-sikkerhet den primære tesen fra dag én, eller skjerpet fokus når du observerte hvordan organisasjoner faktisk distribuerte autonome agenter i produksjon?

Det første tråden jeg trakk, var legitimasjon. Jeg forestilte meg agenter som proliferte, hver behøvde legitimasjon for dusinvis av systemer, alle disse hemmelighetene strømmet inn i LLM-kontekst-vinduer, ble eksfiltrert – en varm rot. Svaret er det samme som det ville ha vært for tyve år siden: sentralisere autentisering og autorisasjon. Men å trekke denne tråden, ledet rett til neste problem: hvis du sentraliserer ved hjelp av tradisjonell integrasjons-verktøy, er du tilbake i landet med statiske koblinger, og agenter er ikke statiske. Det som cementerte visjonen, var å innse at evne-oppdagelse bør være tett koblet til tilgangskontroll – at en agent bare bør bli tilbudt en evne hvis den faktisk er autorisert til å bruke den, og at systemet som tilbyr oppdagelse også kan være enkelt punkt for gjennomføring og overvåking.

Den nylige eksponeringen av store tall på internett-eksponerte agent-eksemplarer har høylysnet hvordan orkestrering og legitimasjon ofte deler samme tillits-grense. Fra din synsvinkel, hva er det grunnleggende arkitektoniske feilen i denne modellen?

Feilen er enkel: agenten – et system som kjører forespørsler fra en LLM – er også systemet som holder legitimasjonen og gjør API-forespørslene. Kompromitter agenten, og du får alt den noen gang kunne gjøre. Det er samme feilen vi gjorde i den tidlige web-æraen – applikasjonsservere med superbruker-database-tilgang fordi det var praktisk. Jentic sitter som et lag mellom agenten og API-ene den kontakter. Agenten holder aldri legitimasjon. Den utsteder forespørsler gjennom vår kontrollerte eksekveringslag, som injiserer legitimasjon på serversiden, gjennomfører policy og logger hver forespørsel. Og når noe går galt, er det en enkelt “drepe”-bryter – en handling som stopper agentens tilgang over hver koblet system samtidig.

Du har snakket om å skille orkestrering fra eksekvering for å begrense skade-radien. Kan du forklare på en praktisk måte hvordan denne skillelsen endrer risiko-profilen når en instans er kompromittert?

…

I den flate modellen, tenker LLM på hva den skal gjøre og kontakter API-er direkte ved hjelp av legitimasjonen den holder. Kompromitter resonnerings-laget, og du kontrollerer eksekverings-laget. Med skillelse, emitterer LLM en intensjon – “kontakt Stripe-betaling-API med disse parameterne” – et kontrollert eksekveringslag validerer forespørselen mot policy, injiserer legitimasjon på serversiden og gjør forespørselen. LLM berører aldri legitimasjonen. I praksis: lateral bevegelse blir mye harder, skade-radien er avgrenset av hva eksekverings-laget tillater for denne spesifikke agent-identiteten, og du får en “drepe”-bryter. En enkelt bryter og agentens tilgang stopper over hver koblet system. Agenten kan fremdeles manipuleres – men manipulering betyr ikke lenger automatisk full legitimasjons-kompromitt.

I virkelige bedrifts-distribusjoner, hva ser sentralisert legitimasjons-håndtering og øyeblikkelig tilbakekalling ut som, og hvordan forskjeller det fra hvordan de fleste team håndterer API-nøkler og -token for agenter?

I dag, har de fleste team en utvikler som provisionerer API-nøkler, lagrer dem i en .env-fil og laster dem ved agent-start – ofte direkte inn i LLMs kontekst-vindu. Ingen har en fullt ut bilde av hvilke agenter holder hvilke legitimasjoner. Når noen forlater, blir nøklene de provisionerte ikke rotert. Når en agent oppfører seg underlig, er det ingen audit-spor å rekonstruere hva som skjedde. Med Jentic, håndterer utvikleren aldri rå legitimasjoner. De erklærer hva tilgang en agent trenger, plattformen provisionerer omfattende tilgang, og agenten kontakter gjennom vår eksekveringslag uten å noen gang se den underliggende nøkkelen. Det betyr at du får øyeblikkelig per-agent-tilbakekalling, evnen til å pause tilgang mens du undersøker, og en tidstemplet audit-spor av hver API-forespørsel. Forskjellen mellom det og “API-nøkkel i en .env-fil” er betydelig.

Mange team eksperimenterer med agent-rammeverk over salg, ingeniørarbeid og data-vitenskap. Hva er de vanligste sikkerhets-feilene du ser når organisasjoner flytter fra eksperimentering til produksjon?

De samme mønsterne gjentar seg: overprivilegerte agenter som fremdeles kjører på admin-legitimasjoner de ble prototypet med; legitimasjoner overført i forespørsler eller kontekst-vinduer hvor de ender opp i logger, telemetri og potensielt treningsdata; delt legitimasjon over flere agent-eksemplarer så du ikke kan isolere en enkelt dårlig aktør; ingen “drepe”-bryter for å stoppe en agent uten å ta ned det bredere systemet; ingen audit-spor verdt å nevne; og prompt-injeksjon ikke tatt alvorlig – selv om hver agent som leser e-post, prosesserer dokumenter eller surfer på nettet, vil møte motstrategisk konstruert innhold. Det felles tråden er at disse teamene bygget for den lykkelige vei og oppdager nå at produksjon mest består av de ulykkelige veier.

Jentic stiller seg som et kontrollert eksekveringslag som sitter mellom agent-rammeverk og eksterne systemer. Hvordan tvinger dette mellomlaget gjennom styring uten å sakke ned utviklere eller redusere agent-fleksibilitet?

I stedet for å koble en agent til femti forskjellige API-er – hver med sin egen autentiserings-skjema, hastighetsbegrensninger og egenheter – kobler utvikleren til ett endepunkt. Dette endepunktet eksponerer verktøy for å søke vår hele katalog av API-evner, laste detaljer og eksekvere hver forespørsel. Dette maksimerer fleksibilitet gjennom et enkelt forent grensesnitt til ubegrenset API-er, samtidig som det muliggjør styring – hvilke agenter aksesserer hvilke API-er, under hvilke betingelser, med hvilke begrensninger – alt håndtert i plattformen, ikke i klient-kode. Eksekverings-laget er et gjennomgangslag; agenter kan fremdeles komponere multi-trinn-arbeidsflyter, kjede forespørsler og håndtere feil dynamisk. Styring uten friksjon er vanskelig. Snarveien er å skyve byrden over på utviklere. Infrastruktur bør gjøre det motsatte — absorbere denne kompleksiteten så utviklere ikke må.

Med infostealer-malware som nå aktivt målretter agent-konfigurasjonsfiler og lagrede legitimasjoner, ser du angripere skifte fokus mot kunstig intelligens-infrastruktur som et nytt høyt-verdi-område?

Absolutt – og logikken er åpenbar. En agent-konfigurasjonsfil er effektivt en multi-tjeneste-super-nøkkel: legitimasjoner for e-post-systemer, CRMs, fakturering-plattformer, interne API-er og GitHub-kontoer. En enkelt vellykket infostealer-kjørning gir måneder med tilgang over hele selskapets eksterne systemer. Det er et dramatisk høyere avkastning enn å målrette noen enkelt tjeneste i isolasjon. Den andre dimensjonen er at agenter som kjører kontinuerlig i produksjon er varige, legitimerte tilstedeværelser — ikke en bruker som logger inn og ut. En kompromittert agent kan tjene som en langvarig fotfeste, opererende under detekterings-terskler. Den ubehagelige virkeligheten er at angreps-overflaten utvikler seg raskere enn defensive verktøy. Jentic kan betydelig redusere legitimasjons-angreps-overflaten, men vi kan ikke forhindre at en agent misbruker de omfang den har fått. Det vanskeligere problemet må løses på modell-nivå, med guardrails og prompt-injeksjons-deteksjon.

Utenom noen enkelt rammeverk, hvilke bredere sikkerhets-prinsipper bør organisasjoner adoptere hvis de ønsker å distribuere agens-kunstig intelligens trygt i stor skala?

De fleste ledede organisasjoner kan ikke distribuere ikke-deterministiske systemer inn i deres mest verdifulle forretnings-prosesser. En bank eller forsikringsselskap kan ikke peke en autonom agent mot deres faktureringssystem og si “gå og finn ut”. Så hvordan kan du innovere uten at din risiko-holdning blir en håndbrekk? Svaret er sandkasse. Opprett en digital tvilling av din API-eiendom med samme struktur og arbeidsflyter, men uten produksjons-legitimasjoner eller konsekvenser. Distribuer agenter der, la dem utforske, se hva som skjer. De vellykkede stier fanges som strukturerte, deterministiske arbeidsflyt-automatiseringer som bruker Arazzo, den åpne arbeidsflyt-specifikasjonen utviklet innen OpenAPI-initiativet – auditable, gjentakbare og gjennomgåbare av enhver compliance-team. Dette betyr at du kan bevege deg i AI-hastighet i sandkassen og i bedrift-hastighet i produksjon, og at disse to modusene sameksisterer. De andre prinsippene gjelder fortsatt – minst privilegie, audit-spor, “drepe”-brytere, skillelse av orkestrering fra eksekvering. Men sandkassen er det strukturelle svaret på spørsmålet bedrifts-team faktisk blir fast i: hvordan kan vi eksperimentere med ikke-deterministisk kunstig intelligens uten å satse vår compliance-holdning på det? Du distribuerer ikke ikke-determinismen. Du trekker ut verdien fra den under kontrollerte forhold, og distribuerer bare de deterministiske utgangene.

Takk for det flotte intervjuet, lesere som ønsker å lære mer bør besøke Jentic.