Sean Blanchfield, spoluzakladatel a CEO společnosti Jentic – Interview Series

Sean Blanchfield, spoluzakladatel a CEO společnosti Jentic, je zkušený technologický podnikatel s desetiletými zkušenostmi s budováním velkých softwarových a infrastrukturních společností. Se sídlem v Dublinu v současné době vede Jentic a zároveň působí v Irské radě pro umělou inteligenci, kde radí vládě v oblasti politiky umělé inteligence. Na počátku své kariéry spoluzakládal DemonWare, platformu pro velké online služby pro hlavní vydavatele videoher, která byla později získaná společností Activision Blizzard (ATVI ), a PageFair, startup financovaný venture kapitálem, zaměřený na analytiku blokování reklam, který byl později získán společností Blockthrough. Založil nebo vedl několik startupů a nadále podporuje irskou startupovou ekosystém prostřednictvím iniciativ, jako je Techpreneurs.

Jentic vyvíjí univerzální integrační vrstvu, která má pomoci agentům umělé inteligence bezpečně komunikovat s podnikovými systémy a API. Platforma umožňuje organizacím propojit modely umělé inteligence s interními nástroji, externími službami a provozními pracovními postupy, zatímco zachovává správu, ověření a dohled. Transformací fragmentovaných API na strukturovaná rozhraní, která agenti umělé inteligence mohou spolehlivě využívat, Jentic usiluje o pomoc podnikům při nasazování automatizace poháněné umělou inteligencí ve velkém měřítku v komplexních softwarových prostředích.

Vy jste založil a vedl několik technologických společností, od DemonWare (získané společností Activision Blizzard) po PageFair a nyní Jentic, a zároveň působíte v Irské radě pro umělou inteligenci. Co vás přimělo k návratu do budování na infrastrukturní úrovni s Jentic, a jakou mezeru jste viděl v ekosystému agentů umělé inteligence, kterou ostatní postrádali?

Třetíkrát, když si všimnete vzoru, musíte to brát vážně. V DemonWare všichni mluvili o online multiplayeru – ale tvrdý problém byl síťová infrastruktura pod ním. Stejné se děje s agenty umělé inteligence. Modely jsou pozoruhodné. Úzké místo je integrační vrstva – vždycky to bylo. Agenti umělé inteligence běží na API, a ta API byla postavena pro lidi: dokumentovaná pro lidi, zabezpečená pro lidi a strukturovaná pro lidi. Ukážete autonomnímu agentovi na tu infrastrukturu, a rozpadne se rychle. Pilotní projekty podnikové umělé inteligence neselhávají, protože model nepochopil úkol; selhávají, protože agent nemohl spolehlivě připojit se k systémům, které potřeboval. Generativní umělá inteligence nabízí nový způsob, jak tento problém vyřešit – tím, že se integrační problém řeší jako problém znalostí, ne jako problém kódování. Ta myšlenka mě přitáhla.

Když jste v roce 2024 založil Jentic, byla bezpečnost agentů primární tezí od samého počátku, nebo se zaměření zostřilo, když jste pozorovali, jak organizace nasazují autonomní agenty v produkci?

První nit, kterou jsem vytáhl, byly pověření. Představil jsem si agenty, kteří se množí, každý z nich potřebuje pověření pro desítky systémů, všechny ty tajnosti proudí do kontextových oken LLM, jsou vyčerpány – horký nepořádek. Odpověď je stejná jako by to bylo před dvaceti lety: centralizovat ověření a autorizaci. Ale vytáhnutí té nitky vedlo přímo k dalšímu problému: pokud centralizujete pomocí tradičních integračních nástrojů, jste zpět v zemi statických konektorů, a agenti nejsou statické. Co upevnilo vizi, bylo uvědomění, že zjištění schopností by mělo být úzce spojeno s přístupovým řízením – že by agentovi mělo být nabídnuto pouze schopnosti, pro které je skutečně autorizován, a že systém, který poskytuje zjištění, může být také jediným bodem vynucování a pozorovatelnosti.

