Sean Blanchfield, Co-Fondator și CEO al Jentic – Seria de Interviuri

Sean Blanchfield, Co-Fondator și CEO al Jentic, este un antreprenor tehnologic serial cu zeci de ani de experiență în construirea de companii de software și infrastructură la scară largă. Cu sediul în Dublin, el conduce în prezent Jentic, iar în același timp face parte din Consiliul Consultativ pentru Inteligență Artificială din Irlanda, sfătuind guvernul cu privire la politica de inteligență artificială. La începutul carierei sale, el a co-fondat DemonWare, o platformă de servicii online la scară largă pentru editori de jocuri video de mare anvergură, care a fost ulterior achiziționată de Activision Blizzard (ATVI ) , și PageFair, o companie startup finanțată de venture care se axează pe analiza blocării de reclame, care a fost achiziționată de Blockthrough. El a fondat sau condus, de asemenea, mai multe startup-uri și continuă să sprijine ecosistemul startup-urilor din Irlanda prin inițiative precum Techpreneurs.

Jentic dezvoltă un strat de integrare universal destinat să ajute agenții de inteligență artificială să interacționeze în siguranță cu sistemele și API-urile întreprinderilor. Platforma permite organizațiilor să conecteze modelele de inteligență artificială cu uneltele interne, serviciile externe și fluxurile de lucru operaționale, menținând în același timp guvernanța, autentificarea și supravegherea. Prin transformarea API-urilor fragmentate în interfețe structurate pe care agenții de inteligență artificială le pot utiliza în mod fiabil, Jentic își propune să ajute întreprinderile să implementeze automatizarea condusă de inteligență artificială la scară, în medii software complexe.

Ai fondat și condus mai multe companii tehnologice, de la DemonWare (achiziționată de Activision Blizzard) la PageFair și acum Jentic, și faci parte, de asemenea, din Consiliul Consultativ pentru Inteligență Artificială din Irlanda. Ce te-a determinat să revii la construirea la nivelul de infrastructură cu Jentic, și ce lacună ai văzut în ecosistemul emergent de agenți de inteligență artificială pe care alții o ignorau?

La a treia oară când observi un model, trebuie să îl iei în serios. La DemonWare, toată lumea vorbea despre multiplayer online – dar problema grea era infrastructura de rețea de sub el. Același lucru se întâmplă și cu agenții de inteligență artificială. Modelele sunt remarcabile. Sticla de gât este stratul de integrare – întotdeauna a fost. Agenții de inteligență artificială rulează pe API-uri, iar aceste API-uri au fost create pentru oameni: documentate pentru oameni, securizate pentru oameni și structurate pentru oameni. Îndreaptă un agent autonom către această infrastructură, și se prăbușește rapid. Proiectele-pilot de inteligență artificială din întreprinderi nu eşuează pentru că modelul nu a înțeles sarcina; eşuează pentru că agentul nu a putut conecta în mod fiabil la sistemele de care avea nevoie. Inteligența artificială generativă oferă un mod nou de a rezolva această problemă – prin tratarea integrării ca o problemă de cunoaștere, nu ca o problemă de codare. Această perspectivă m-a atras.

Când ai început Jentic în 2024, a fost securitatea agentului principala teză de la început, sau s-a ascuțit focalizarea pe măsură ce ai observat cum organizațiile implementează în mod real agenți autonomi în producție?

Primul fir pe care l-am tras a fost cel al credențialelor. M-am imaginat agenți care proliferează, fiecare având nevoie de credențiale pentru zeci de sisteme, toate aceste secrete curgând în ferestrele de context LLM, fiind extrase – un haos total. Răspunsul este același ca și acum douăzeci de ani: centralizați autentificarea și autorizarea. Dar trăgând de acest fir m-a condus direct la următoarea problemă: dacă centralizați folosind unelte de integrare tradiționale, sunteți înapoi în țara conectoarelor statice, iar agenții nu sunt statici. Ceea ce a cimentat viziunea a fost realizarea că descoperirea capacităților ar trebui să fie strâns legată de controlul accesului – că un agent ar trebui să primească o capacitate doar dacă este autorizat să o utilizeze, și că sistemul care oferă descoperirea poate fi, de asemenea, punctul unic de aplicare și observare.

