Micha Rave, генеральный директор и соучредитель Hush Security — серия интервью

Micha Rave, генеральный директор и соучредитель Hush Security, является опытным руководителем в сфере кибербезопасности и технологий, чья карьера охватывает разработку программного обеспечения, управление продуктами, корпоративные сети, облачную безопасность и идентификацию. До основания Hush Security в 2024 году он более пяти лет работал в Proofpoint в качестве старшего директора по управлению продуктами облачной безопасности, где отвечал за продуктовые линейки Zero Trust Network Access (ZTNA) и Secure Web Gateway (SWG). Ранее он занимал пост вице‑президента по управлению продуктами в Meta Networks, сосредотачивая внимание на корпоративных сетях и безопасности, а также занимал руководящие позиции в области продукта и инженерии в HARMAN International, Redbend, SanDisk, Hola, Jungo и Elbit Systems. Его опыт сочетает практическую разработку программного обеспечения с более чем двадцатилетним опытом создания и коммерциализации продуктов в области безопасности, сетей, виртуализации и встроенных технологий.

Hush Security — компания в сфере кибербезопасности, сосредоточенная на защите AI‑агентов и других не‑человеческих идентичностей путём замены долговечных учётных данных и статических секретов доступом, управляемым политиками на основе идентичности. Платформа обнаруживает AI‑агентов, включая теневых и внутренне разработанных, присваивает им проверяемые идентичности и регулирует их взаимодействие с корпоративными системами с помощью ограниченных, выдаваемых «just in time» прав, централизованных политик и аудируемых записей активности. Компания была основана ветеранами безопасности из команды, стоявшей за Meta Networks, которую Proofpoint приобрёл в 2019 году. В июле 2026 года Hush привлекла $30 млн в рамках серии A, при этом Akamai Technologies стал стратегическим инвестором вместе с Battery Ventures и YL Ventures, доведя общий объём финансирования до $41 млн, поскольку компания расширяет технологию управления корпоративными AI‑агентами и не‑человеческой инфраструктурой.

Прежде чем основать Hush Security, вы много лет разрабатывали и руководили продуктами безопасности, включая облачную безопасность в Proofpoint. Что вы увидели на рынке, что убедило вас в необходимости создания Hush, и как изначальная гипотеза изменилась с быстрым ростом агентного ИИ?

В Proofpoint мы наблюдали, как предприятия решали задачи человеческой идентификации, в то время как всё не‑человеческое по‑прежнему работало на статических секретах. Сервисные аккаунты, рабочие нагрузки, конвейеры — все аутентифицировались с помощью ключей, которым никто не владел и которые никто не отзывал. Индустрия ответила лучшими хранилищами. Это более надёжный сейф, а не решение.

Основная гипотеза основания заключалась в переходе доступа не‑человеческих сущностей от секретов к идентичности. Проверяемая идентичность рабочих нагрузок, краткоживущие учётные данные, выдаваемые «just in time», политика, применяемая непосредственно в процессе. Без переписывания кода.

Агентный ИИ сделал это срочным. Агент — это NHI, который в режиме выполнения рассуждает и решает, какие инструменты вызвать. Если дать ему статический ключ, вы предоставляете автономному программному обеспечению постоянный доступ к продакшн‑среде, а агенты поставляются вне любого процесса изменения: разработчик настраивает сервер MCP во вторник, а к пятнице он уже работает с данными клиентов.

Гипотеза не изменилась. Изменилась область применения. Доступ, основанный на идентичности, был правильным решением для рабочих нагрузок. Для агентов это единственное работоспособное решение: знать каждого существующего агента, по умолчанию предоставлять каждому минимальную агентность и фиксировать каждое действие. У людей есть IdP. Агентам тоже нужен такой сервис, и это Hush.

Hush утверждает, что корпоративные AI‑агенты должны иметь собственные идентичности и делегированные разрешения, а не просто наследовать права доступа людей, которые их используют. Почему традиционные системы управления идентификацией и доступом (IAM) испытывают трудности с автономными агентами, и что необходимо изменить?