Nedávné odhalení velkého počtu internetových agentů s instancemi vysoce zdůraznilo, jak orchestrace a pověření často sdílejí stejnou hranici důvěry. Z vašeho pohledu, jaký je základní architektonický nedostatek v tomto modelu?

Nedostatek je jednoduchý: agent – systém, který běží na podnětech z LLM – je také systém, který drží pověření a provádí API volání. Ohrožte agenta a získáte vše, co by mohl kdykoli udělat. Je to stejná chyba, kterou jsme udělali v rané éře webu – aplikační servery s přístupem superuživatele k databázi, protože to bylo pohodlné. Jentic sedí jako vrstva mezi agentem a API, které volá. Agent nikdy nedrží pověření. Vyjadřuje požadavky prostřednictvím naší řízené vrstvy, která vkládá pověření server-side, vynucuje zásady a protokoluje každé volání. A když něco goes wrong, je tam jediná vypínače – jedna akce zastaví přístup agenta ke všem propojeným systémům současně.

Mluvili jste o oddělení orchestrace od provádění, aby se omezila rádio exploze. Můžete vysvětlit v praktických termínech, jak se změní riziko, když je instance ohrožena?

V plochém modelu LLM rozumí, co dělat a přímo volá API pomocí pověření, která drží. Ohrožte vrstvu rozumění, a budete mít kontrolu nad vrstvou provádění. S oddělením LLM vydává intent – “volat API Stripe billing s těmito parametry” – řízená vrstva ověřuje ten požadavek proti zásadám, vkládá pověření server-side a provádí volání. LLM se nikdy nedotkne pověření. V praxi: laterální pohyb se stává mnohem těžším, rádio exploze je omezeno tím, co řízená vrstva povoluje pro tu konkrétní agentní identitu, a získáte vypínače. Jedna akce a přístup agenta se zastaví ke všem propojeným systémům. Agent může být stále manipulován – ale manipulace již automaticky neznamená úplné ohrožení pověření.

V reálných podnikových nasazeních, jak vypadá centralizovaná správa pověření a okamžitá revokace, a jak se liší od toho, jak většina týmů目前 handles API klíče a tokeny pro agenty?

Dnes většina týmů má vývojáře, který zřizuje API klíče, ukládá je do souboru .env a načítá je při spuštění agenta – často přímo do kontextového okna LLM. Nikdo nemá úplný přehled o tom, které agenty drží která pověření. Když někdo odejde, klíče, které zřídil, se neotáčí. Když se agent chová divně, není tam žádný auditní stopa, aby se dalo rekonstruovat, co se stalo. S Jentic vývojář nikdy nezpracovává surová pověření. Deklaruje, jaký přístup potřebuje agent, platforma zřídí rozsah přístupu, a agent volá prostřednictvím naší řízené vrstvy bez toho, aby viděl podkladový klíč. To znamená, že získáte okamžitou revokaci na agenta, schopnost pozastavit přístup, zatímco vyšetřujete, a časově označenou auditní stopu každého API volání. Rozdíl mezi tím a “API klíč v souboru .env” je podstatný.

Mnohé týmy experimentují s rámci agentů napříč prodejem, inženýrstvím a datovou vědou. Jaké jsou nejčastější bezpečnostní pochybení, které vidíte, když organizace přecházejí z experimentování do produkce?

Stejné vzory se opakují: agenty s nadměrnými oprávněními, které stále běží na administračních pověřeních, se kterými byly prototypovány; pověření předávaná v podnětech nebo kontextových oknech, kde končí v protokolech, telemetrii a potenciálně v trénovacích datech; sdílená pověření napříč několika instancemi agentů, takže nemůžete izolovat jeden špatný aktér; žádný vypínač, aby se zastavil agent bez toho, aby se zastavil celý systém; žádná auditní stopa, která by stála za zmínku; a vkládání podnětů se nebere vážně – přestože každý agent, který čte e-maily, zpracovává dokumenty nebo prochází web, narazí na adversarially vytvořený obsah. Společný vlákno je, že tyto týmy postavily na šťastné cestě a nyní objevují, že produkce je většinou nešťastné cesty.

