Sean Blanchfield, mede-oprichter en CEO van Jentic – Interview Serie

Sean Blanchfield, mede-oprichter en CEO van Jentic, is een serie-technologieondernemer met decennia ervaring in het opbouwen van grote software- en infrastructuurbedrijven. Gevestigd in Dublin, leidt hij momenteel Jentic en zit hij ook in de AI-adviesraad van Ierland, waar hij de regering adviseert over het beleid voor kunstmatige intelligentie. Eerder in zijn carrière was hij mede-oprichter van DemonWare, een platform voor online diensten voor grote videogame-uitgevers dat later werd overgenomen door Activision Blizzard (ATVI ), en PageFair, een startup met venture-backing die zich richtte op ad-blocking analytics en werd overgenomen door Blockthrough. Hij heeft ook meerdere startups opgericht of geleid en blijft Ierlands startup-ecosysteem ondersteunen via initiatieven zoals Techpreneurs.

Jentic ontwikkelt een universele integratielaag die AI-agents in staat stelt om veilig te communiceren met bedrijfsystemen en API’s. Het platform stelt organisaties in staat om AI-modellen te verbinden met interne tools, externe diensten en operationele workflows, terwijl governance, authenticatie en toezicht worden gehandhaafd. Door gefragmenteerde API’s om te zetten in gestructureerde interfaces die AI-agents betrouwbaar kunnen gebruiken, beoogt Jentic bedrijven te helpen om AI-gedreven automatisering op grote schaal in te zetten in complexe software-omgevingen.

U heeft meerdere technologiebedrijven opgericht en geleid, van DemonWare (overgenomen door Activision Blizzard) tot PageFair en nu Jentic, en u zit ook in de AI-adviesraad van Ierland. Wat trok u terug naar het opbouwen van de infrastructuurlaag met Jentic, en welke lacune zag u in het opkomende AI-agent-ecosysteem dat anderen misten?

Als je voor de derde keer een patroon ziet, moet je het serieus nemen. Bij DemonWare praatten iedereen over online multiplayer – maar het harde probleem was de netwerk infrastructuur eronder. Hetzelfde gebeurt met AI-agents. De modellen zijn opmerkelijk. De bottleneck is de integratielaag – altijd al geweest. AI-agents draaien op API’s, en die API’s zijn gebouwd voor mensen: gedocumenteerd voor mensen, beveiligd voor mensen en gestructureerd voor mensen. Richt een autonome agent op die infrastructuur, en het valt snel uit elkaar. Enterprise AI-piloten falen niet omdat het model de taak verkeerd begreep; ze falen omdat de agent niet betrouwbaar kon verbinden met de systemen die het nodig had. Generatieve AI biedt een nieuwe manier om dit op te lossen – door integratie te behandelen als een kennisprobleem, niet als een coderingsprobleem. Die inzicht trok me aan.

Toen u Jentic in 2024 startte, was agentbeveiliging vanaf het begin het primaire these, of werd de focus scherper naarmate u zag hoe organisaties autonome agenten in productie inzetten?

Het allereerste draadje dat ik trok was credentials. Ik stelde me voor dat agenten zich zouden vermenigvuldigen, elk met credentials voor tientallen systemen, al die geheimen die in LLM-contextvensters stromen, worden geëxtraheerd – een hete chaos. Het antwoord is hetzelfde als het twintig jaar geleden zou zijn: centraliseer authenticatie en autorisatie. Maar het trekken van dat draadje leidde rechtstreeks naar het volgende probleem: als je centraliseert met traditionele integratietooling, ben je terug in het land van statische connectors, en agenten zijn niet statisch. Wat de visie verankerde, was het realiseren dat capability discovery nauw verbonden moet zijn met toegangscontrole – dat een agent alleen een capaciteit moet worden aangeboden als het daadwerkelijk is geautoriseerd om het te gebruiken, en dat het systeem dat discovery biedt ook het enige punt van handhaving en observatie kan zijn.

De recente blootstelling van een groot aantal internetgerichte agentinstanties heeft laten zien hoe orkestratie en credentials vaak dezelfde vertrouwensgrens delen. Wat is uit uw oogpunt het kernarchitectonische gebrek in dat model?

