Sean Blanchfield, Co-Fondatore e Amministratore Delegato di Jentic – Serie di Interviste

Sean Blanchfield, Co-Fondatore e Amministratore Delegato di Jentic, è un imprenditore tecnologico seriale con decenni di esperienza nella costruzione di grandi aziende di software e infrastrutture. Con sede a Dublino, attualmente guida Jentic e fa anche parte del Consiglio Consultivo per l’Intelligenza Artificiale dell’Irlanda, consigliando il governo sulla politica di intelligenza artificiale. All’inizio della sua carriera, ha co-fondato DemonWare, una piattaforma di servizi online ad alta scala per importanti editori di videogiochi, successivamente acquisita da Activision Blizzard (ATVI ), e PageFair, una startup finanziata da venture capital focalizzata sull’analisi degli ad-blocker, acquisita da Blockthrough. Ha anche fondato o guidato molte altre startup e continua a sostenere l’ecosistema startup irlandese attraverso iniziative come Techpreneurs.

Jentic sta sviluppando un livello di integrazione universale progettato per aiutare gli agenti di intelligenza artificiale a interagire in modo sicuro con i sistemi e le API aziendali. La piattaforma consente alle organizzazioni di collegare i modelli di intelligenza artificiale con gli strumenti interni, i servizi esterni e i flussi di lavoro operativi, mantenendo al contempo la governance, l’autenticazione e la supervisione. Trasformando le API frammentate in interfacce strutturate che gli agenti di intelligenza artificiale possono utilizzare in modo affidabile, Jentic mira a aiutare le imprese a distribuire l’automazione guidata da intelligenza artificiale su larga scala all’interno di ambienti software complessi.

Hai fondato e guidato molte aziende tecnologiche, da DemonWare (acquisita da Activision Blizzard) a PageFair e ora Jentic, e fai anche parte del Consiglio Consultivo per l’Intelligenza Artificiale dell’Irlanda. Cosa ti ha riportato a costruire nuovamente al livello dell’infrastruttura con Jentic, e quale lacuna hai visto nell’ecosistema emergente degli agenti di intelligenza artificiale che gli altri stavano perdendo?

La terza volta che noti un modello, devi prenderlo seriamente. A DemonWare, tutti parlavano di multiplayer online – ma il problema difficile era l’infrastruttura di rete sottostante. La stessa cosa sta accadendo con gli agenti di intelligenza artificiale. I modelli sono notevoli. L’ostacolo è il livello di integrazione – sempre lo è stato. Gli agenti di intelligenza artificiale funzionano su API, e quelle API sono state costruite per gli esseri umani: documentate per gli esseri umani, protette per gli esseri umani e strutturate per gli esseri umani. Punti un agente autonomo su quell’infrastruttura, e si rompe rapidamente. I piloti di intelligenza artificiale aziendale non falliscono perché il modello non ha capito il compito; falliscono perché l’agente non poteva connettersi in modo affidabile ai sistemi di cui aveva bisogno. L’intelligenza artificiale generativa offre un nuovo modo per risolvere questo problema – trattando l’integrazione come un problema di conoscenza, non come un problema di codifica. Quell’intuizione mi ha attirato.

Quando hai iniziato Jentic nel 2024, la sicurezza degli agenti era la tesi principale fin dal primo giorno, o l’attenzione si è focalizzata mentre osservavi come le organizzazioni stavano effettivamente distribuendo agenti autonomi in produzione?

Il primo filo che ho tirato è stato quello delle credenziali. Immaginavo agenti che si moltiplicavano, ognuno dei quali aveva bisogno di credenziali per dozzine di sistemi, tutti quei segreti che fluivano nelle finestre di contesto LLM, venivano esfiltrati – un pasticcio caldo. La risposta è la stessa di vent’anni fa: centralizzare l’autenticazione e l’autorizzazione. Ma tirare quel filo mi ha portato direttamente al prossimo problema: se centralizzi utilizzando strumenti di integrazione tradizionali, sei di nuovo nella terra dei connettori statici, e gli agenti non sono statici. Ciò che ha cementato la visione è stata la realizzazione che la scoperta delle capacità dovrebbe essere strettamente collegata al controllo di accesso – che un agente dovrebbe essere offerto solo una capacità se è effettivamente autorizzato a utilizzarla, e che il sistema che fornisce la scoperta può anche essere il singolo punto di applicazione e osservazione.