Очевидный случай — агент, действующий от имени пользователя. Сложнее — агент без какого‑либо пользователя: запланированная задача, автономный реагент SOC, конвейер, который самостоятельно рассуждает и действует. Нет никого, от кого можно делегировать, поэтому команды прибегают к единственному доступному им инструменту — статическому сервисному аккаунту с широкими правами и ключу, который никогда не истекает. Это та же модель общих секретов, которая ломается уже десятилетие, теперь привязанная к программному обеспечению, импровизирующему в работе.

Системы на другом конце лишь усугубляют ситуацию. Большинство внутренних API, баз данных и серверов MCP не осуществляют реальную авторизацию. Они проверяют, есть ли у вас действительный токен, а не какие действия вам разрешено выполнять. Наличие токена приравнивается к разрешению.

Что необходимо изменить: каждому агенту должна быть присвоена собственная идентичность, криптографически выданная, независимо от наличия человека. Доступ предоставляется по действию, краткоживущий и ограниченный областью, с политикой, применяемой непосредственно, а не доверяемой целевой системе. Когда есть пользователь, разрешения агента являются пересечением того, что может пользователь, и того, что агент может выполнять для конкретной задачи. Когда пользователя нет, единственной основой являются собственная идентичность агента и его политика. У людей есть принцип наименьших привилегий. Агентам нужен принцип наименьшей агентности.

Вы используете концепцию «наименьшей агентности», обсуждая безопасность ИИ. Чем наименьшая агентность отличается от традиционного принципа кибербезопасности «наименьших привилегий», и как организации могут точно определить, что AI‑агенту разрешено делать для конкретной задачи?

У агентов нет фиксированного поведения. Если дать одному доступ на чтение к CRM и право записи в электронную почту, вы не предоставляете два отдельных разрешения, а открываете все возможные пути между ними. Принцип наименьших привилегий ограничивает то, к чему агент может получить доступ. Он ничего не говорит о том, что агент должен делать с этим доступом.

Least agency добавляет недостающую измерение: какие действия, для какой задачи, прямо сейчас. Агент, обрабатывающий тикеты, должен уметь читать и комментировать. Ему не нужно закрывать, удалять или трогать биллинг, даже если токен позволяет это. Когда задача заканчивается, заканчивается и доступ.

Определение того, что разрешено, начинается с наблюдения, а не с догадок. Запустите агента, посмотрите, что он действительно вызывает, и позвольте этому стать базовым уровнем. Затем сузьте область, используя три входных параметра: задачу, для которой он существует, пользователя, от имени которого он действует (никогда не более того, что может сделать пользователь), и радиус воздействия каждого действия, потому что размещение комментария и проведение платежа не должны делиться одним путём одобрения.

Least privilege определяет, кто получает ключи. Least agency решает, что они могут делать, находясь внутри.

Мы часто «одалживаем» нашу личность агенту, но не хотим, чтобы агент имел тот же уровень разрешений, что и мы — это и есть определение least agency.

Hush недавно привлек раунд серии A на 30 млн долларов, доведя общий объём финансирования до $41 million, при этом Akamai присоединилась в качестве стратегического инвестора вместе с Battery Ventures и YL Ventures. Что участие Akamai приносит помимо капитала, и как вы ожидаете, что партнёрство повлияет на расширение Hush в сфере безопасности AI‑агентов для предприятий?

Akamai находится в пути трафика большинства мировых предприятий, и именно там должна работать безопасность агентов. Вы не управляете агентом из панели управления после того, как событие уже произошло. Вы управляете им в режиме inline, в момент, когда он вызывает инструмент или API. Akamai построила свой бизнес на этой модели.

Помимо капитала они приносят три вещи: распространение среди CISO, уже задающихся вопросом, как контролировать агентов и трафик MCP; подтверждение того, что идентичность агента — реальная категория, а не просто функция; и десятилетия опыта в защите машинного трафика в глобальном масштабе, которым и будет становиться трафик агент‑инструмент.

Model Context Protocol (MCP) быстро становится важным слоем для соединения AI‑агентов с инструментами и корпоративными данными. С точки зрения безопасности, какие новые риски вводит MCP и как организациям следует рассматривать идентичность и авторизацию между агентом, сервером MCP и базовым ресурсом?

