Интервью
Гарольд Бюн, генеральный директор BlueRock – Интервью

Гарольд Бюн, генеральный директор BlueRock, – ветеран корпоративных технологий с глубоким опытом в области кибербезопасности, платформ SaaS, облачной безопасности и корпоративного лидерства по продуктам. До того, как он стал генеральным директором в апреле 2026 года, он занимал должность главного офицера по продуктам, где он помог сформировать направление BlueRock в области агентной безопасности и наблюдаемости ИИ. До прихода в BlueRock Бюн занимал руководящие должности в AppOmni, ServiceNow (NOW ), Skyhigh Networks, Symantec и Citrix после приобретения Zenprise. На этих должностях он заслужил репутацию специалиста, помогающего корпорациям обеспечить безопасность все более сложных облачных и данных сред, опыт, который сейчас напрямую соответствует возникающим проблемам безопасности, связанным с автономными агентами ИИ и протоколом контекста модели (MCP) экосистем.
BlueRock фокусируется на обеспечении безопасности слоя выполнения агентных систем ИИ, области, которая становится все более критической, поскольку корпорации развертывают автономные агенты ИИ, способные взаимодействовать с инструментами, API, кодовыми базами и чувствительными корпоративными данными. Компания разрабатывает технологии безопасности и наблюдаемости, предназначенные для мониторинга, sandbox и обеспечения ограничений поведения агентов ИИ, особенно в средах на основе MCP. Платформа BlueRock подчеркивает видимость во время выполнения и защиту слоя выполнения, а не полагается исключительно на меры безопасности на уровне запросов, отражая более широкий сдвиг отрасли в сторону обеспечения безопасности того, как агенты ИИ действуют, а не только того, что они говорят. Когда организации переходят от экспериментов с ИИ к автономным рабочим процессам в производстве, компании, такие как BlueRock, позиционируют себя в центре того, что может стать значительной новой категорией в области корпоративной кибербезопасности.
Вы провели годы в облачных, SaaS, Data Loss Prevention (DLP) и корпоративных технологиях безопасности в компаниях, таких как AppOmni, Symantec, ServiceNow и Skyhigh Networks. Что убедило вас, что безопасность во время выполнения для агентов ИИ станет следующей крупной категорией безопасности?
Что стало очевидным для меня, так это то, что ИИ меняет, где фактически происходит значимый операционный риск и сложность. В традиционном программном обеспечении большинство поведения определяется до развертывания. В агентных системах поведение все чаще возникает во время выполнения через запросы, контекст, инструменты, API, серверы MCP и последующие взаимодействия.
Это создает очень другую операционную модель. Как только агенты могут принимать решения и совершать действия динамически через системы, организации теряют четкую видимость и операционное понимание, на которые они полагались в течение многих лет.
Я видел подобные сдвиги платформ раньше в облачной и SaaS-безопасности, где инфраструктура развивалась быстрее, чем системы, используемые для ее управления. ИИ создает еще один из таких моментов. Долгосрочная задача заключается не только в безопасности модели. Это обеспечение того, чтобы организации могли безопасно эксплуатировать агентные системы в масштабе.
Категория, которая в конечном итоге имеет значение, будет той, которая поможет организациям понять, что агенты фактически делают в производстве, и даст им уверенность в том, чтобы масштабировать операции, родные для ИИ, ответственно.
BlueRock говорит об “агентном пробеле выполнения”, где организации теряют видимость, как только агенты начинают действовать автономно во время выполнения. Почему традиционные инструменты наблюдаемости и безопасности не справляются в этих средах?
Традиционные инструменты наблюдаемости и безопасности были разработаны для детерминированных систем с относительно предсказуемыми путями выполнения. Они предполагают, что разработчики в основном знают, как приложения должны вести себя до их запуска.
Агентные системы нарушают это предположение.
Агенты могут динамически обнаруживать инструменты, вызывать серверы MCP, цепочить рабочие процессы, взаимодействовать с API и принимать решения в реальном времени. Путь выполнения часто возникает во время выполнения.
Большинство существующих инструментов захватывают фрагменты, такие как журналы, трассировки, телеметрия или выходные данные модели. Но организации все чаще нуждаются в причинно-следственном понимании на протяжении всего пути выполнения: почему агент выбрал инструмент, какой контекст повлиял на решение, какие системы были затронуты, и какие действия произошли в результате.
Это и есть агентный пробел выполнения. Выполнение стало динамичным, но модели видимости и контроля не эволюционировали вместе с ним.
Растущее число корпораций экспериментирует с архитектурами, основанными на протоколе контекста модели (MCP), и автономными рабочими процессами ИИ. Какие самые большие заблуждения о безопасности MCP-серверов и агентных систем все еще существуют в организациях?
MCP быстро становится фундаментальной инфраструктурой для того, как агенты ИИ обнаруживают, подключаются и взаимодействуют с инструментами, системами и корпоративными данными.
Что делает MCP важным, так это то, что он значительно снижает трение между системами ИИ и операционными средами. Он увеличивает скорость разработки и разблокирует мощные рабочие процессы, но он также массово расширяет количество путей выполнения, которые агенты могут пройти через корпоративные системы.
В многих случаях организации могут уже иметь инструменты ИИ, взаимодействующие с сервисами, подключенными к MCP, не полностью понимая операционную уязвимость, создаваемую.
Другое заблуждение заключается в том, что контроль над запросами или моделями является достаточным. На практике более крупные риски возникают после того, как модель принимает решение. Как только агенты могут вызывать инструменты, выполнять рабочие процессы, извлекать чувствительные данные или взаимодействовать с инфраструктурой, задача смещается в сторону поведения во время выполнения и контроля над выполнением.
Операционная поверхность растет намного быстрее, чем большинство моделей управления и наблюдаемости были разработаны для обработки.
Исследование BlueRock показало серьезные уязвимости на публичных серверах MCP, включая уязвимости SSRF и внедрение команд. Неужели корпорации недооценивают, насколько быстро экосистемы MCP могут стать новой поверхностью атаки цепочки поставок программного обеспечения?
Да. Я думаю, что отрасль все еще находится на ранней стадии понимания того, насколько важным может стать экосистема MCP с точки зрения цепочки поставок и операционного доверия. Например, более 36% из 11 000 серверов MCP, которые мы проанализировали, имеют уязвимости SSRF без ограничений. Большинство людей в отрасли не понимают, что это фактически открывает их整个 сеть с точки зрения доступа к данным. Это никогда не было бы намеренно разрешено в几乎 любой корпоративной среде в мире сегодня.
Исторически корпорации беспокоились о библиотеках, контейнерах и открытых исходных кодах, потому что эти компоненты стали частью стека программного обеспечения до развертывания. MCP меняет эту модель. Агенты могут теперь динамически обнаруживать и взаимодействовать с внешними инструментами и сервисами во время выполнения. И в многих случаях разработчики и бизнес просто перешли вперед и развернули MCP, не понимая или не оценивая рисков.
Это создает очень другую проблему доверия.
Организации больше не управляют только статическими зависимостями. Они все чаще управляют динамическими зависимостями выполнения, которые возникают, пока системы работают. Агенты могут вызывать инструменты, цепочить рабочие процессы или получать доступ к последующим системам способами, которые операторы не полностью предвидят или наблюдают.
Наше исследование вокруг SSRF, внедрения команд и других уязвимостей отражает, насколько еще незрелыми являются части экосистемы. Но более крупная проблема шире, чем отдельные уязвимости. Когда принятие MCP ускоряется, организации будут нуждаться в гораздо более глубоком понимании того, как автономные системы взаимодействуют с внешними сервисами во время выполнения.
Ваша платформа подчеркивает “агентную наблюдаемость” вместо простого мониторинга запросов или выходных данных. Что такое осмысленная видимость во время выполнения, когда агенты принимают динамические решения через инструменты, API и инфраструктуру?
Осмысленная видимость во время выполнения требует понимания полного пути выполнения, а не только изолированных событий.
Организации должны видеть, как решение модели превращается в действия через инструменты, серверы MCP, API, инфраструктуру и последующие системы. Это означает понимание, почему агент выбрал инструмент, какой контекст повлиял на решение, какие разрешения были использованы, какие действия были вызваны, и какой операционный результат был в конечном итоге создан.
Это становится особенно важным, когда агенты работают в распределенных и эфемерных средах, где традиционный мониторинг быстро фрагментируется.
Мониторинг запросов alone не достаточно, потому что запросы не объясняют операционное поведение. Выходные данные не достаточно, потому что они не раскрывают, какие системы были затронуты.
Будущее наблюдаемости в агентных системах является осведомленным о выполнении. Это о понимании поведения от решения к действию к результату в реальном времени.
Двигатель доверия BlueRock, по-видимому, прикрепляет данные идентификатора, доверия и возможностей直接 к потокам выполнения в реальном времени. Насколько важно будет контекстное доверие, когда агенты ИИ все чаще взаимодействуют с внешними инструментами и системами автономно?
Контекстное доверие становится фундаментальным в агентных системах, потому что агенты принимают решения динамически во время выполнения.
Традиционные системы сильно полагались на статические предположения о доверии. Но агенты все чаще работают в меняющихся контекстах, внешних инструментах, API, серверах MCP, идентификаторах и разрешениях.
Организации должны оценивать доверие непрерывно во время выполнения. Не только безопасна ли модель, но и является ли вызываемый инструмент доверенным, соответствует ли запрошенное действие ожидаемому поведению, и какой операционный риск вводит действие.
Это почему мы считаем, что контекст доверия становится критической инфраструктурой для следующего поколения систем ИИ.
Мы наблюдаем быстрое принятие агентов кодирования ИИ и автономных рабочих процессов разработки. Какие наиболее тревожные риски, когда агенты получают возможность изменять инфраструктуру, развертывать код или взаимодействовать с производственными системами без человеческого обзора?
Самый большой сдвиг заключается в том, что организации пытаются значительно увеличить скорость разработки, позволяя гораздо большему количеству людей строить с помощью ИИ, а не только традиционных инженеров-программистов.
Агенты кодирования ИИ могут уже генерировать код, изменять инфраструктуру, взаимодействовать с конвейерами CI/CD, вызывать облачные сервисы и получать доступ к чувствительным системам. Продуктивность очень высока, потому что корпорации могут теперь разблокировать как опытных разработчиков, так и новое поколение разработчиков, родных для ИИ и гражданских разработчиков.
Задача заключается в том, что операционная сложность растет так же быстро. Забота не только в злонамеренном поведении. Это нежелательное воздействие, которое агент может оказать, что вызывает сбои в работе продукта и влияет на доступность данных и инфраструктуры для организации. Это tipo поведения вне контроля. Мы ожидаем, что агенты будут вести себя. Мы ожидаем, что будут установлены ограничители и проверки. Но есть пути к непредвиденному поведению, чрезмерным разрешениям, скрытым зависимостям, небезопасному использованию инструментов или путям выполнения, которые никто не предвидел. И это приведет к большему количеству сбоев или субоптимальных развертываний, где люди становятся кнопочными толкателями, и ROI не реализуется полностью.
Организации нуждаются в операционной видимости и осведомленности о выполнении контроля, которые перемещаются с рабочей нагрузкой, чтобы они могли безопасно масштабировать разработку, родную для ИИ, без замедления инноваций.
Многие организации все еще думают о безопасности ИИ в первую очередь через призму безопасности модели и инъекции запроса. Почему вы считаете, что отрасль теперь должна сместиться в сторону обеспечения безопасности действий и путей выполнения?
Безопасность модели и инъекция запроса абсолютно важны, но они представляют только часть задачи.
Отрасль переходит от систем, которые генерируют ответы, к системам, которые принимают действия. Как только агенты могут вызывать инструменты, изменять системы, извлекать чувствительные данные или взаимодействовать с инфраструктурой, операционный риск смещается в сторону поведения во время выполнения.
Идеально согласованная модель может все равно создать риск, если она вызывает неправильный инструмент, получает доступ к неправильной системе или вызывает непредвиденные последующие действия. Это почему обеспечение безопасности только запросов является недостаточным. И всегда будут новые подходы к обходу этих типов ограничений запросов. Это будет постоянной игрой в кошки-мышки.
Организации должны признать, что эти ограничения будут обходиться, и когда они будут обходиться, потенциальное негативное воздействие будет самым высоким позже в пути выполнения. Следовательно, они все чаще нуждаются в видимости и контроле на протяжении всего пути выполнения и операционного воздействия поведения агента в реальном времени.
Некоторые исследователи сравнивают принятие MCP с предоставлением системам ИИ “универсального USB-порта” в корпоративную инфраструктуру. Как компании должны сбалансировать огромную продуктивность агентов, подключенных к сети, с операционными рисками, которые они вводят?
Продуктивность очень высока. MCP значительно упрощает, как агенты подключаются к инструментам, системам и рабочим процессам, что является одной из причин, почему принятие ускоряется так быстро.
Но организации должны избегать мышления о MCP исключительно как о слое подключения. Он фактически становится частью операционной ткани предприятия.
Баланс возникает из-за того, что разработчики и строители, родные для ИИ, могут двигаться быстро, сохраняя при этом осведомленность о выполнении и контроль.
Это означает понимание безопасности реализации сервера MCP, что является причиной, по которой мы построили реестр mcp-trust.com. И это означает понимание, какие серверы MCP агенты взаимодействуют, какие типы инструментов эти серверы открывают, какие разрешения предоставляются и как действия распространяются во время выполнения.
Организации, которые преуспеют, будут теми, которые построили операционное доверие вокруг автономного выполнения.
Глядя вперед, какой вид имеет зрелый стек безопасности ИИ корпоративного уровня в мире, где автономные агенты регулярно сотрудничают, принимают решения и выполняют задачи через несколько систем в производстве?
Я думаю, что зрелый стек безопасности ИИ корпоративного уровня становится гораздо более ориентированным на выполнение.
Организации все еще будут нуждаться в безопасности модели, идентификаторе, защите данных и безопасности инфраструктуры. Но более крупный сдвиг заключается в том, что предприятия будут нуждаться в операционных системах, разработанных для автономного и недетерминированного программного обеспечения.
Когда агенты все чаще сотрудничают, принимают решения и выполняют действия через инструменты, инфраструктуру и бизнес-рабочие процессы, организации будут нуждаться в непрерывной видимости того, как системы ИИ фактически ведут себя во время выполнения.
Будущий стек будет объединять наблюдаемость, контекст доверия, операционное управление, обеспечение политики, осведомленное о выполнении, идентификатор и безопасность во время выполнения в едином операционном слое для агентных систем.
Организации, которые преуспеют, будут теми, которые могут непрерывно понимать и операционализировать автономное выполнение без замедления инноваций.
Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить BlueRock.












