Sean Blanchfield, medstifter og administrerende direktør i Jentic – Interviewserie

Sean Blanchfield, medstifter og administrerende direktør i Jentic, er en seriøs teknologi-entrepreneur med årtiers erfaring i opbygning af storstilede software- og infrastruktur-virksomheder. Med base i Dublin leder han i øjeblikket Jentic, samtidig med at han også fungerer som medlem af Irlands AI-råd, hvor han rådgiver regeringen om kunstig intelligens-politik. Tidligere i sin karriere var han medstifter af DemonWare, en storstilede online-tjeneste-platform for store videospil-udgivere, der senere blev opkøbt af Activision Blizzard (ATVI ) , og PageFair, en venture-backet startup, der fokuserede på ad-blocking-analytik og blev opkøbt af Blockthrough. Han har også stiftet eller ledet flere startups og fortsætter med at støtte Irlands startup-økosystem gennem initiativer som Techpreneurs.

Jentic udvikler en universel integrationslag, der er designet til at hjælpe AI-agenter med at interagere sikkert med virksomheds-systemer og API’er. Platformen giver organisationer mulighed for at tilslutte AI-modeller til interne værktøjer, eksterne tjenester og operationelle arbejdsgange, samtidig med at de opretholder governance, autentificering og tilsyn. Ved at omdanne fragmenterede API’er til strukturerede grænseflader, som AI-agenter kan bruge pålideligt, sigter Jentic på at hjælpe virksomheder med at implementere AI-drevet automatisering i stor skala på komplekse software-miljøer.

Du har stiftet og ledet flere teknologi-virksomheder, fra DemonWare (opkøbt af Activision Blizzard) til PageFair og nu Jentic, og du fungerer også som medlem af Irlands AI-råd. Hvad fik dig til at vende tilbage til opbygning af infrastruktur-lag med Jentic, og hvilken åbning så du i den opblomstrende AI-agent-økosystem, som andre overså?

Når du ser en mønster for tredje gang, må du tage det alvorligt. Hos DemonWare talte alle om online-multiplayer – men det hårde problem var netværks-infrastrukturen under det hele. Det samme sker med AI-agenter. Modellerne er bemærkelsesværdige. Flaskehalsen er integrations-laget – altid har været. AI-agenter kører på API’er, og disse API’er blev bygget til mennesker: dokumenteret til mennesker, sikret til mennesker og struktureret til mennesker. Peger en autonom agent på denne infrastruktur, og den falder sammen hurtigt. Enterprise AI-piloter mislykkes ikke, fordi modellen misforstod opgaven; de mislykkes, fordi agenten ikke kunne tilslutte sig systemerne, den havde brug for, pålideligt. Generativ AI tilbyder en ny måde at løse dette problem på – ved at behandle integration som et viden-problem, ikke et kodnings-problem. Den indsigt fik mig til at interessere mig.

Da du startede Jentic i 2024, var agent-sikkerhed den primære tes fra dag én, eller skærpede fokus, da du observerede, hvordan organisationer faktisk implementerede autonome agenter i produktion?

Det første tråd, jeg trak, var legitimationsoplysninger. Jeg forestillede mig agenter, der blev mere og mere udbredte, hver med legitimationsoplysninger til dusinvis af systemer, alle disse hemmeligheder strømmende ind i LLM-kontekst-vinduer, blev eksfiltreret – en varm rod. Svaret er det samme, som det ville have været for tyve år siden: centralisere autentificering og autorisation. Men at trække denne tråd førte direkte til det næste problem: hvis du centraliserer ved hjælp af traditionel integration-værktøj, er du tilbage i landet med statiske connectores, og agenter er ikke statiske. Det, der cementerede visionen, var at forstå, at evne-opsøgning burde være tæt sammenkoblet med adgangskontrol – at en agent kun burde blive tilbudt en evne, hvis den faktisk er autoriseret til at bruge den, og at systemet, der tilbyder opsøgning, også kan være det enkelte punkt for gennemtvingelse og overvågning.

Den seneste afsløring af et stort antal internet-tilgængelige agent-forekomster har fremhævet, hvordan orkestrering og legitimationsoplysninger ofte deler den samme tillidsgrænse. Fra din synsvinkel, hvad er den grundlæggende arkitektoniske fejl i denne model?

