Harold Byun, CEO společnosti BlueRock – rozhovor

Harold Byun, CEO společnosti BlueRock, je zkušený manažer podnikového softwaru s hlubokými znalostmi v oblasti kybernetické bezpečnosti, platforem SaaS, cloudové bezpečnosti a vedení podnikových produktů. Předtím, než se stal CEO v dubnu 2026, působil jako hlavní produktový manažer společnosti, kde pomáhal formovat směr BlueRocku kolem agentic AI bezpečnosti a pozorovatelnosti. Předtím, než vstoupil do BlueRocku, Byun zastával seniorní manažerské pozice ve společnostech AppOmni, ServiceNow, Skyhigh Networks, Symantec a Citrix po akvizici Zenprise. V těchto rolích si vybudoval reputaci pomáhající podnikům zabezpečit stále složitější cloudové a datové prostředí, zkušenosti, které nyní přímo souvisejí s novými bezpečnostními výzvami okolo autonomních agentů AI a protokolu Model Context Protocol (MCP) ekosystémů.

BlueRock se zaměřuje na zabezpečení vrstvy provádění agentic AI systémů, oblast, která se stává stále kritičtější, protože podniky nasazují autonomní agenty AI schopné interagovat s nástroji, API, kódy a citlivými podnikovými daty. Společnost vyvíjí bezpečnostní a pozorovatelnostní technologie navržené pro monitorování, sandboxování a vynucování ochranných plotů kolem chování agentů AI, zejména v prostředí založeném na MCP. Platforma BlueRocku zdůrazňuje viditelnost a ochranu vrstvy provádění spíše než spoléhání se pouze na bezpečnost na úrovni promptů, což odráží širší průmyslový posun směrem k zabezpečení toho, jak agenty AI jednají, a not only co říkají. Když se organizace přesouvají z experimentování s AI směrem k autonomním pracovním postupům v produkci, společnosti jako BlueRock se umisťují do centra toho, co by se mohlo stát velkou novou kategorií v rámci podnikové kybernetické bezpečnosti.

Vy jste strávil roky v cloudu, SaaS, DLP a podnikové bezpečnosti ve společnostech jako AppOmni, Symantec, ServiceNow a Skyhigh Networks. Co vás přesvědčilo, že bezpečnost provádění pro agenty AI se stane další velkou bezpečnostní kategorií?

Co se mi stalo zjevným, je to, že AI mění, kde se skutečné provozní riziko a složitost skutečně vyskytují. V tradičním softwaru je většina chování definována před nasazením. V agentic systémech se chování stále více objevuje během provádění prostřednictvím promptů, kontextu, nástrojů, API, serverů MCP a následných interakcí.

To vytváří velmi odlišný provozní model. Jakmile mohou agenty dynamicky rozhodovat a provádět akce napříč systémy, organizace ztrácí jasnou viditelnost a provozní pochopení, na které se roky spoléhaly.

Jsem viděl podobné platformové posuny dříve v cloudu a SaaS bezpečnosti, kde infrastruktura se vyvíjela rychleji než systémy používané pro její správu. AI vytváří další jeden z těchto okamžiků. Dlouhodobá výzva není pouze bezpečnost modelu. Je to umožnění organizacím bezpečně provozovat agentic systémy v měřítku.

Kategorie, která nakonec bude záležet, je ta, která pomůže organizacím pochopit, co agenty skutečně dělají v produkci, a dá jim důvěru škálovat AI-nativní operace zodpovědně.

BlueRock mluví o „Agentic Execution Gap“, kde organizace ztrácí viditelnost, jakmile agenty začínají jednat autonomně během provádění. Proč tradiční nástroje pro pozorovatelnost a bezpečnost selhávají v těchto prostředích?

Tradiční nástroje pro pozorovatelnost a bezpečnost byly postaveny pro deterministické systémy s relativně předvídatelnými cestami provádění. Předpokládají, že vývojáři znají, jak aplikace mají fungovat předtím, než budou spuštěny.