Het gebrek is eenvoudig: de agent – een systeem dat prompts van een LLM uitvoert – is ook het systeem dat de credentials bezit en de API-aanroepen doet. Compromitteer de agent en je krijgt alles wat het ooit kan doen. Het is dezelfde fout die we in de vroege webperiode maakten – applicatieservers met superuser-database-toegang omdat het handig was. Jentic zit als een laag tussen de agent en de API’s die het aanroept. De agent heeft nooit credentials. Het geeft verzoeken door via onze beheerde uitvoeringslaag, die credentials server-side injecteert, beleid afdwingt en elke aanroep logt. En als er iets misgaat, is er een enkele kill switch – één actie stopt de toegang van die agent tot elk verbonden systeem tegelijkertijd.

U heeft gesproken over het scheiden van orkestratie van uitvoering om de blast radius te beperken. Kun je in praktische zin uitleggen hoe die scheiding de risicoprofiel verandert wanneer een instantie wordt gecompromitteerd?

In het platte model redeneert de LLM over wat te doen en roept het API’s rechtstreeks aan met de credentials die het bezit. Compromitteer de redeneringslaag, en je controleert de uitvoeringslaag. Met scheiding geeft de LLM een intentie – “roep de Stripe-betaling-API aan met deze parameters” – een beheerde uitvoeringslaag valideert dat verzoek tegen beleid, injecteert de credential server-side en doet de aanroep. De LLM raakt de credential nooit aan. In de praktijk: laterale beweging wordt veel moeilijker, de blast radius is begrensd door wat de uitvoeringslaag toestaat voor die specifieke agentidentiteit, en je krijgt een kill switch. Één toggle en de toegang van de agent tot elk verbonden systeem stopt. De agent kan nog steeds worden gemanipuleerd – maar manipulatie betekent niet automatisch volledige credential-compromittering.

In echte enterprise-implementaties, hoe ziet centrale credentialbeheer en instant revocatie eruit, en hoe verschilt dit van hoe de meeste teams momenteel API-sleutels en tokens voor agenten behandelen?

Vandaag de dag hebben de meeste teams een ontwikkelaar die API-sleutels provisioneert, ze opslaat in een .env-bestand en ze laadt bij het opstarten van de agent – vaak rechtstreeks in het LLM-contextvenster. Niemand heeft een volledig beeld van welke agenten welke credentials bezitten. Wanneer iemand vertrekt, worden de sleutels die hij provisioneerde niet geroteerd. Wanneer een agent vreemd gedrag vertoont, is er geen audittrail om te reconstrueren wat er gebeurde. Met Jentic behandelt de ontwikkelaar nooit brute credentials. Ze verklaren welke toegang een agent nodig heeft, het platform provisioneert gescopeerde toegang en de agent roept door onze uitvoeringslaag zonder ooit de onderliggende sleutel te zien. Dat betekent dat je instant per-agent-revocatie krijgt, de mogelijkheid om toegang te pauzeren terwijl je onderzoekt en een getijdstemplede audittrail van elke API-aanroep. Het verschil tussen dat en “API-sleutel in een .env-bestand” is aanzienlijk.

Veel teams experimenteren met agentframeworks in verkoop, engineering en datawetenschap. Wat zijn de meest voorkomende beveiligingsfouten die u ziet als organisaties van experimenten naar productie gaan?

Dezelfde patronen herhalen zich: overgeprivilegieerde agenten die nog steeds op de admin-credentials draaien waarmee ze zijn geprototypeerd; credentials die in prompts of contextvensters worden doorgegeven waar ze in logs, telemetrie en potentieel trainingsdata terechtkomen; gedeelde credentials over meerdere agentinstanties, zodat je geen enkele slechte actor kunt isoleren; geen kill switch om een agent te stoppen zonder het bredere systeem uit te schakelen; geen audittrail die de moeite waard is; en prompt-injectie niet serieus nemen – zelfs niet als een agent e-mails leest, documenten verwerkt of op het web surft en zal tegen vijandig gecreëerde inhoud komen. De gemeenschappelijke draad is dat deze teams voor de happy path bouwen en nu ontdekken dat productie meestal ongelukkige paden zijn.

