Шон Бланчфилд, сооснователь и генеральный директор Jentic – Интервью

Шон Бланчфилд, сооснователь и генеральный директор Jentic, – серийный технологический предприниматель с десятилетним опытом создания крупномасштабных программных и инфраструктурных компаний. Основанный в Дублине, он в настоящее время возглавляет Jentic, а также является членом Ирландского консультативного совета по искусственному интеллекту, где консультирует правительство по вопросам политики искусственного интеллекта. Ранее в своей карьере он соосновал DemonWare, высокомасштабную онлайн-платформу для крупных издателей видеоигр, которая позже была приобретена Activision Blizzard, и PageFair, стартап, финансируемый венчурными фондами, ориентированный на аналитику блокировки рекламы, который был приобретен Blockthrough. Он также основал или возглавлял несколько стартапов и продолжает поддерживать экосистему стартапов Ирландии через инициативы, такие как Techpreneurs.

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

Вы основали и возглавляли несколько технологических компаний, от DemonWare (приобретенной Activision Blizzard) до PageFair и теперь Jentic, и также являетесь членом Ирландского консультативного совета по искусственному интеллекту. Что привело вас обратно к строительству на уровне инфраструктуры снова с Jentic, и какую пробел вы увидели в экосистеме агентов искусственного интеллекта, которую другие пропускали?

В третий раз, когда вы замечаете закономерность, вы должны ее воспринимать серьезно. В DemonWare все говорили об онлайн-мультиплеере – но трудной проблемой была сетевая инфраструктура под ним. То же самое происходит с агентами искусственного интеллекта. Модели замечательны. Бутылочное горлышко – это слой интеграции – всегда было. Агенты искусственного интеллекта работают на API, и эти API были построены для людей: задокументированы для людей, защищены для людей и структурированы для людей. Укажите автономного агента на эту инфраструктуру, и она быстро разрушается. Пилотные проекты корпоративного искусственного интеллекта не терпят неудачи, потому что модель неправильно поняла задачу; они терпят неудачи, потому что агент не смог надежно подключиться к системам, которые ему нужны. Генеративный искусственный интеллект предлагает новый способ решения этой проблемы – путем рассмотрения интеграции как проблемы знаний, а не проблемы кодирования. Этот вывод привлек меня.

Когда вы начали Jentic в 2024 году, была ли безопасность агентов основной тезисом с первого дня, или фокус уточнился, когда вы наблюдали, как организации фактически развертывали автономные агенты в производстве?

Первой нитью, которую я потянул, были учетные данные. Я представлял себе агентов, размножающихся, каждый из которых нуждается в учетных данных для десятков систем, все эти секреты текут в контекстные окна LLM, получаются эксфильтрованные – горячая мешанина. Ответ тот же, что и двадцать лет назад: централизуйте аутентификацию и авторизацию. Но потянув эту нить, я сразу же столкнулся с следующей проблемой: если вы централизуете, используя традиционные инструменты интеграции, вы снова оказываетесь в стране статических коннекторов, а агенты не статичны. Что укрепило видение, было осознание того, что открытие возможностей должно быть тесно связано с контролем доступа – что агент должен быть предложен только той возможностью, которой он фактически уполномочен использовать, и что система, предоставляющая открытие, также может быть единой точкой принудительного исполнения и наблюдения.

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

Ошибка проста: агент – система, выполняющая запросы из LLM – также является системой, которая держит учетные данные и делает API-запросы. Компрометируйте агента, и вы получите все, что он мог бы сделать. Это та же ошибка, которую мы допустили в раннюю эпоху веба – веб-серверы с доступом к базе данных суперпользователя, потому что это было удобно. Jentic сидит как слой между агентом и API, которые он вызывает. Агент никогда не держит учетные данные. Он выдает запросы через наш управляемый слой выполнения, который вставляет учетные данные на стороне сервера, обеспечивает соблюдение политики и регистрирует каждый вызов. И когда что-то идет не так, есть единственный выключатель – одно действие останавливает доступ агента ко всем подключенным системам одновременно.

Вы говорили о разделении оркестровки и выполнения, чтобы содержать радиус взрыва. Можете ли вы объяснить на практике, как это разделение меняет профиль риска, когда экземпляр скомпрометирован?

В плоской модели LLM рассуждает о том, что делать, и直接 вызывает API, используя учетные данные, которые он держит. Компрометируйте слой рассуждения, и вы контролируете слой выполнения. С разделением LLM издает намерение – “вызовите API оплаты Stripe с этими параметрами” – управляемый слой выполнения проверяет этот запрос против политики, вставляет учетные данные на стороне сервера и делает вызов. LLM никогда не касается учетных данных. На практике: боковое движение становится намного сложнее, радиус взрыва ограничен тем, что слой выполнения разрешает для этой конкретной идентичности агента, и вы получаете выключатель. Один переключатель, и доступ агента останавливается во всех подключенных системах. Агент все еще может быть манипулирован – но манипулирование больше не означает автоматического компрометации учетных данных.