La recente esposizione di un gran numero di istanze di agenti che affrontano Internet ha messo in luce come l’orchestrazione e le credenziali spesso condividano lo stesso confine di fiducia. Dal tuo punto di vista, qual è il difetto architettonico fondamentale in quel modello?

Il difetto è semplice: l’agente – un sistema che esegue prompt da un LLM – è anche il sistema che detiene le credenziali e effettua le chiamate API. Compromettere l’agente significa ottenere tutto ciò che potrebbe fare. È lo stesso errore che abbiamo fatto all’inizio dell’era web – server di applicazioni con accesso al database di superutente perché era comodo. Jentic si trova come un livello tra l’agente e le API che chiama. L’agente non detiene mai le credenziali. Emette richieste attraverso il nostro livello di esecuzione gestito, che inietta le credenziali sul lato server, applica le politiche e registra ogni chiamata. E quando qualcosa va storto, c’è un singolo interruttore di arresto – un’azione che ferma l’accesso dell’agente a tutti i sistemi connessi contemporaneamente.

Hai parlato di separare l’orchestrazione dall’esecuzione per contenere il raggio di azione. Puoi spiegare in termini pratici come quella separazione cambi il profilo di rischio quando un’istanza è compromessa?

Nel modello piatto, il LLM ragiona su cosa fare e chiama direttamente le API utilizzando le credenziali che detiene. Compromettere il livello di ragionamento significa controllare il livello di esecuzione. Con la separazione, il LLM emette un’intenzione – “chiama l’API di fatturazione di Stripe con questi parametri” – un livello di esecuzione gestito valida quella richiesta contro la politica, inietta la credenziale sul lato server e effettua la chiamata. Il LLM non tocca mai la credenziale. Nella pratica: il movimento laterale diventa molto più difficile, il raggio di azione è limitato da ciò che il livello di esecuzione consente per quell’identità di agente specifica, e si ottiene un interruttore di arresto. Un singolo toggle e l’accesso dell’agente si ferma su tutti i sistemi connessi. L’agente può ancora essere manipolato – ma la manipolazione non significa più automaticamente il compromesso completo delle credenziali.

Nelle distribuzioni aziendali del mondo reale, cosa significa effettivamente la gestione centralizzata delle credenziali e la revoca istantanea, e come differisce da come la maggior parte dei team sta attualmente gestendo le chiavi API e i token per gli agenti?

Oggi, la maggior parte dei team ha uno sviluppatore che fornisce chiavi API, le memorizza in un file .env e le carica all’avvio dell’agente – spesso direttamente nella finestra di contesto LLM. Nessuno ha una visione completa di quali agenti detengono quali credenziali. Quando qualcuno se ne va, le chiavi che ha fornito non vengono ruotate. Quando un agente si comporta in modo strano, non c’è una traccia di audit per ricostruire cosa è successo. Con Jentic, lo sviluppatore non gestisce mai le credenziali grezze. Dichiara quale accesso è necessario per un agente, la piattaforma fornisce un accesso ambito e l’agente chiama attraverso il nostro livello di esecuzione senza mai vedere la chiave sottostante. Ciò significa ottenere la revoca istantanea per agente, la capacità di interrompere l’accesso mentre si indaga e una traccia di audit timestampata di ogni chiamata API. La differenza tra questo e “chiave API in un file .env” è sostanziale.

Molti team stanno sperimentando con framework di agenti in vendita, ingegneria e scienza dei dati. Quali sono gli errori di sicurezza più comuni che stai vedendo mentre le organizzazioni passano dall’esperimento alla produzione?

Gli stessi modelli si ripetono: agenti ancora in esecuzione con le credenziali di amministratore con cui sono stati prototipati; credenziali passate in prompt o finestre di contesto dove finiscono nei log, nella telemetria e potenzialmente nei dati di formazione; credenziali condivise tra più istanze di agenti in modo che non si possa isolare un singolo attore malvagio; nessun interruttore di arresto per fermare un agente senza disabilitare l’intero sistema; nessuna traccia di audit degna di questo nome; e iniezione di prompt non presa seriamente – anche se qualsiasi agente che legge e-mail, elabora documenti o naviga nel web incontrerà contenuti creati in modo avversario. Il filo comune è che questi team hanno costruito per il percorso felice e stanno ora scoprendo che la produzione è per lo più percorsi infelici.

