Джейкоб Идеског, технический директор Curity – Интервью

Джейкоб Идеског – специалист по идентификации и технический директор в Curity. Большую часть своего времени он посвящает работе с решениями безопасности в области API и веб-пространства. Он работал над проектированием и реализацией решений OAuth и OpenID Connect для крупных корпоративных развертываний, а также для небольших стартапов.

Curity – современная платформа управления идентификацией и доступом (IAM), построенная вокруг сервера идентификации Curity, который представляет собой решение на основе стандартов, предназначенное для обеспечения безопасности аутентификации и авторизации для приложений, API и цифровых сервисов в крупном масштабе. Она поддерживает протоколы, такие как OAuth 2.0 и OpenID Connect, для централизации потоков входа, обеспечения тонкого контроля доступа и выдачи безопасных токенов как для человеческих пользователей, так и для машинных клиентов, включая API и сервисы. Платформа разработана с учетом гибкости и масштабируемости, что позволяет организациям развертывать ее в облаке, гибридных или локальных средах, интегрироваться с существующими системами и обеспечивать безопасный, безшовный пользовательский опыт без необходимости использования индивидуальной безопасности.

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

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

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

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

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

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

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

Вы утверждали, что строгие ограничения необходимы для агентских AI. Что представляет собой “хорошая” идентификационная конструкция для AI-агентов на практике, и где компании обычно ошибаются?

Хорошая идентификационная конструкция начинается с принципа наименьших привилегий и разрешений, привязанных к явному намерению. Каждый AI-агент должен иметь свою собственную идентификацию, узко определенные разрешения и четко определенные доверительные отношения (явные правила для систем, с которыми он разрешен взаимодействовать). Основополагающим должно быть, что доступ должен быть связан с целью, ограничен во времени и легко отзываться.

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

Curity долгое время работала со стандартами, такими как OAuth и OpenID Connect. Насколько критически важны открытые стандарты идентификации для обеспечения совместимости и безопасности агентских AI в сложных корпоративных средах?

Открытые стандарты абсолютно критичны. Предприятия уже работают с сложными тканями идентификации, охватывающими облачные платформы, сервисы SaaS и внутренние API. Агентские AI добавляют еще больше сложности.

Без стандартов каждый агент становится своей собственной интеграцией и постоянным исключением безопасности. С стандартами, такими как OAuth и OpenID Connect, агенты могут быть аутентифицированы, авторизованы и аудированы, как и любая другая рабочая нагрузка. Это единственный подход, который может обеспечить безопасное масштабирование в реальных корпоративных средах.

Нечеловеческие идентификаторы становятся более распространенными, от учетных записей сервисов до машинных идентификаторов. Что делает AI-агентов фундаментально khácными от предыдущих нечеловеческих идентификаторов с точки зрения безопасности?

Ключевое различие между современными AI-агентами и более старыми нечеловеческими идентификаторами (НХИ) заключается в автономности. Традиционная учетная запись сервиса делает именно то, что говорит ей код, строго связанный с ее задачей. AI-агент интерпретирует инструкции, адаптирует свое поведение и выполняет действия, которые никогда не были явно прописаны – все это увеличивает потенциальную опасность, если нет соответствующих ограничений.

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

Насколько важны аудиторские следы и идентификационная журналистика для управления агентскими AI, особенно в регулируемых отраслях?

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

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

Какие реальные риски вы видите, возникающие, когда организации развертывают чрезмерно привилегированные или плохо контролируемые AI-агенты в производстве?

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

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

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

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

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

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

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

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

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

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

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

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

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