Sean Blanchfield, medgrundare och VD för Jentic – Intervju-serien

Sean Blanchfield, medgrundare och VD för Jentic, är en serieentreprenör inom teknologi med decenniers erfarenhet av att bygga storskaliga programvaru- och infrastrukturföretag. Med bas i Dublin leder han för närvarande Jentic och sitter också i Irlands AI-råd, där han råder regeringen om artificiell intelligenspolicy. Tidigare i sin karriär co-founded han DemonWare, en högskalig online-tjänstplattform för stora videospelutgivare som senare förvärvades av Activision Blizzard (ATVI ) , och PageFair, ett venture-backat startup som fokuserade på ad-blockeringsanalys och som senare förvärvades av Blockthrough. Han har också grundat eller lett flera startups och fortsätter att stödja Irlands startup-ekosystem genom initiativ som Techpreneurs.

Jentic utvecklar en universell integreringslager som är utformad för att hjälpa AI-agenter att på ett säkert sätt interagera med företagssystem och API:er. Plattformen möjliggör för organisationer att ansluta AI-modeller till interna verktyg, externa tjänster och operativa arbetsflöden samtidigt som de upprätthåller styrning, autentisering och tillsyn. Genom att omvandla fragmenterade API:er till strukturerade gränssnitt som AI-agenter kan använda på ett tillförlitligt sätt, syftar Jentic till att hjälpa företag att distribuera AI-drivna automatiseringar i stor skala över komplexa programvarumiljöer.

Du har grundat och lett flera teknologiföretag, från DemonWare (förvärvat av Activision Blizzard) till PageFair och nu Jentic, och du sitter också i Irlands AI-råd. Vad drog dig tillbaka till att bygga på infrastrukturlagret igen med Jentic, och vilket gap såg du i den framväxande AI-agent-ekosystemet som andra missade?

När du för tredje gången märker ett mönster, måste du ta det på allvar. På DemonWare pratade alla om online-multiplayer – men det hårda problemet var nätverksinfrastrukturen under det. Samma sak händer med AI-agenter. Modellerna är remarkabla. Flaskhalsen är integreringslagret – alltid har varit. AI-agenter körs på API:er, och dessa API:er byggdes för människor: dokumenterade för människor, säkrade för människor och strukturerade för människor. Pekar du en autonom agent mot den infrastrukturen, så kollapsar den snabbt. Företags AI-piloter misslyckas inte för att modellen missförstod uppgiften; de misslyckas för att agenten inte kunde ansluta till systemen den behövde på ett tillförlitligt sätt. Generativ AI erbjuder ett nytt sätt att lösa detta – genom att behandla integration som ett kunskapsproblem, inte ett kodningsproblem. Den insikten drog mig in.

När du startade Jentic 2024, var agent-säkerhet den primära tesen från dag ett, eller skärptes fokus när du observerade hur organisationer faktiskt distribuerade autonoma agenter i produktion?

Det första tråden jag drog var autentiseringsuppgifter. Jag föreställde mig agenter som förökade sig, var och en behövde autentiseringsuppgifter för dussintals system, alla dessa hemligheter flödade in i LLM-sammanhangsfönster, blev exfiltrerade – en het röra. Svaret är detsamma som det skulle ha varit för tjugo år sedan: centralisera autentisering och auktorisering. Men att dra den tråden ledde rakt till nästa problem: om du centraliserar med hjälp av traditionell integreringsverktyg, så är du tillbaka i landet med statiska anslutningar, och agenter är inte statiska. Vad som cementerade visionen var att inse att kapacitetsupptäckt borde vara tätt kopplat till åtkomstkontroll – att en agent bara borde erbjudas en kapacitet om den faktiskt är auktoriserad att använda den, och att systemet som tillhandahåller upptäckt också kan vara den enda punkten för verkställighet och övervakning.

Den nyliga exponeringen av stora mängder internet-vända agent-instanser har belyst hur orkestrering och autentiseringsuppgifter ofta delar samma förtroendegräns. Vad är den grundläggande arkitektoniska felet i den modellen?