Jentic si posiziona come un livello di esecuzione gestito tra i framework di agenti e i sistemi esterni. Come fa quel livello intermedio a imporre la governance senza rallentare gli sviluppatori o ridurre la flessibilità degli agenti?

Invece di collegare un agente a cinquanta diverse API – ognuna con il proprio schema di autenticazione, limiti di velocità e peculiarità – lo sviluppatore si collega a un endpoint. Quell’endpoint espone strumenti per cercare nel nostro intero catalogo di capacità API, caricare i dettagli e eseguire qualsiasi chiamata. Ciò massimizza la flessibilità attraverso un’interfaccia unificata per API illimitate, consentendo al contempo la governance – quali agenti accedono a quali API, in quali condizioni, con quali limiti – tutto gestito nella piattaforma, non nel codice client. Il livello di esecuzione è un pass-through; gli agenti possono ancora comporre flussi di lavoro multistep, concatenare chiamate e gestire gli errori in modo dinamico. La governance senza attrito è difficile. La scorciatoia è spingere il carico sui developer. L’infrastruttura dovrebbe fare il contrario – assorbire quella complessità in modo che i developer non debbano farlo.

Con il malware infostealer che ora prende di mira attivamente i file di configurazione degli agenti e le credenziali memorizzate, vedi gli attaccanti spostare la loro attenzione verso l’infrastruttura di intelligenza artificiale come una nuova area di superficie ad alto valore?

Assolutamente – e la logica è ovvia. Un file di configurazione di un agente è effettivamente una superchiave multiservizio: credenziali per sistemi di posta elettronica, CRM, piattaforme di fatturazione, API interne e account GitHub. Un singolo esecuzione di infostealer di successo produce mesi di accesso in tutta l’area dei sistemi esterni di un’azienda. Questo rappresenta un ritorno drasticamente più alto rispetto a quello di targeting qualsiasi servizio isolato. L’altra dimensione è che gli agenti che eseguono in modo continuo in produzione sono presenze credenziate persistenti – non un utente che si collega e si disconnette. Un agente compromesso può servire come un punto di appiglio a lungo termine, operando al di sotto dei limiti di rilevamento. La realtà scomoda è che la superficie di attacco si sta evolvendo più velocemente della strumentazione difensiva. Jentic può ridurre notevolmente la superficie di attacco delle credenziali, ma non può impedire a un agente di utilizzare male gli ambiti che gli sono stati concessi. Quel problema più difficile deve essere risolto a livello di modello, con paratie e rilevamento dell’iniezione di prompt.

Oltre a qualsiasi singolo framework, quali principi di sicurezza più ampi le organizzazioni dovrebbero adottare se desiderano distribuire in modo sicuro l’intelligenza artificiale agente su larga scala?

La maggior parte delle organizzazioni gestite non può distribuire sistemi non deterministici nei propri processi aziendali più preziosi. Una banca o un’assicurazione non può puntare un agente autonomo al proprio sistema di fatturazione e dire “figuralo”. Quindi, come si fa a innovare senza che la propria postura di rischio diventi un freno? La risposta è la sandbox. Crea un gemello digitale del tuo patrimonio API con la stessa struttura e flussi di lavoro, ma senza credenziali di produzione o conseguenze. Distribuisci gli agenti lì, lasciali esplorare, osserva cosa succede. I percorsi di successo vengono catturati come automazioni di flussi di lavoro deterministici strutturati utilizzando Arazzo, la specifica di flusso di lavoro aperta sviluppata all’interno dell’iniziativa OpenAPI – verificabile, ripetibile e verificabile da qualsiasi team di conformità. Ciò significa che puoi muoverti alla velocità dell’intelligenza artificiale nella sandbox e alla velocità aziendale in produzione, e quei due modi coesistono. I principi restano validi – il minimo privilegio, le tracce di audit, gli interruttori di arresto, la separazione dell’orchestrazione dall’esecuzione. Ma la sandbox è la risposta strutturale alla domanda con cui le squadre aziendali effettivamente rimangono bloccate: come facciamo a sperimentare con l’intelligenza artificiale non deterministica senza scommettere la nostra postura di conformità su di essa? Non si distribuisce la non determinazione. Si estrae valore da essa in condizioni controllate e si distribuiscono solo gli output deterministici.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Jentic.