Expunerea recentă a unui număr mare de instanțe de agenți cu internet a evidențiat modul în care orchestrarea și credențialele adesea împărtășesc aceeași limită de încredere. Din perspectiva ta, care este defectul arhitectural de bază în acest model?

Defectul este simplu: agentul – un sistem care rulează prompturi dintr-un LLM – este și sistemul care deține credențialele și face apelurile API. Compromite agentul și vei obține tot ceea ce ar putea face vreodată. Este aceeași greșeală pe care am făcut-o în era web-ului timpuriu – servere de aplicații cu acces de superutilizator la baze de date, deoarece era convenabil. Jentic se află ca un strat între agent și API-urile pe care le apelează. Agentul nu deține niciodată credențiale. El emite solicitări prin stratul nostru de execuție gestionat, care injectează credențialele server-side, aplică politica și înregistrează fiecare apel. Și când ceva merge prost, există un singur comutator de oprire – o singură acțiune care oprește accesul agentului la toate sistemele conectate, simultan.

Ai vorbit despre separarea orchestration de execuție pentru a conține raza de explozie. Poți explica în termeni practici cum această separare modifică profilul de risc atunci când o instanță este compromisă?

În modelul plat, LLM-ul raționează despre ce să facă și apelează direct API-urile folosind credențialele pe care le deține. Compromite stratul de raționament, și vei controla stratul de execuție. Cu separarea, LLM-ul emite o intenție – “apelă API-ul de facturare Stripe cu aceste parametri” – un strat de execuție gestionat verifică solicitarea împotriva politicii, injectează credenționalele server-side și face apelul. LLM-ul nu atinge niciodată credenționala. În practică: mișcarea laterală devine mult mai grea, raza de explozie este delimitată de ceea ce stratul de execuție permite pentru acea identitate de agent specifică, și obții un comutator de oprire. Un singur toggle și accesul agentului se oprește peste toate sistemele conectate. Agentul poate fi încă manipulat – dar manipularea nu mai înseamnă automat compromiterea completă a credenționalelor.

În implementările reale ale întreprinderilor, ce reprezintă gestionarea centralizată a credențialelor și revocarea instantanee, și cum diferă aceasta de modul în care majoritatea echipelor gestionează în prezent cheile API și token-urile pentru agenți?

Astăzi, majoritatea echipelor au un dezvoltator care alocă chei API, le stochează într-un fișier .env și le încarcă la pornirea agentului – adesea direct în fereastra de context LLM. Nimeni nu are o imagine completă a agenților care dețin ce credenționale. Când cineva pleacă, cheile pe care le-a alocat nu sunt rotite. Când un agent se comportă ciudat, nu există nicio urmă de audit pentru a reconstitui ce s-a întâmplat. Cu Jentic, dezvoltatorul nu manipulează niciodată credenționale brute. Ei declară ce acces necesită un agent, platforma alocă acces cu scop, și agentul apelează prin stratul nostru de execuție fără a vedea niciodată cheia subiacentă. Acest lucru înseamnă că obții revocare instantanee pe agent, capacitatea de a pune în pauză accesul în timp ce investighezi, și o urmă de audit cu timestamp pentru fiecare apel API. Diferența dintre aceasta și “cheia API într-un fișier .env” este substanțială.

Multe echipe experimentează cu cadre de agenți în vânzări, inginerie și știință a datelor. Care sunt cele mai comune greșeli de securitate pe care le observi atunci când organizațiile trec de la experimentare la producție?

Aceleași modele se repetă: agenți supradotati care rulează încă pe credențialele de administrator cu care au fost prototipate; credențiale trecute în prompturi sau ferestre de context unde ajung în jurnale, telemetrie și, posibil, în datele de antrenament; credențiale partajate între multiple instanțe de agenți, astfel încât nu puteți izola un singur actor rău; niciun comutator de oprire pentru a opri un agent fără a lua întregul sistem; nicio urmă de audit demnă de numit; și injecția de prompturi nu este luată în serios – chiar dacă orice agent care citește e-mailuri, prelucrează documente sau navighează pe web va întâlni conținut adversar creat. Firea comună este că aceste echipe au construit pentru calea fericită și acum descoperă că producția este, în mare parte, căile nefericite.

