Sean Blanchfield, Współzałożyciel i CEO Jentic – Wywiad

Sean Blanchfield, Współzałożyciel i CEO Jentic, jest doświadczonym przedsiębiorcą technologicznym z wieloletnim doświadczeniem w budowaniu firm zajmujących się oprogramowaniem i infrastrukturą na dużą skalę. Mając siedzibę w Dublinie, obecnie kieruje Jentic, a jednocześnie zasiada w Irlandzkiej Radzie Doradczej ds. Sztucznej Inteligencji, doradzając rządowi w zakresie polityki AI. Wcześniej w swojej karierze współtworzył DemonWare, platformę usług online na dużą skalę dla głównych wydawców gier wideo, która została później przejęta przez Activision Blizzard, oraz PageFair, startup wspierany przez venture capital, skupiony na analityce blokowania reklam, przejęty przez Blockthrough. Założył lub kierował także wieloma innymi startupami i nadal wspiera irlandzki ekosystem startupowy poprzez inicjatywy takie jak Techpreneurs. Jentic rozwija uniwersalną warstwę integracyjną zaprojektowaną, aby pomóc agentom AI w bezpiecznej interakcji z systemami przedsiębiorstw i interfejsami API. Platforma umożliwia organizacjom łączenie modeli AI z narzędziami wewnętrznymi, usługami zewnętrznymi i operacyjnymi przepływami pracy, przy jednoczesnym zachowaniu zarządzania, uwierzytelniania i nadzoru. Przekształcając rozproszone interfejsy API w ustrukturyzowane interfejsy, z których mogą niezawodnie korzystać agenci AI, Jentic ma na celu pomoc przedsiębiorstwom we wdrażaniu automatyzacji napędzanej AI na dużą skalę w złożonych środowiskach programowych. Zakładałeś i prowadziłeś wiele firm technologicznych, od DemonWare (przejętego przez Activision Blizzard) przez PageFair po obecnie Jentic, a także zasiadasz w Irlandzkiej Radzie Doradczej ds. AI. Co skłoniło cię do powrotu do budowania na poziomie infrastruktury z Jentic i jaką lukę dostrzegłeś w powstającym ekosystemie agentów AI, którą inni przeoczyli? Kiedy po raz trzeci zauważasz schemat, musisz potraktować go poważnie. W DemonWare wszyscy mówili o trybie wieloosobowym online – ale trudnym problemem była infrastruktura sieciowa pod spodem. To samo dzieje się z agentami AI. Modele są niezwykłe. Wąskim gardłem jest warstwa integracyjna – i zawsze nią była. Agenci AI działają na interfejsach API, a te interfejsy API były budowane dla ludzi: dokumentowane dla ludzi, zabezpieczane dla ludzi i strukturyzowane dla ludzi. Skieruj autonomicznego agenta na tę infrastrukturę, a szybko się rozpadnie. Pilotaże AI w przedsiębiorstwach nie kończą się niepowodzeniem, ponieważ model źle zrozumiał zadanie; kończą się niepowodzeniem, ponieważ agent nie mógł niezawodnie połączyć się z potrzebnymi systemami. Generatywna AI oferuje nowy sposób rozwiązania tego problemu – traktując integrację jako problem wiedzy, a nie problem kodowania. Ta właśnie myśl mnie przyciągnęła. Kiedy zakładałeś Jentic w 2024 roku, czy bezpieczeństwo agentów było główną tezą od pierwszego dnia, czy też skupienie wyostrzyło się, gdy obserwowałeś, jak organizacje faktycznie wdrażają autonomiczne agenty w środowisku produkcyjnym? Pierwszym wątkiem, za który pociągnąłem, były dane uwierzytelniające. Wyobrażałem sobie proliferację agentów, z których każdy potrzebowałby danych uwierzytelniających do dziesiątek systemów, wszystkie te sekrety trafiające do okien kontekstowych LLM, ulegające eksfiltracji – istny chaos. Odpowiedź jest taka sama, jak dwadzieścia lat temu: scentralizuj uwierzytelnianie i autoryzację. Ale pociągnięcie tego wątku prowadziło prosto do następnego problemu: jeśli scentralizujesz za pomocą tradycyjnych narzędzi integracyjnych, wracasz do krainy statycznych łączników, a agenci nie są statyczni. To, co utwierdziło mnie w wizji, to uświadomienie sobie, że wykrywanie możliwości powinno być ściśle powiązane z kontrolą dostępu – że agentowi powinna być oferowana możliwość tylko wtedy, gdy jest on faktycznie upoważniony do jej użycia, oraz że system zapewniający wykrywanie może być również jedynym punktem egzekwowania i obserwowalności. Ostatnie ujawnienie dużej liczby wystawionych na internet instancji agentów podkreśliło, jak często orkiestracja i dane uwierzytelniające dzielą tę samą granicę zaufania. Z twojej perspektywy, jaka jest podstawowa wada architektoniczna w tym modelu? Wada jest prosta: agent – system wykonujący prompty z LLM – jest jednocześnie systemem przechowującym dane uwierzytelniające i wykonującym wywołania API. Skompromituj agenta, a otrzymasz wszystko, co kiedykolwiek mógłby zrobić. To ten sam błąd, który popełnialiśmy we wczesnej erze sieci web – serwery aplikacji z dostępem superużytkownika do bazy danych, bo było to wygodne. Jentic działa jako warstwa między agentem a interfejsami API, które wywołuje. Agent nigdy nie posiada danych uwierzytelniających. Wystawia żądania przez naszą zarządzaną warstwę wykonawczą, która wstrzykuje dane uwierzytelniające po stronie serwera, egzekwuje polityki i loguje każde wywołanie. A gdy coś pójdzie nie tak, istnieje pojedynczy wyłącznik awaryjny – jedna akcja zatrzymuje dostęp tego agenta we wszystkich podłączonych systemach jednocześnie. Mówiłeś o oddzieleniu orkiestracji od wykonania, aby ograniczyć promień rażenia. Czy możesz wyjaśnić w praktycznych terminach, jak to rozdzielenie zmienia profil ryzyka, gdy instancja zostanie naruszona? W płaskim modelu LLM rozważa, co zrobić, i bezpośrednio wywołuje interfejsy API, używając posiadanych danych uwierzytelniających. Skompromituj warstwę rozumowania, a kontrolujesz warstwę wykonawczą. Przy rozdzieleniu, LLM emituje intencję – “wywołaj interfejs API rozliczeniowy Stripe z tymi parametrami” – zarządzana warstwa wykonawcza weryfikuje to żądanie względem polityk, wstrzykuje dane uwierzytelniające po stronie serwera i wykonuje wywołanie. LLM nigdy nie dotyka danych uwierzytelniających. W praktyce: ruch boczny staje się znacznie trudniejszy, promień rażenia jest ograniczony przez to, co warstwa wykonawcza zezwala dla tej konkretnej tożsamości agenta, i otrzymujesz wyłącznik awaryjny. Jeden przełącznik i dostęp agenta zatrzymuje się we wszystkich podłączonych systemach. Agentem nadal można manipulować – ale manipulacja nie oznacza już automatycznie pełnego kompromisu danych uwierzytelniających. W rzeczywistych wdrożeniach przedsiębiorstw, jak właściwie wygląda scentralizowane zarządzanie danymi uwierzytelniającymi i natychmiastowe odwołanie dostępu, i czym różni się to od tego, jak większość zespołów obecnie obsługuje klucze API i tokeny dla agentów? Obecnie większość zespołów ma dewelopera, który pozyskuje klucze API, przechowuje je w pliku .env i ładuje je przy uruchamianiu agenta – często bezpośrednio do okna kontekstowego LLM. Nikt nie ma pełnego obrazu tego, które agenty posiadają jakie dane uwierzytelniające. Gdy ktoś odchodzi, klucze, które pozyskał, nie są rotowane. Gdy agent zachowuje się dziwnie, nie ma śladu audytowego, aby odtworzyć, co się stało. W Jentic deweloper nigdy nie obsługuje surowych danych uwierzytelniających. Deklaruje, jakiego dostępu potrzebuje agent, platforma udostępnia zakresowy dostęp, a agent wywołuje przez naszą warstwę wykonawczą, nigdy nie widząc podstawowego klucza. Oznacza to, że otrzymujesz natychmiastowe odwołanie dostępu na agenta, możliwość wstrzymania dostępu podczas dochodzenia oraz ślad audytowy z sygnaturą czasową każdego wywołania API. Różnica między tym a “kluczem API w pliku .env” jest znacząca. Wiele zespołów eksperymentuje z frameworkami agentów w obszarach sprzedaży, inżynierii i data science. Jakie są najczęstsze błędy w zakresie bezpieczeństwa, które obserwujesz, gdy organizacje przechodzą od eksperymentów do produkcji? Powtarzają się te same schematy: naduprzywilejowani agenci nadal działający na danych uwierzytelniających administratora, z którymi byli prototypowani; dane uwierzytelniające przekazywane w promptach lub oknach kontekstowych, gdzie trafiają do logów, telemetrii i potencjalnie danych treningowych; współdzielone dane uwierzytelniające między wieloma instancjami agentów, więc nie można wyizolować pojedynczego złego aktora; brak wyłącznika awaryjnego, aby zatrzymać agenta bez wyłączania szerszego systemu; brak porządnego śladu audytowego; oraz brak poważnego traktowania iniekcji promptów – mimo że każdy agent, który czyta e-maile, przetwarza dokumenty lub przegląda sieć, napotka treści stworzone w sposób wrogi. Wspólnym wątkiem jest to, że te zespoły budowały pod ścieżkę sukcesu i teraz odkrywają, że produkcja to głównie ścieżki niepowodzeń. Jentic pozycjonuje się jako zarządzana warstwa wykonawcza znajdująca się między frameworkami agentów a systemami zewnętrznymi. W jaki sposób ta warstwa pośrednia egzekwuje zarządzanie bez spowalniania deweloperów lub ograniczania elastyczności agentów? Zamiast podłączać agenta do pięćdziesięciu różnych interfejsów API – każdy z własnym schematem uwierzytelniania, limitami szybkości i osobliwościami – deweloper łączy się z jednym punktem końcowym. Ten punkt końcowy udostępnia narzędzia do przeszukiwania całego naszego katalogu możliwości API, ładowania szczegółów i wykonywania dowolnych wywołań. Maksymalizuje to elastyczność poprzez jeden ujednolicony interfejs do nieograniczonej liczby interfejsów API, jednocześnie umożliwiając zarządzanie – które agenty mają dostęp do których interfejsów API, pod jakimi warunkami, z jakimi limitami – wszystko zarządzane w platformie, a nie w kodzie klienta. Warstwa wykonawcza jest przepustką; agenci nadal mogą komponować wieloetapowe przepływy pracy, łączyć wywołania i dynamicznie obsługiwać błędy. Zarządzanie bez tarcia jest trudne. Skrótem jest przerzucenie ciężaru na deweloperów. Infrastruktura powinna robić odwrotnie — absorbować tę złożoność, aby deweloperzy nie musieli. Ponieważ złośliwe oprogramowanie typu infostealer aktywnie atakuje teraz pliki konfiguracyjne agentów i przechowywane dane uwierzytelniające, czy uważasz, że atakujący przesuwają swoją uwagę w kierunku infrastruktury AI jako nowej, wysokowartościowej powierzchni ataku? Absolutnie – a logika jest oczywista. Plik konfiguracyjny agenta to w efekcie superklucz do wielu usług: dane uwierzytelniające do systemów e-mail, CRM, platform rozliczeniowych, wewnętrznych interfejsów API i kont GitHub. Pojedynczy udany atak infostealerem daje miesiące dostępu do wszystkich zewnętrznych systemów firmy. To znacznie wyższy zwrot niż atakowanie jakiejkolwiek pojedynczej usługi w izolacji. Innym wymiarem jest to, że agenci działający nieprzerwanie w produkcji są trwałymi, uwierzytelnionymi obecnościami — a nie użytkownikiem logującym się i wylogowującym. Skompromitowany agent może służyć jako długoterminowa przyczółka, działając poniżej progów wykrywania. Niewygodna rzeczywistość jest taka, że powierzchnia ataku ewoluuje szybciej niż narzędzia obronne. Jentic może znacząco zmniejszyć powierzchnię ataku na dane uwierzytelniające, ale nie możemy zapobiec niewłaściwemu wykorzystaniu zakresów, które zostały przyznane agentowi. Ten trudniejszy problem musi zostać rozwiązany na poziomie modelu, za pomocą zabezpieczeń i wykrywania iniekcji promptów. Poza jakimkolwiek pojedynczym frameworkiem, jakie szersze zasady bezpieczeństwa powinny przyjąć organizacje, jeśli chcą bezpiecznie wdrażać agentową AI na dużą skalę? Większość zarządzanych organizacji nie może wdrażać systemów niedeterministycznych w swoich najcenniejszych procesach biznesowych. Bank lub ubezpieczyciel nie może skierować autonomicznego agenta na swój system rozliczeniowy i powiedzieć “idź i się domyśl”. Jak więc wprowadzać innowacje, bez tego, aby postawa wobec ryzyka stała się hamulcem? Odpowiedzią jest piaskownica. Stwórz cyfrowego bliźniaka swojego zestawu interfejsów API z tą samą strukturą i przepływami pracy, ale bez produkcyjnych danych uwierzytelniających lub konsekwencji. Wdrażaj tam agentów, pozwól im eksplorować, obserwuj, co się dzieje. Udane ścieżki są przechwytywane jako ustrukturyzowane, deterministyczne automatyzacje przepływów pracy przy użyciu Arazzo, otwartej specyfikacji przepływu pracy opracowanej w ramach OpenAPI Initiative – podlegające audytowi, powtarzalne i możliwe do przejrzenia przez każdy zespół compliance. Oznacza to, że możesz poruszać się z prędkością AI w piaskownicy i z prędkością przedsiębiorstwa w produkcji, a te dwa tryby współistnieją. Inne zasady nadal obowiązują – najmniejsze uprawnienia, ślady audytowe, wyłączniki awaryjne, oddzielenie orkiestracji od wykonania. Ale piaskownica jest strukturalną odpowiedzią na pytanie, na którym faktycznie utykają zespoły przedsiębiorstw: jak eksperymentować z niedeterministyczną AI, nie stawiając na szali naszej postawy compliance? Nie wdrażasz niedeterminizmu. Czerpiesz z