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

Шон Бланчфилд, сооснователь и генеральный директор Jentic, – серийный технологический предприниматель с десятилетним опытом создания крупномасштабных программных и инфраструктурных компаний. Основанный в Дублине, он в настоящее время возглавляет Jentic, а также является членом Ирландского консультативного совета по искусственному интеллекту, где консультирует правительство по вопросам политики искусственного интеллекта. Ранее в своей карьере он соосновал DemonWare, высокомасштабную онлайн-платформу для крупных издателей видеоигр, которая позже была приобретена Activision Blizzard (ATVI ), и 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, при каких условиях, с какими ограничениями – все управляется в платформе, а не в коде клиента. Слой выполнения является проходным; агенты все еще могут составлять многоступенчатые рабочие процессы, цепочечные вызовы и обрабатывать ошибки динамически. Управление без трения трудно. Побочный путь – переложить бремя на разработчиков. Инфраструктура должна делать противоположное – поглощать эту сложность, чтобы разработчикам не пришлось.

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

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

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

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

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