Jentic se poziționează ca un strat de execuție gestionat, situat între cadrele de agenți și sistemele externe. Cum impune acest strat intermediar guvernanța fără a încetini dezvoltatorii sau a reduce flexibilitatea agenților?

În loc de a conecta un agent la cincizeci de API-uri diferite – fiecare cu propriul sistem de autentificare, limite de rată și ciudățenii – dezvoltatorul se conectează la un singur punct de terminare. Acest punct de terminare oferă instrumente pentru a căuta întregul catalog de capacități API, a încărca detalii și a executa orice apel. Acest lucru maximizează flexibilitatea printr-o interfață unificată pentru API-uri nelimitate, permițând în același timp guvernanța – care agenți accesează care API-uri, în ce condiții, cu ce limite – gestionate în platformă, nu în codul client. Stratul de execuție este un pasaj; agenții pot încă compune fluxuri de lucru multi-pași, lanțuri de apeluri și gestionarea dinamică a erorilor. Guvernanța fără frecare este grea. Scurtătura este să împingi povara asupra dezvoltatorilor. Infrastructura ar trebui să facă contrariul – să absoarbă acea complexitate, astfel încât dezvoltatorii să nu fie nevoiți să o facă.

Cu malware-ul infostealer care vizează în mod activ fișierele de configurare ale agenților și credențialele stocate, vezi atacatorii schimbându-și focalizarea către infrastructura de inteligență artificială ca o nouă zonă de suprafață de înaltă valoare?

Absolut – și logica este evidentă. Un fișier de configurare a agentului este, în esență, o supercheie multiservicii: credențiale pentru sisteme de e-mail, CRM, platforme de facturare, API-uri interne și conturi GitHub. O singură execuție reușită de infostealer oferă acces pe parcursul mai multor luni la sistemele externe ale unei companii. Acesta este un randament dramatic mai mare decât vizarea oricărui serviciu izolat. Cealaltă dimensiune este că agenții care rulează continuu în producție sunt prezențe credenționate persistente – nu un utilizator care se conectează și deconectează. Un agent compromis poate servi ca o poziție de aterizare pe termen lung, operând sub pragurile de detectare. Realitatea incomodă este că suprafața de atac evoluează mai repede decât instrumentele defensive. Jentic poate reduce semnificativ suprafața de atac a credențialelor, dar nu poate preveni ca un agent să nu-și folosească scopurile acordate. Această problemă mai grea trebuie rezolvată la nivelul modelului, cu păzitori și detectarea injecției de prompturi.

Dincolo de orice cadru individual, care sunt principiile de securitate mai ample pe care organizațiile ar trebui să le adopte dacă doresc să implementeze în siguranță inteligența artificială agentică la scară?

Majoritatea organizațiilor gestionate nu pot implementa sisteme nedeterministe în procesele lor de afaceri cele mai valoroase. O bancă sau o companie de asigurări nu poate direcționa un agent autonom către sistemul lor de facturare și spune “figuriți-vă”. Așadar, cum inovați fără a vă transforma postura de risc într-un frână? Răspunsul este sandboxarea. Creați un dublu digital al moștenirii dvs. API cu aceeași structură și fluxuri de lucru, dar fără credențiale de producție sau consecințe. Implementați agenți acolo, lăsați-i să exploreze, urmăriți ce se întâmplă. Căile de succes sunt capturate ca automatizări de fluxuri de lucru structurate și deterministice, utilizând Arazzo, specificația de flux de lucru deschisă dezvoltată în cadrul OpenAPI Initiative – auditabile, reproductibile și examinabile de orice echipă de conformitate. Acest lucru înseamnă că puteți mișca cu viteza inteligenței artificiale în sandbox și cu viteza întreprinderii în producție, și că aceste moduri coexistă. Celelalte principii încă se aplică – cel mai mic privilegiu, urme de audit, comutatoare de oprire, separarea orchestration de execuție. Dar sandboxarea este răspunsul structural la întrebarea cu care echipele întreprinderilor se blochează de fapt: cum experimentăm cu inteligența artificială nedeterministă fără a ne pune postura de conformitate pe ea? Nu implementați nedeterminismul. Extrageți valoarea de sub condiții controlate și implementați doar ieșirile deterministice.

Mulțumim pentru acest interviu minunat, cititorilor care doresc să afle mai multe despre Jentic.