В реальных корпоративных развертываниях, как выглядит централизованное управление учетными данными и мгновенная отзывка на самом деле, и как это отличается от того, как большинство команд в настоящее время обрабатывают API-ключи и токены для агентов?

Сегодня большинство команд имеют разработчика, который выдает API-ключи, хранит их в файле .env и загружает их при запуске агента – часто напрямую в контекстное окно LLM. Никто не имеет полной картины того, какие агенты держат какие учетные данные. Когда кто-то уходит, ключи, которые он выдал, не ротируются. Когда агент ведет себя странно, нет аудиторской трассы, чтобы восстановить, что произошло. С Jentic разработчик никогда не обрабатывает сырые учетные данные. Они объявляют, какой доступ агенту нужен, платформа выдает ограниченный доступ, и агент вызывает через наш слой выполнения, не видя основного ключа. Это означает, что вы получаете мгновенную отзывку на агента, возможность приостановить доступ, пока вы расследуете, и временную аудиторскую трассу каждого API-запроса. Разница между этим и “API-ключ в файле .env” существенна.

Многие команды экспериментируют с фреймворками агентов в продажах, инженерии и науке о данных. Какие наиболее распространенные ошибки безопасности вы видите, когда организации переходят от экспериментов к производству?

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

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

Вместо того, чтобы подключать агент к пятидесяти разным API – каждому со своей схемой аутентификации, ограничениями скорости и причудами – разработчик подключается к одному конечному пункту. Этот конечный пункт предлагает инструменты для поиска нашего整个 каталога возможностей API, загрузки деталей и выполнения любого вызова. Это максимизирует гибкость через единый унифицированный интерфейс для неограниченных API, а также обеспечивает управление – какие агенты получают доступ к каким API, при каких условиях, с какими ограничениями – все управляется в платформе, а не в коде клиента. Слой выполнения является проходным; агенты все еще могут составлять многоступенчатые рабочие процессы, цепочечные вызовы и обрабатывать ошибки динамически. Управление без трения сложно. Побочный путь – переложить бремя на разработчиков. Инфраструктура должна делать обратное – поглощать эту сложность, чтобы разработчикам не пришлось.

С учетом того, что malware infostealer теперь активно нацеливается на файлы конфигурации агентов и хранимые учетные данные, видите ли вы, как атакующие смещают свое внимание в сторону инфраструктуры искусственного интеллекта как новой высокоценной поверхности?

Определенно – и логика очевидна. Файл конфигурации агента по сути является многосервисным суперключом: учетные данные для систем электронной почты, CRM, платформ выставления счетов, внутренних API и учетных записей GitHub. Одна успешная операция infostealer дает доступ на месяцы ко всей внешней системе компании. Это значительно более высокая отдача, чем нацеливание на любой отдельный сервис в изоляции. Другое измерение заключается в том, что агенты, работающие непрерывно в производстве, являются постоянными, аккредитованными присутствиями – не пользователем, который входит и выходит. Скомпрометированный агент может служить долгосрочным опорным пунктом, действующим ниже порогов обнаружения. Неудобная реальность заключается в том, что поверхность атаки развивается быстрее, чем оборонительное инструментирование. Jentic может значительно уменьшить поверхность атаки учетных данных, но мы не можем предотвратить, чтобы агент неправильно использовал предоставленные ему объемы. Эта более сложная проблема должна быть решена на уровне модели, с ограничениями и обнаружением внедрения запросов.

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

Большинство управляемых организаций не могут развертывать недетерминированные системы в свои наиболее ценные бизнес-процессы. Банк или страховщик не могут указать автономного агента на свою систему выставления счетов и сказать “разберитесь”. Итак, как вы можете инновировать без того, чтобы ваша позиция по риску стала тормозом? Ответ – песочница. Создайте цифрового двойника вашего имущества API с той же структурой и рабочими процессами, но без производственных учетных данных или последствий. Разверните агентов там, пусть они исследуют, наблюдайте, что происходит. Успешные пути захватываются в виде структурированных, детерминированных автоматизаций рабочих процессов, используя Arazzo, открытый стандарт рабочего процесса, разработанный в инициативе OpenAPI – аудиторный, повторяемый и просматриваемый любой командой по соблюдению требований. Это означает, что вы можете двигаться со скоростью искусственного интеллекта в песочнице и со скоростью предприятия в производстве, и эти два режима сосуществуют. Другие принципы все еще применяются – наименьшие привилегии, аудиторские трассы, выключатели, разделение оркестровки и выполнения. Но песочница – это структурный ответ на вопрос, застрявший на самом деле команды предприятия: как мы можем экспериментировать с недетерминированным искусственным интеллектом без того, чтобы поставить нашу позицию по соблюдению требований на него? Вы не развертываете недетерминизм. Вы извлекаете ценность из него в контролируемых условиях и развертываете только детерминированные выходы.

Спасибо за отличное интервью, читателям, которые хотят узнать больше, следует посетить Jentic.