MCP упростил подключение агента к инструменту. В этом и заключается риск. Разработчик добавляет сервер в файл конфигурации, и модель теперь может читать Jira, выполнять запросы к базе данных или отправлять электронную почту. Без проверки, без инвентаризации, без политики. О безопасности узнают только когда что‑то ломается.

Сейчас появились три новых проблемы:

1. Shadow MCP — никто не знает, сколько серверов работает и к чему они имеют доступ.
2. Разрастание учётных данных — большинство серверов аутентифицируются статическим токеном, который открывает весь спектр возможностей, поэтому агент получает всё, что может токен.
3. Схлопнутая цепочка — ресурс видит только учётные данные сервера MCP, поэтому не может определить, какой агент и от имени какого пользователя сделал запрос. Идентичность должна находиться в основе каждого взаимодействия, доступ должен быть временным, ограниченным и основанным на разрешениях агента и пользователя.

Hush изначально был построен вокруг идеи, что статические секреты и долгоживущие учётные данные являются сломанным фундаментом для машинного доступа. Поскольку большинство корпоративных инфраструктур всё ещё сильно полагаются на API‑ключи, токены и другие секреты, как компании могут реально перейти к основанному на идентичности, краткоживущему доступу без полной перестройки технологического стека?

Вы не перестраиваете. Никто, кто утверждает обратное, не сталкивался с реальными предприятиями. Большая часть того, что мы защищаем, предшествует термину «нечеловеческая идентичность», и её не переписывают.

Поэтому мы не требуем этого. Hush развёртывается без изменений кода и находится в пути доступа. Первый шаг — обнаружение: каждый секрет, кто его использует, к чему он приводит, что он действительно делает во время выполнения. Большинство компаний никогда не видели такой картины.

Затем это путешествие, а не миграция. Обнаружение показывает, какие секреты мертвы, избыточны или представляют наибольший риск. Сначала исправьте их. Затем заменяйте статические ключи на краткоживущие, выданные по идентичности, по одной системе за раз. Приложение всё ещё считает, что использует ключ. Ключ просто перестаёт быть долгоживущим, а политика переходит к нам.

Та же модель охватывает пятнадцатилетний Java‑сервис и сервер MCP, запущенный на прошлой неделе. Начинайте там, где риск выше всего, докажите эффективность, двигайтесь дальше.

AI‑агенты всё чаще будут работать от имени людей и, во многих случаях, делегировать задачи другим агентам. По мере усложнения таких многопользовательских рабочих процессов, как поддерживать чёткую цепочку идентичности, авторизации, владения и ответственности за каждое действие?

Сценарий отказа: пользователь обращается к оркестратору, тот делегирует задачу второму агенту, который вызывает инструмент через сервер MCP, который обращается к базе данных с учётной записью сервиса. Через четыре перехода журнал показывает лишь один элемент — действительный токен. Кто запросил, кто принял решение и кто несёт ответственность, исчезают.

Решение — не позволять идентичности схлопываться на любом этапе. Каждый агент имеет собственную криптографическую идентичность. При делегировании он не передаёт свой токен. Он выдаёт ограниченную делегацию: этот суб‑агент, эта задача, эти действия от имени этого пользователя. Каждый переход несёт полную цепочку и свои собственные разрешения.

Ответственность возникает благодаря принудительному применению и журналированию в режиме встроенного выполнения, в точке действия. Запись шлюза о том, что ему было разрешено делать, какие вызовы он делал и цепочке, стоящей за этим.

Системам с несколькими агентами будет всё труднее поддавать их разумному анализу. Цепочка ответственности за каждое действие не обязана быть простой.

Внедрение подсказок и другие атаки могут потенциально заставить легитимного AI‑агента выполнять действия, которых оператор никогда не намеревался. Насколько контроль доступа, основанный на идентичности, может ограничить ущерб от скомпрометированного или манипулируемого агента, даже если базовая модель ИИ работает некорректно?

