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

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

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

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

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

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

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

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

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

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

В плоской модели LLM (Large-Low Management System) обдумывает необходимые действия и напрямую вызывает API, используя имеющиеся у него учетные данные. Компрометация уровня рассуждений приводит к контролю уровня исполнения. При разделении LLM генерирует намерение — «вызвать API биллинга Stripe с этими параметрами» — управляемый уровень исполнения проверяет этот запрос на соответствие политике, внедряет учетные данные на стороне сервера и выполняет вызов. LLM никогда не прикасается к учетным данным. На практике: горизонтальное перемещение становится намного сложнее, радиус поражения ограничен тем, что уровень исполнения разрешает для конкретной учетной записи агента, и появляется аварийный выключатель. Одно переключение — и доступ агента прекращается во всех подключенных системах. Агентом по-прежнему можно манипулировать, но манипуляция больше не означает автоматическую полную компрометацию учетных данных.

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

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

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

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

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

Вместо того чтобы подключать агента к пятидесяти различным API — каждый со своей схемой аутентификации, ограничениями скорости и особенностями — разработчик подключается к одной конечной точке. Эта конечная точка предоставляет инструменты для поиска по всему нашему каталогу возможностей API, загрузки подробной информации и выполнения любого вызова. Это обеспечивает максимальную гибкость благодаря единому унифицированному интерфейсу для неограниченного количества API, одновременно позволяя управлять доступом агентов к каким API, при каких условиях и с какими ограничениями — всё это управляется на платформе, а не в клиентском коде. Уровень выполнения является сквозным; агенты по-прежнему могут создавать многошаговые рабочие процессы, объединять вызовы и динамически обрабатывать ошибки. Управление без препятствий — сложная задача. Кратчайший путь — переложить бремя на разработчиков. Инфраструктура должна делать обратное — поглощать эту сложность, чтобы разработчикам не приходилось этого делать.

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

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

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

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

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