Fejlen er enkel: agenten – et system, der kører prompter fra en LLM – er også systemet, der holder legitimationsoplysningerne og foretager API-opkaldene. Hvis agenten bliver kompromitteret, får man adgang til alt, det kan gøre. Det er den samme fejl, vi gjorde i den tidlige web-æra – applikationsservere med superbruger-adgang til databasen, fordi det var bekvemt. Jentic sidder som et lag mellem agenten og API’erne, den kalder. Agenten holder aldrig legitimationsoplysninger. Den udsteder anmodninger gennem vores administreret eksekveringslag, som indsætter legitimationsoplysninger server-side, gennemtvinger politik og logger hvert opkald. Og hvis noget går galt, er der en enkelt “dræb-kontakt” – én handling stopper agentens adgang til alle tilsluttede systemer samtidig.

Du har talt om at adskille orkestrering fra eksekvering for at indeholde skade-radius. Kan du forklare, hvordan denne adskillelse ændrer risiko-profilen, når en forekomst bliver kompromitteret?

I den flade model taler LLM om, hvad der skal gøres, og kalder direkte API’er ved hjælp af de legitimationsoplysninger, den holder. Hvis LLM bliver kompromitteret, kontrollerer man eksekverings-laget. Med adskillelse udsender LLM en intention – “kal Stripe-betaling-API med disse parametre” – et administreret eksekveringslag validerer anmodningen mod politik, indsætter legitimationsoplysningerne server-side og foretager opkaldet. LLM rører aldrig ved legitimationsoplysningerne. I praksis: lateral bevægelse bliver meget sværere, skade-radius er begrænset af, hvad eksekverings-laget tillader for denne specifikke agent-identitet, og man får en “dræb-kontakt”. Én toggle, og agentens adgang stopper over alle tilsluttede systemer. Agenten kan stadig manipuleres – men manipulation betyder ikke automatisk fuld legitimationsoplysning-kompromittering.

I virkelige enterprise-implementationer, hvordan ser centraliseret legitimationsoplysning-styring og instant-tilbagekald ud, og hvordan adskiller det sig fra, hvordan de fleste hold håndterer API-nøgler og -token for agenter?

I dag har de fleste hold en udvikler, der klargør API-nøgler, gemmer dem i en .env-fil og indlæser dem ved agent-start – ofte direkte ind i LLM’ens kontekst-vindue. Ingen har en komplet oversigt over, hvilke agenter holder hvilke legitimationsoplysninger. Når en agent opfører sig underligt, er der ingen revisions-spor til at genskabe, hvad der skete. Med Jentic håndterer udvikleren aldrig rå legitimationsoplysninger. De erklærer, hvilken adgang en agent har brug for, platformen klargør omfattende adgang, og agenten kalder gennem vores eksekveringslag uden at se den underliggende nøgle. Det betyder, at man får instant per-agent-tilbagekald, mulighed for at pause adgang, mens man undersøger, og en tidsstempel-mærket revisions-spor over hvert API-opkald. Forskellen mellem det og “API-nøgle i en .env-fil” er betydelig.

Mange hold eksperimenterer med agent-rammer på tværs af salg, ingeniørvidenskab og datavidenskab. Hvad er de mest almindelige sikkerheds-fejl, du ser, når organisationer flytter fra eksperimenter til produktion?

De samme mønstre gentager sig: over-privilegerede agenter, der stadig kører på de administrator-legitimationsoplysninger, de blev prototype med; legitimationsoplysninger, der overføres i prompter eller kontekst-vinduer, hvor de ender i logfiler, telemetri og potentielt træningsdata; fælles legitimationsoplysninger på tværs af multiple agent-forekomster, så man ikke kan isolere en enkelt dårlig aktør; ingen “dræb-kontakt” for at stoppe en agent uden at tage hele systemet ned; ingen revisions-spor værd at tale om; og prompt-injektion ikke taget alvorligt – selvom enhver agent, der læser e-mails, behandler dokumenter eller surfer på internettet, vil møde modstandskraftigt konstrueret indhold. Den fælles tråd er, at disse hold byggede til den lykkelige vej og opdager nu, at produktion er mest de ulykkelige veje.