Agentic systémy porušují toto předpoklad.

Agenty mohou dynamicky objevovat nástroje, vyvolávat servery MCP, řetězit pracovní postupy, interagovat s API a rozhodovat se v reálném čase. Cesta provádění se často objevuje během provádění.

Většina stávajícího nástrojování zachycuje fragmenty, jako jsou protokoly, stopy, telemetrie nebo výstupy modelů. Ale organizace stále více potřebují kauzální pochopení napříč celou cestou provádění: proč agent vybral nástroj, jaký kontext ovlivnil rozhodnutí, které systémy byly dotčeny a jaké akce se vyskytly jako výsledek.

To je Agentic Execution Gap. Provádění se stalo dynamickým, ale modely viditelnosti a kontroly se nevyvinuly spolu s ním.

Rostoucí počet podniků experimentuje s architekturami založenými na Model Context Protocol (MCP) a autonomními pracovními postupy AI. Jaké jsou největší bezpečnostní mýty, které organizace stále mají o serverech MCP a agentic systémech?

MCP se rychle stává základním infrastrukturou pro to, jak agenty AI objevují, připojují se k a interagují s nástroji, systémy a podnikovými daty.

Co dělá MCP důležité, je to, že dramaticky snižuje tření mezi systémy AI a provozními prostředími. Zvyšuje rychlost vývoje a odemyká powerful pracovní postupy, ale také dramaticky zvyšuje počet cest provádění, které agenty mohou vzít napříč podnikovými systémy.

V mnoha případech mohou organizace již mít nástroje AI interagující se službami připojenými k MCP, aniž by plně rozuměly provoznímu expozici, která je vytvářena.

Další mýtus je, že kontrola promptů nebo modelů je dostatečná. V praxi se větší rizika objevují po rozhodnutí modelu. Jakmile mohou agenty vyvolávat nástroje, provádět pracovní postupy, získávat citlivá data nebo interagovat s infrastrukturou, výzva se posouvá směrem k chování a kontrole provádění.

Provozní povrch se zvětšuje mnohem rychleji, než většina modelů governance a pozorovatelnosti byla navržena.

Výzkum BlueRocku odhalil vážné zranitelnosti napříč veřejnými servery MCP, včetně Server-Side Request Forgery (SSRF) a expozice injekce příkazů. Podceňují podniky, jak rychle by ekosystémy MCP mohly stát se novou útočnou plochou softwarového dodavatelského řetězce?

Ano. Domnívám se, že průmysl je stále na počátku porozumění, jak důležité může být ekosystém MCP z hlediska dodavatelského řetězce a provozní důvěry. Například z více než 11 000 serverů MCP, které jsme analyzovali, má více než 36 % neomezené zranitelnosti SSRF. Většina lidí v průmyslu nerozumí, že to efektivní otevře jejich celou síť z hlediska přístupu k datům. To by nikdy nebylo vědomě povoleno v téměř každém podnikovém prostředí na světě.

Historicky se organizace obávaly knihoven, kontejnerů a open source závislostí, protože tyto komponenty se staly součástí softwarového stacku před nasazením. MCP mění tento model. Agenty mohou nyní dynamicky objevovat a interagovat s externími nástroji a službami během provádění samotného. A ve многих případech vývojáři a podniky prostě šli vpřed a nasadili MCP, aniž by rozuměli nebo hodnotili rizika.

To vytváří velmi odlišný problém důvěry.

Organizace již nejsou pouze spravovány statické závislosti. Stále více spravují dynamické závislosti provádění, které se objevují, zatímco systémy běží. Agenty mohou vyvolávat nástroje, řetězit pracovní postupy nebo přistupovat k následným systémům způsoby, které operátoři plně nepředpokládají nebo nezaznamenávají.

Náš výzkum kolem SSRF, injekce příkazů a dalších zranitelností odráží, jak nezralé části ekosystému stále jsou. Ale větší problém je širší než jednotlivé zranitelnosti. Jakmile se adopce MCP zrychluje, organizace budou potřebovat mnohem hlubší viditelnost do toho, jak autonomní systémy interagují s externími službami během provádění.