Jentic positioneert zichzelf als een beheerde uitvoeringslaag tussen agentframeworks en externe systemen. Hoe verplicht die tussenlaag governance zonder ontwikkelaars te vertragen of agentflexibiliteit te verminderen?

In plaats van een agent rechtstreeks te verbinden met vijftig verschillende API’s – elk met zijn eigen authenticatieschema, limieten en eigenaardigheden – verbindt de ontwikkelaar met één endpoint. Dat endpoint biedt tools om onze hele catalogus van API-mogelijkheden te doorzoeken, details te laden en elke aanroep uit te voeren. Dit maximaliseert flexibiliteit via een enkel uniform interface voor onbeperkte API’s, terwijl governance mogelijk wordt – welke agenten toegang hebben tot welke API’s, onder welke voorwaarden, met welke limieten – alles wordt beheerd in het platform, niet in clientcode. De uitvoeringslaag is een doorgeefluik; agenten kunnen nog steeds multi-stap-workflows samenstellen, aanroepen ketenen en dynamisch fouten afhandelen. Governance zonder wrijving is moeilijk. De shortcut is om de last op ontwikkelaars af te wentelen. Infrastructuur moet het tegenovergestelde doen – die complexiteit absorberen zodat ontwikkelaars het niet hoeven te doen.

Met infostealer-malware die nu actief agentconfiguratiebestanden en opgeslagen credentials aanvalt, ziet u aanvallers hun focus verleggen naar AI-infrastructuur als een nieuwe hoge-waarde-oppervlakte?

Absoluut – en de logica is voor de hand liggend. Een agentconfiguratiebestand is effectief een multi-service-superkey: credentials voor e-mailsystemen, CRMs, facturingsplatforms, interne API’s en GitHub-accounts. Een enkele succesvolle infostealer-run levert maanden aan toegang tot alle externe systemen van een heel bedrijf op. Dat is een dramatisch hogere opbrengst dan het aanvallen van een enkele dienst in isolatie. De andere dimensie is dat agenten die continu in productie draaien, persistente, gecrediteerde aanwezigheden zijn – niet een gebruiker die in- en uitlogt. Een gecompromitteerde agent kan dienen als een langdurig steunpunt, opererend onder detectie-drempels. De oncomfortabele realiteit is dat de aanvalssurface sneller evolueert dan de defensieve tooling. Jentic kan de credential-aanvalssurface aanzienlijk verkleinen, maar we kunnen niet voorkomen dat een agent zijn scopes misbruikt. Dat hardere probleem moet op het modelniveau worden opgelost, met guardrails en prompt-injectiedetectie.

Behalve een enkel framework, welke bredere beveiligingsprincipes moeten organisaties aannemen als ze veilig AI-agents op grote schaal willen inzetten?

De meeste beheerde organisaties kunnen geen niet-deterministische systemen in hun meest waardevolle bedrijfsprocessen inzetten. Een bank of verzekeraar kan geen autonome agent naar hun factureringssysteem wijzen en zeggen “ga maar figuur het uit.” Hoe kun je dus innoveren zonder dat je risicohouding een rem wordt? Het antwoord is sandboxen. Creëer een digitale tweeling van uw API-bezit met dezelfde structuur en workflows, maar zonder productiecredentials of gevolgen. Zet agenten daar, laat ze verkennen, kijk wat er gebeurt. De succesvolle paden worden vastgelegd als gestructureerde, deterministische workflowautomatiseringen met behulp van Arazzo, de open workflow-specificatie ontwikkeld binnen de OpenAPI-initiatief – auditeerbaar, herhaalbaar en door elk compliance-team te controleren. Dit betekent dat je op AI-snelheid in de sandbox en op bedrijfssnelheid in productie kunt bewegen, en die twee modi coëxisteren. De andere principes gelden nog steeds – minste privilege, audittrails, kill switches, scheiding van orkestratie van uitvoering. Maar de sandbox is het structurele antwoord op de vraag waarop enterprise-teams eigenlijk vast komen te zitten: hoe experimenteren we met niet-deterministische AI zonder onze compliance-houding in te zetten? U zet de niet-deterministische AI niet in. U haalt waarde uit onder gecontroleerde omstandigheden en zet alleen de deterministische uitvoer in.

Bedankt voor het geweldige interview, lezers die meer willen leren, moeten Jentic bezoeken.