Остановить внедрение подсказок на уровне модели не получится. Модели по замыслу читают недоверенный контент. Предположим, что агент в конечном итоге будет убеждён выполнить что‑то неправильное. Вопрос в том, что он сможет сделать в такой ситуации.

Контроль доступа, основанный на идентичности, ограничивает радиус поражения. Манипулируемый агент с минимальными полномочиями может злоупотреблять только теми действиями, которые ему предоставлены для конкретной задачи. Если он может читать тикеты и оставлять комментарии, никакое внедрение не заставит его вытянуть базу данных клиентов. У токена нет такого охвата.

Атрибуция пользователя сохраняет цепочку целостной: какой пользователь, какой агент, какая задача, на каждом вызове. Агент никогда не превышает того, что может пользователь, и каждое действие можно отследить обратно.

Обнаружение аномалий улавливает то, что разрешено политикой, но не соответствует намерению. Агент, который обычно читает пять записей, а вдруг запрашивает пять тысяч, выходит из привычного поведения, даже если каждый вызов авторизован. Поскольку шлюз работает в режиме inline и знает базовый уровень, он может в реальном времени пометить или заблокировать такое действие.

Модель будет ошибаться время от времени. Ограниченная идентичность, атрибуция и базовые модели поведения делают такие ошибки выживаемыми.

Hush в первую очередь сосредоточен на обеспечении безопасности ИИ, но как вы используете ИИ внутри самого Hush? Есть ли области, такие как обнаружение нечеловеческих идентичностей, анализ шаблонов доступа, приоритизация рисков или принудительное применение политик, где ИИ может существенно улучшить платформу безопасности?

Мы используем его там, где он заслуживает места.

В продукте сложность заключается не в поиске секретов, а в их понимании. Ключ появляется в трафике. Идентичность нагрузки, интеграция поставщика, токен тестовой разработки, мёртвая учётная запись? LLM читает контекст выполнения и сигналы владельца и предлагает ответ с оценкой уверенности. Он суммирует, что именно делает идентичность, простым человеческим языком, чтобы политику мог одобрить человек. Он ранжирует риск по реальному охвату и радиусу поражения, а не по статической тяжести. Применение остаётся детерминированным. ИИ помогает писать политику — он не получает голос в режиме выполнения.

Внутри Hush агентное программирование изменило наш график. Функции, которые раньше занимали спринт, теперь занимают дни, и мы выпускаем интеграции с такой скоростью, которой команда Series A не могла бы позволить себе. LLMs triage запросов в поддержку, группируют корневые причины и выводят запросы клиентов для обсуждения дорожной карты. Наш собственный шлюз MCP стоит перед всем этим, помогая клиентам рассуждать и использовать NHI и агентный риск.

Hush сообщает, что несколько компаний из списка Fortune 500 уже используют её технологию, а Kyndryl внедрила Hush внутри компании и начала перепродавать её корпоративным клиентам. Чего вы узнаёте из этих масштабных внедрений о реальных проблемах управления, с которыми сталкиваются компании, когда AI‑агенты переходят от экспериментов к эксплуатации?

Никто не знает, что у него есть. Каждое крупное внедрение начинается одинаково: безопасность считает, что в продакшене десяток агентов, а обнаружение находит сотни, уже работающие с данными клиентов. Проблема управления — это не политика, а сначала инвентаризация.

Учётные данные хуже, чем сами агенты. Практически каждый агент в продакшене работает на статической сервисной учётной записи, существующей ещё до него, с правами, накопленными за годы для иных целей. У неё не было ограниченного доступа.

Отсутствует владение. Спросив, кто отвечает за агента или за NHI, вы получите в лучшем случае название команды, бывшего подрядчика или молчание.

И покупатель изменился. Это была проблема команды платформы. Теперь за это отвечает CISO, потому что совет директоров требует. Это перевело нас от пилотных проектов к масштабным корпоративным развертываниям, и именно поэтому Kyndryl внедрила технологию внутри компании перед перепродажей.

Агенты не создали новых проблем управления. Они взяли те, которые предприятия игнорировали в течение десятилетия с сервисными учётными записями, и усугубили их.

Спасибо за отличное интервью, читатели, желающие узнать больше, должны посетить Hush Security.