Vaše platforma zdůrazňuje „agentic pozorovatelnost“ spíše než pouze monitorování promptů nebo výstupů. Co vlastně znamená smysluplná viditelnost provádění, jakmile agenty dělají dynamická rozhodnutí napříč nástroji, API a infrastrukturou?

Smysluplná viditelnost provádění vyžaduje pochopení celé cesty provádění, ne pouze izolovaných událostí.

Organizace potřebují vidět, jak rozhodnutí modelu se promění v akce napříč nástroji, servery MCP, API, infrastrukturou a následnými systémy. To znamená pochopit, proč agent vybral nástroj, jaký kontext ovlivnil rozhodnutí, jaké oprávnění byly použity, jaké následné akce byly spuštěny a jaký provozní výsledek byl nakonec vytvořen.

To se stává especialmente důležité, jakmile agenty operují napříč distribuovanými a efemérními prostředími, kde tradiční monitorování rychle fragmentuje.

Monitorování promptů samotných není dostatečné, protože prompty neobjasňují provozní chování. Výstupy nejsou dostatečné, protože neodhalují, které systémy byly ovlivněny následně.

Budoucnost pozorovatelnosti v agentic systémech je vědomá provádění. Je to o pochopení chování od rozhodnutí k akci k výsledku v reálném čase.

Motor důvěry BlueRocku zdá se, že připojuje identitu, důvěru a údaje o schopnostech přímo k tokům provádění v reálném čase. Jak důležité bude kontextuální důvěra, jakmile agenty AI stále více interagují s externími nástroji a systémy autonomně?

Kontextuální důvěra se stává základním prvkem v agentic systémech, protože agenty dělají dynamická rozhodnutí během provádění.

Tradiční systémy spoléhaly se silně na statické předpoklady důvěry. Ale agenty stále více operují napříč měnícími se kontexty, externími nástroji, API, servery MCP, identitami a oprávněními.

Organizace potřebují hodnotit důvěru kontinuálně během provádění samotného. Nejen zda je model bezpečný, ale zda je nástroj, který je vyvolán, důvěryhodný, zda požadovaná akce odpovídá očekávanému chování a jaké provozní riziko akce zavádí.

To je proč jsme přesvědčeni, že kontext důvěry se stává kritickou infrastrukturou pro příští generaci systémů AI.

Sledujeme rychlou adopci agentů AI pro kódování a autonomních pracovních postupů pro vývojáře. Jaká jsou nejvíce znepokojivé rizika, když agenty získávat schopnost modifikovat infrastrukturu, nasazovat kód nebo interagovat s produkčními systémy bez lidské revize?

Největší posun je, že organizace se snaží dramaticky zvýšit rychlost vývoje, aby umožnily daleko více lidí stavět s AI, nejen tradičním softwarovým inženýrům.

Agenty AI pro kódování mohou již generovat kód, modifikovat infrastrukturu, interagovat s CI/CD pipeline, vyvolávat cloudové služby a přistupovat k citlivým systémům. Produktivita je enormní, protože podniky mohou nyní odemknout jak zkušené vývojáře, tak novou generaci AI-nativních a občanů-developerů.

Výzva je, že provozní složitost roste stejně rychle. Obava není pouze škodlivá činnost. Je to nepříznivé dopady, které agent může mít, což způsobí výpadek produktu a ovlivní dostupnost dat a infrastruktury pro organizaci. Tento typ chování je podobný problému veřejných S3 bucketů z předchozích let. Očekáváme, že agenty budou fungovat. Očekáváme, že budou zavedeny ochranné ploty a kontroly. Ale existují cesty k neúmyslnému chování, nadměrným oprávněním, skrytým závislostem, nebezpečnému použití nástrojů nebo cestám provádění, které nikdo neočekával. A to povede k více výpadkům nebo sub-optimálním nasazením, kde lidé se stanou tlačítky a ROI nebude plně realizován.