Felet är enkelt: agenten – ett system som kör kommandon från en LLM – är också systemet som innehåller autentiseringsuppgifterna och gör API-anropen. Kompromettera agenten och du får allt den någonsin kunde göra. Det är samma misstag vi gjorde i den tidiga webberan – applikationsservrar med superanvändaråtkomst till databasen eftersom det var bekvämt. Jentic sitter som ett lager mellan agenten och API:erna den anropar. Agenten innehåller aldrig autentiseringsuppgifter. Den utfärdar förfrågningar genom vår hanterade exekveringslager, som injicerar autentiseringsuppgifter på serversidan, verkställer policy och loggar varje anrop. Och när något går fel, finns det en enda avstängningsknapp – en åtgärd som stoppar agentens åtkomst till alla anslutna system samtidigt.

Du har talat om att separera orkestrering från exekvering för att innesluta skadeområdet. Kan du förklara på ett praktiskt sätt hur den separationen förändrar riskprofilen när en instans är komprometterad?

I den platta modellen resonerar LLM om vad man ska göra och anropar direkt API:er med de autentiseringsuppgifter den innehåller. Kompromettera resonemangs-lagret, och du kontrollerar exekveringslagret. Med separation, utger LLM en avsikt – “anropa Stripe-betalnings-API med dessa parametrar” – ett hanterat exekveringslager validerar den förfrågan mot policy, injicerar autentiseringsuppgifter på serversidan och gör anropet. LLM rör aldrig vid autentiseringsuppgifterna. I praktiken: lateralt rörelse blir mycket svårare, skadeområdet är begränsat till vad exekveringslagret tillåter för den specifika agentidentiteten, och du får en avstängningsknapp. En enda omkopplare och agentens åtkomst stoppas över alla anslutna system. Agenten kan fortfarande manipuleras – men manipulation innebär inte längre automatiskt fullständig autentiseringsuppgiftskompromettering.

I verkliga företagsdistributioner, vad ser centraliserad autentiseringsuppgiftshantering och omedelbar återkallande ut som, och hur skiljer det sig från hur de flesta team hanterar API-nycklar och token för agenter?

Idag har de flesta team en utvecklare som etablerar API-nycklar, lagrar dem i en .env-fil och laddar dem vid agentstart – ofta direkt in i LLM:s sammanhangsfönster. Ingen har en fullständig bild av vilka agenter som innehåller vilka autentiseringsuppgifter. När någon lämnar, roteras inte de nycklar de etablerat. När en agent beter sig konstigt, finns det ingen granskningslogg för att rekonstruera vad som hände. Med Jentic, hanterar utvecklaren aldrig råa autentiseringsuppgifter. De deklarerar vilken åtkomst en agent behöver, plattformen etablerar åtkomst med begränsad omfattning, och agenten anropar genom vårt exekveringslager utan att någonsin se den underliggande nyckeln. Det innebär att du får omedelbar per-agent-återkallande, möjligheten att pausa åtkomst medan du undersöker, och en tidsstämplad granskningslogg för varje API-anrop. Skillnaden mellan det och “API-nyckel i en .env-fil” är betydande.

Många team experimenterar med agent-ramverk över försäljning, teknik och data-vetenskap. Vilka är de vanligaste säkerhetsmisstagen du ser när organisationer flyttar från experiment till produktion?

Samma mönster upprepas: överprivilegierade agenter som fortfarande körs på de admin-autentiseringsuppgifter de prototypades med; autentiseringsuppgifter som skickas i kommandon eller sammanhangsfönster där de hamnar i loggar, telemetri och potentiellt träningsdata; delade autentiseringsuppgifter över flera agent-instanser så att du inte kan isolera en enskild dålig aktör; ingen avstängningsknapp för att stoppa en agent utan att ta ned hela systemet; ingen granskningslogg värd namnet; och kommando-injektion inte tas på allvar – även om varje agent som läser e-post, bearbetar dokument eller bläddrar på webben kommer att stöta på fientligt utformad innehåll. Det gemensamma tråden är att dessa team byggde för den lyckliga vägen och upptäcker nu att produktionen mest består av de olyckliga vägarna.