Jentic позициuje sám jako řízenou vrstvu provádění mezi rámci agentů a externími systémy. Jak tato mezilehlá vrstva vynucuje správu bez zpomalení vývojářů nebo snižování flexibility agentů?

Místo toho, aby agent propojil padesát různých API – každé s vlastním ověřovacím schématem, limity a vlastnostmi – vývojář se připojí k jednomu koncovému bodu. Ten koncový bod nabízí nástroje pro prohledání našeho celého katalogu API schopností, načtení detailů a provedení libovolného volání. To maximalizuje flexibilitu prostřednictvím jednotného sjednoceného rozhraní pro neomezená API, zatímco umožňuje správu – která agenta přistupuje k jakým API, za jakých podmínek, s jakými limity – vše spravované na platformě, ne v klientském kódu. Řízená vrstva je průchozí; agenti mohou stále skládat vícekrokové pracovní postupy, řetězit volání a zpracovávat chyby dynamicky. Správa bez tření je obtížná. Zkratka je přenést zátěž na vývojáře. Infrastruktura by měla dělat opak – absorbovat tu komplexitu, aby vývojáři nemuseli.

S infostealer malware cíleně zaměřeným na konfigurační soubory agentů a uložená pověření, vidíte útočníky, kteří mění svou pozornost na infrastrukturu umělé inteligence jako na novou vysokou hodnotu povrchu?

Absolutně – a logika je zřejmá. Konfigurační soubor agenta je efektivní multi-služební superklíč: pověření pro e-mailové systémy, CRM, fakturační platformy, interní API a GitHub účty. Jeden úspěšný běh infostealeru přináší měsíce přístupu napříč celou společností externích systémů. To je dramaticky vyšší návratnost než cílení na jakoukoli jednu službu izolovaně. Druhý rozměr je, že agenti běží neustále v produkci jsou trvalé, pověření přítomnosti – ne uživatel, který se přihlašuje a odhlašuje. Ohrožený agent může sloužit jako dlouhodobý útočiště, operující pod prahem detekce. Nepříjemná realita je, že útočný povrch se vyvíjí rychleji než obranné nástroje. Jentic může podstatně snížit povrch pověření útoků, ale nemůžeme zabránit agentovi v zneužití rozsahu, který mu byl udělen. Ten tvrdší problém musí být vyřešen na úrovni modelu, se zábranami a detekcí vkládání podnětů.

Mimo jakýkoli jeden rámec, jaké širší bezpečnostní zásady by organizace měly přijmout, pokud chtějí nasadit agenty umělé inteligence bezpečně ve velkém měřítku?

Většina spravovaných organizací nemůže nasadit nedeterministické systémy do svých nejcennějších obchodních procesů. Banka nebo pojišťovna nemohou ukázat autonomnímu agentovi na svůj fakturační systém a říci “jděte to vyřešit.” Jak tedy můžete inovovat bez toho, aby se vaše rizika stala brzdou? Odpověď je sandboxování. Vytvořte digitální dvojče vaší API majetku se stejnou strukturou a pracovními postupy, ale bez produkčních pověření nebo důsledků. Nasazení agentů tam, nechte je prozkoumat, sledujte, co se stane. Úspěšné cesty se zachycují jako strukturované, deterministické workflow automatizace pomocí Arazza, otevřené specifikace workflow vyvinuté v rámci OpenAPI Initiative – auditable, opakované a přezkoumatelné jakoukoli compliance týmem. To znamená, že můžete pohybovat se rychlostí umělé inteligence v sandboxu a rychlostí podniku v produkci, a ty dva režimy koexistují. Ostatní zásady stále platí – minimální práva, auditní stopy, vypínače, oddělení orchestrace od provádění. Ale sandbox je strukturální odpověď na otázku, na kterou se podnikové týmy skutečně zaseknou: jak experimentovat s nedeterministickou umělou inteligencí bez toho, aby se sázeli na svou compliance posturu? Nemusíte nasazovat nedeterminismus. Můžete extrahovat hodnotu z něj za kontrolovaných podmínek a nasazovat pouze deterministické výstupy.

Děkuji za skvělý rozhovor, čtenáři, kteří chtějí se dozvědět více, by měli navštívit Jentic.