Organizace potřebují provozní viditelnost a vědomé provádění kontrol, které se pohybují s pracovní zátěží, aby mohly bezpečně škálovat AI-nativní vývoj bez zpomalení inovace.

Mnohé organizace stále myslí na bezpečnost AI primárně skrze čočku bezpečnosti modelu a injekce promptů. Proč si myslíte, že průmysl nyní potřebuje posunout směrem k zabezpečení akcí a cest provádění?

Bezpečnost modelu a injekce promptů absolutně záleží, ale reprezentují pouze část výzvy.

Průmysl se pohybuje od systémů, které generují odpovědi, k systémům, které provádějí akce. Jakmile mohou agenty vyvolávat nástroje, modifikovat systémy, získávat citlivá data, provádět pracovní postupy nebo interagovat s infrastrukturou, provozní riziko se posouvá směrem k chování provádění samotného.

Dokonale sladěný model může stále vytvořit riziko, pokud vyvolá špatný nástroj, přistupuje k špatnému systému nebo spouští neúmyslné následné akce. To je proč zabezpečení promptů samotných je nedostatečné. A vždy budou nové přístupy, jak obejít tyto typy ochranných plotů. To bude neustálá hra kočky a myši.

Organizace potřebují rozpoznat, že tyto ochranné ploty budou obejity, a když budou, potenciální nepříznivé dopady jsou nejvyšší později v cestě provádění. Jako výsledek, stále více potřebují viditelnost a kontrolu napříč celou cestou provádění a provozním dopadem chování agenta v reálném čase.

Někteří výzkumníci srovnávali adopci MCP s tím, že AI systémy dostávají „univerzální USB port“ do podnikové infrastruktury. Jak by měly společnosti vyvážit enormní produktivitu agentů s provozními riziky, které zavádějí?

Produktivita je skutečná. MCP dramaticky zjednodušuje, jak agenty se připojují k nástrojům, systémům a pracovním postupům, což je jeden důvod, proč adopce zrychluje tak rychle.

Ale organizace by se měly vyvarovat myšlení o MCP čistě jako o vrstvě připojení. Efektivně se stává součástí provozní tkaniny podniku.

Rovnováha pochází z umožnění vývojářům a AI-nativním stavitelům pohybovat se rychle, zatímco zachovávají vědomou viditelnost a kontrolu.

To znamená pochopit bezpečnost implementace serveru MCP samotného, proč jsme postavili registr mcp-trust.com. A znamená to pochopit, se kterými servery MCP agenty interagují, jaké typy nástrojů tyto servery poskytují, jaké oprávnění jsou udělena a jak akce propagují během provádění.

Organizace, které uspějí, budou ty, které postaví provozní důvěru kolem autonomního provádění.

Pohledem do budoucna, jak vypadá zralý podnikový AI bezpečnostní stack v světě, kde autonomní agenty rutinně spolupracují, dělají rozhodnutí a provádějí úkoly napříč několika systémy v produkci?

Domnívám se, že zralý podnikový AI stack se stává mnohem více orientován na provádění.

Organizace stále budou potřebovat bezpečnost modelu, identitu, ochranu dat a infrastrukturu. Ale větší posun je, že podniky budou potřebovat provozní systémy navržené pro autonomní a nedeterministické softwarové systémy.

Jakmile agenty stále více spolupracují, dělají rozhodnutí a provádějí akce napříč nástroji, infrastrukturou a obchodními pracovními postupy, organizace budou potřebovat kontinuální viditelnost do toho, jak systémy AI skutečně fungují během provádění.

Budoucí stack bude kombinovat pozorovatelnost, kontext důvěry, provozní governance, vynucování zásad vědomého provádění, identitu a bezpečnost provádění do jednotné provozní vrstvy pro agentic systémy.

Organizace, které uspějí, budou ty, které mohou kontinuálně rozumět a operationalizovat autonomní provádění bez zpomalení inovace.

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