Jentic positionerer sig som et administreret eksekveringslag mellem agent-rammer og eksterne systemer. Hvordan sikrer dette mellem-lag governance uden at bremse udviklere eller reducere agent-fleksibilitet?

I stedet for at tilslutte en agent til femti forskellige API’er – hver med sin egen autentificerings-skema, rate-grænser og særheder – tilslutter udvikleren sig til ét endpoint. Det endpoint udstiller værktøjer til at søge vores hele katalog over API-kapaciteter, indlæse detaljer og udføre ethvert opkald. Dette maksimerer fleksibilitet gennem en enkelt samlet grænseflade til ubegrænsede API’er, samtidig med at det muliggør governance – hvilke agenter har adgang til hvilke API’er, under hvilke betingelser, med hvilke begrænsninger – alt administreret i platformen, ikke i klient-kode. Eksekverings-laget er en igennemgang; agenter kan stadig komponere multi-trins-arbejdsgange, kæde opkald og håndtere fejl dynamisk. Governance uden gnidning er svært. Genvejen er at overføre byrden til udviklerne. Infrastruktur skal gøre det modsatte – absorbere denne kompleksitet, så udviklerne ikke behøver at.

Med infostealer-malware, der nu aktivt målretter agent-konfigurations-filer og gemte legitimationsoplysninger, ser du angribere skifte fokus mod AI-infrastruktur som en ny høj-værdi-overflade?

Absolut – og logikken er åbenlys. En agent-konfigurationsfil er effektivt en multi-service-super-nøgle: legitimationsoplysninger til e-mail-systemer, CRM-systemer, fakturerings-platforme, interne API’er og GitHub-konti. En enkelt succesfuld infostealer-kørsel giver måneder med adgang til hele virksomhedens eksterne systemer. Det er en dramatisk højere afkast end at målrette et enkelt tjeneste i isolation. Den anden dimension er, at agenter, der kører kontinuerligt i produktion, er varige, legitimerede tilstedeværelser – ikke en bruger, der logger ind og ud. En kompromitteret agent kan fungere som en langvarig fodhold, der opererer under detektions-grænserne. Den ubehagelige virkelighed er, at angrebs-overfladen udvikler sig hurtigere end defensiv-værktøjer. Jentic kan betydeligt reducere legitimationsoplysning-angrebs-overfladen, men vi kan ikke forhindre, at en agent misbruger de omfang, den er blevet tildelt. Det sværere problem skal løses på model-niveau med guardrails og prompt-injektions-detektion.

Uden for enhver enkelt ramme, hvilke bredere sikkerheds-principper bør organisationer adoptere, hvis de ønsker at implementere agentic AI sikkert i stor skala?

De fleste managed organisationer kan ikke implementere ikke-deterministiske systemer i deres mest værdifulde forretnings-processer. En bank eller forsikringsselskab kan ikke pege en autonom agent mod deres fakturerings-system og sige “gå og figurér det ud.” Så hvordan innovere uden, at risiko-posturen bliver en håndbremse? Svaret er sandkasse. Oprettelse af en digital tvilling af API-estaten med samme struktur og arbejdsgange, men uden produktions-legitimationsoplysninger eller konsekvenser. Implementer agenter der, lad dem udforske, observer, hvad der sker. De succesfulde stier fås fanget som strukturerede, deterministiske workflow-automatiseringer ved hjælp af Arazzo, den åbne workflow-specifikation udviklet inden for OpenAPI-initiativet – gennemgangs-bar, gentagelig og gennemgangs-bar af enhver compliance-hold. Dette betyder, at man kan bevæge sig med AI-hastighed i sandkassen og med virksomheds-hastighed i produktion, og at disse to tilstande sameksisterer. De andre principper gælder stadig – mindst-privilegie, revisions-spor, “dræb-kontakt” og adskillelse af orkestrering fra eksekvering. Men sandkassen er det strukturelle svar på det spørgsmål, virksomheds-hold faktisk bliver fast på: hvordan eksperimenterer man med ikke-deterministisk AI uden at satse sin compliance-postur på det? Man implementerer ikke ikke-determinismen. Man udvinder værdi fra den under kontrollerede betingelser og implementerer kun de deterministiske output.

Tak for det store interview. Læsere, der ønsker at lære mere, kan besøge Jentic.