Jentic positionerar sig som ett hanterat exekveringslager som sitter mellan agent-ramverk och externa system. Hur upprätthåller den mellanliggande lagret styrning utan att sakta ner utvecklare eller minska agentens flexibilitet?

Istället för att koppla en agent till femtio olika API:er – var och en med sitt eget autentiseringschema, begränsningar och egenheter – ansluter utvecklaren till en enda slutpunkt. Den slutpunkten exponerar verktyg för att söka i vår hela katalog av API-kapaciteter, ladda detaljer och utföra varje anrop. Detta maximerar flexibiliteten genom en enda enhetlig gränssnitt till obegränsade API:er, samtidigt som det möjliggör styrning – vilka agenter som har åtkomst till vilka API:er, under vilka förhållanden, med vilka begränsningar – allt hanterat i plattformen, inte i klientkod. Exekveringslagret är ett pass-through; agenter kan fortfarande komponera multi-stegs-arbetsflöden, kedja anrop och hantera fel dynamiskt. Styrning utan friktion är svårt. Genvägen är att lägga bördan på utvecklare. Infrastruktur bör göra det motsatta — absorbera den komplexiteten så att utvecklare inte behöver.

Med infostealer-malware som nu aktivt riktar sig mot agent-konfigurationsfiler och lagrade autentiseringsuppgifter, ser du angripare som flyttar sin fokus mot AI-infrastruktur som en ny högvärdig yta?

Absolut – och logiken är uppenbar. En agent-konfigurationsfil är i princip en multi-tjänst-super-nyckel: autentiseringsuppgifter för e-postsystem, CRM-system, faktureringsplattformar, interna API:er och GitHub-konton. En enda lyckad infostealer-körning ger månader av åtkomst till hela företagets externa system. Det är en dramatiskt högre avkastning än att rikta sig mot någon enskild tjänst i isolering. Den andra dimensionen är att agenter som körs kontinuerligt i produktion är bestående, auktoriserade närvaron – inte en användare som loggar in och ut. En komprometterad agent kan fungera som en långsiktig fotfäste, opererar under upptäcktsgränserna. Den obekväma verkligheten är att angreppsytan utvecklas snabbare än den försvarande verktygen. Jentic kan avsevärt minska autentiseringsuppgifts-angreppsytan, men vi kan inte förhindra att en agent missbrukar de omfattningar den har tilldelats. Det svårare problemet måste lösas på modellnivå, med skydd och kommando-injektionsupptäckt.

Bortom ett enskilt ramverk, vilka bredare säkerhetsprinciper bör organisationer anta om de vill distribuera agenter med AI på ett säkert sätt i stor skala?

De flesta hanterade organisationer kan inte distribuera icke-deterministiska system i sina viktigaste affärsprocesser. En bank eller försäkringsbolag kan inte peka en autonom agent mot sin fakturerings-system och säga “gå och figurera ut”. Så hur innovativa utan att din riskpostur blir en handbroms? Svaret är sandlådor. Skapa en digital kopia av din API-egendom med samma struktur och arbetsflöden, men utan produktionsautentiseringsuppgifter eller konsekvenser. Distribuera agenter där, låt dem utforska, se vad som händer. De lyckade vägarna fångas som strukturerade, deterministiska arbetsflödesautomatiseringar med hjälp av Arazzo, den öppna arbetsflödesspecifikationen som utvecklats inom OpenAPI-initiativet – granskning, upprepningsbar och granskad av varje efterlevnadsteam. Det innebär att du kan flytta i AI-hastighet i sandlådan och i företagshastighet i produktion, och att de två lägena samexisterar. De andra principerna gäller fortfarande – minsta behörighet, granskningsloggar, avstängningsknappar, separation av orkestrering från exekvering. Men sandlådan är det strukturella svaret på den fråga som företagsteam faktiskt fastnar på: hur experimenterar vi med icke-deterministisk AI utan att satsa vår efterlevnads-postur på det? Du distribuerar inte icke-determinismen. Du utvinner värde från den under kontrollerade förhållanden och distribuerar endast de deterministiska utdata. Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Jentic.