Агенты становятся новой нагрузкой для IAM, а ваши сервисные аккаунты к этому не готовы

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

Но именно здесь такой подход перестает работать. Сервисный аккаунт отвечает на вопрос: «какая система выполняет вызов?» Агент заставляет задать более сложный вопрос: «какой агент выполняет вызов, от чьего имени, ради какой цели и кто может отозвать его полномочия в следующие тридцать секунд?» По собственным оценкам IAM-индустрии, нечеловеческих идентичностей сейчас примерно на порядок больше, чем человеческих. Verizon DBIR 2026 также предупредил, что с приходом агентного ИИ особого внимания требуют сервисные и машинные аккаунты, согласно интерпретации отчета Token Security. Это разбор того, почему прежняя схема соответствия больше не работает, что создают ей на замену и как уже выглядят последствия ошибок.

Главные выводы - Сервисные аккаунты и API-ключи предполагают стабильного, детерминированного вызывающего. Агенты краткоживущие, недетерминированные и делегируют полномочия друг другу, что разрушает заложенные в общие учетные данные предположения об аудите, отзыве и минимально необходимых привилегиях. - Стандарты движутся к идентичности рабочей нагрузки для каждого агента: рабочую группу IETF WIMSE призывают требовать различимости агентов именно по идентичности, а не только по scope токена, используя идентификаторы каждого агента в стиле SPIFFE для политик, аудита и отзыва. - Инциденты уже вполне конкретны: скомпрометированные OAuth-токены в экосистеме Salesloft Drift использовались для перехода в корпоративные среды Salesforce, а июльский взлом Hugging Face был полностью выполнен автономным агентом. - Практические рекомендации сходятся в одной точке: отдельная идентичность для каждого агента, краткоживущие учетные данные с областью действия на конкретную задачу, выдаваемые вне контекста модели, и аудит, привязанный к агенту, а не к общей роли. - Если все ваши агенты аутентифицируются через один общий сервисный аккаунт, журналы не смогут показать, какой агент что сделал. Именно это стоит проверить уже на этой неделе.

Что произошло

В первые недели августа совпали два процесса. Во-первых, дискуссия о стандартах стала конкретной. Issue к проекту архитектуры IETF WIMSE, открытый 4 августа, утверждает, что текущая формулировка проекта об ИИ-посредниках слишком слаба: она допускает «separate workload identities or token scopes» для различения действий автономных агентов. Авторы issue объясняют, почему token scopes для этого недостаточно. Scope ограничивает то, что токен может делать, но не меняет того, кого этот токен представляет. Несколько агентов, разделяющих одни учетные данные, остаются неразличимыми в журналах аудита, системах отзыва и политиках на уровне агента, независимо от различий scope. Предлагаемое исправление: управляемые агентные платформы должны присваивать каждому агенту уникальный идентификатор рабочей нагрузки, передавать его в отдельном claim и использовать как стабильный ключ для политик, аудита и отзыва. В качестве рабочего примера приводится схема идентичности агентов Google, где каждому развернутому агенту присваивается идентичность на основе SPIFFE, связанная с его ресурсом агента.

Во-вторых, поток инцидентов не прекращался. Взлом Hugging Face в середине июля стал первым публичным вторжением в конкретно названную компанию, которое автономный агент провел от начала до конца: выполнение кода в pipeline наборов данных, сбор учетных данных, боковое перемещение между внутренними кластерами и тысячи действий за одни выходные. Ранее в том же году Moltbook, социальная сеть для ИИ-агентов, раскрыла 1,5 миллиона API-токенов из-за неверно настроенной базы данных всего через несколько дней после достижения 1,5 миллиона аккаунтов агентов, согласно обзору Studio Global. И повторяющийся пример DBIR об атаках на нечеловеческие идентичности, компрометация OAuth-токенов Salesloft Drift с последующим доступом к Salesforce-средам крупных компаний, включая Google, Cisco и Zscaler, имеет ровно ту форму риска учетных данных, от которых зависят агенты.

В августе 2026 года issue IETF WIMSE предложил различать действия агентов по отдельным идентичностям рабочих нагрузок, а не по token scopes, используя идентификаторы каждого агента как стабильный ключ для политик, аудита и отзыва. Этому предшествовали июльский взлом Hugging Face, проведенный агентом, и январский инцидент, при котором агентная платформа Moltbook раскрыла 1,5 миллиона API-токенов.

Почему сервисные аккаунты и API-ключи не соответствуют агентам

У этого несоответствия четыре стороны, и их полезно рассматривать отдельно, потому что решения различаются.

Общая идентичность уничтожает атрибуцию. Сервисные аккаунты изначально создавались как общие, статичные и достаточно привилегированные. Запустите десять агентов под одним аккаунтом, и ваш журнал аудита покажет одного субъекта. Как отмечает практический разбор Cockroach Labs, вы не сможете понять, какой агент обращался к каким данным, ротация потребует координации всех агентов, а разрешения аккаунта постепенно станут объединением всего, что когда-либо требовалось любому из них. Их обезличенный пример напоминает варианты, которые я слышал от клиентских команд: агент поддержки три месяца работал под аккаунтом с правом чтения всей клиентской базы, получил такой scope во время разработки и до запуска в production его так и не ограничили.

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

Делегирование ломает цепочку «от чьего имени». Агент, действующий от имени пользователя, и агент, действующий автономно, должны выглядеть для policy engine совершенно по-разному. С общим сервисным аккаунтом они выглядят одинаково. OAuth-делегирование достаточно хорошо решает пользовательский сценарий; автономному агенту нужна собственная идентичность, а при делегировании между несколькими агентами каждый переход должен сужать, а не расширять передаваемые полномочия.

Модель никогда не должна хранить секрет. Это структурная проблема, а не вопрос настройки. Учетные данные, помещенные в контекстное окно, видны модели и всему, что способно ею манипулировать. Prompt injection может вывести их наружу через собственные ответы агента. Решение состоит в краткоживущих, ограниченных по scope учетных данных, выдаваемых во время задачи token service и хранимых на уровне исполнения инструментов, чтобы модель инициировала вызовы, не получая секрет в контекст. Cockroach Labs хорошо объясняет этот принцип, и он совпадает с тем, что я говорю клиентам, строящим самостоятельно размещаемые агентные стеки: ключи находятся у harness, намерение находится у модели.

Общие сервисные аккаунты ломают атрибуцию действий агентов, потому что в логах остается один субъект, живут дольше краткоживущих агентных нагрузок, размывают границу между действиями по поручению пользователя и автономными действиями и подталкивают команды передавать учетные данные через контекст модели, где до них может добраться prompt injection, согласно Cockroach Labs и сравнению miniOrange.

Что создают поставщики и органы стандартизации

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

Идентичность рабочей нагрузки для каждого агента. Описанное выше направление WIMSE представляет стандартный подход: каждый логический агент получает уникальный стабильный идентификатор, в качестве рекомендуемой формы предлагается SPIFFE URI, отдельный от любой общей роли исполнения. Именно этот идентификатор становится ключом для политик, аудита и отзыва. Управляемые платформой агенты, разделяющие учетные данные исполнения, должны дополнять их claim для конкретного агента. Это самый важный сдвиг: идентичность на агента, а не на deployment.

Федерация вместо хранимых секретов. Разбор workload identity federation для агентов от Descope показывает схему: платформенная идентичность агента, например AWS IAM role или Kubernetes service account через IRSA, обменивается на краткоживущий scoped-токен у identity platform. Та также создает запись агента в каталоге, чтобы audit trail сохранялся дольше срока жизни токена. Нет долговечного ключа, который можно украсть, а запись идентичности переживает любую отдельную учетную запись или токен.

Обнаружение и governance как рынок. На коммерческой стороне поставщики non-human identity, включая Reco, Token Security, Oasis, Aembit и других, перепозиционируются вокруг агентов: обнаруживать все агентные учетные данные, связывать их с владельцем, отмечать избыточные привилегии и корректно отзывать. Подход Reco практичен: подбирать тип идентичности под роль агента, delegated OAuth для действий пользователя и отдельную workload identity для автономных действий, а затем пересматривать права по мере роста обязанностей, потому что агенты накапливают привилегии так же, как сотрудники накапливают ключи от помещений. OWASP Top 10 for Agentic Applications, опубликованный в декабре 2025 года, выделяет Identity and Privilege Abuse в отдельную категорию риска, давая командам безопасности общий язык для результатов аудита. Место этого уровня в более широком стеке является вопросом governance не меньше, чем tooling; организационную сторону я рассматриваю в материале о governance ИИ-агентов.

Формирующаяся архитектура: workload identity для каждого агента с идентификаторами в стиле SPIFFE как ключами политик, аудита и отзыва согласно обсуждению WIMSE; федерация платформенной идентичности в краткоживущие scoped-токены с постоянными каталожными записями агентов согласно Descope; и рынок поставщиков для discovery и least-privilege governance нечеловеческих идентичностей.

Когда идентичность агента дает сбой

Три инцидента, три разных режима отказа, и каждый из них показателен.

Hugging Face, июль 2026: проблема идентичности атакующего одновременно оказалась проблемой защитника. Вторжение, проведенное агентом, собрало облачные и кластерные учетные данные из worker выполнения кода и двигалось дальше по инфраструктуре. Это классическая история сверхпривилегированной нагрузки: компонент обработки данных хранил учетные данные, которые стоило украсть. Менее обсуждаемая деталь состоит в форензической асимметрии, раскрытой Hugging Face: атакующий агент не был ограничен какой-либо политикой использования, а собственную форензику компании сначала блокировали защитные ограничения размещенных моделей, которые она пыталась использовать. В итоге анализ провели на open-weight модели GLM 5.2 в собственной инфраструктуре. Ошибки идентичности и доступа по обе стороны одного инцидента.

Salesloft Drift, предупреждение DBIR: токены как универсальные ключи. Скомпрометированные OAuth-токены одной вендорской экосистемы использовались для перехода в Salesforce-среды крупных предприятий. Без паролей и без фишинга людей: нечеловеческие учетные данные, которым широко доверяли и которые незаметно переиспользовались. Каждый агент, подключенный к SaaS-инструменту долгоживущим OAuth grant, имеет именно такую форму риска. Меры защиты должны иметь ту же форму: короткий срок жизни, узкий scope, отдельность для каждого агента и возможность отзыва.

Moltbook, январь 2026: агентные платформы концентрируют риск идентичности. Платформа агентных аккаунтов раскрыла 1,5 миллиона API-токенов, а также адреса электронной почты и сообщения между агентами из-за неверно настроенной базы данных, согласно материалу Studio Global. Централизуя идентичность агентов, вы одновременно централизуете потенциальный blast radius. Стоит отметить, что часть циркулирующих деталей я бы считал сообщенными, а не аудированными: раскрытие Hugging Face является первичным источником, а цифры Moltbook происходят из вторичной публикации.

К документированным сбоям идентичности агентов относятся июльский взлом Hugging Face 2026 года, когда автономный агент получил облачные и кластерные учетные данные и двигался по инфраструктуре согласно анализу Waxell, переход через OAuth-токены Salesloft Drift в корпоративные Salesforce tenants согласно Token Security о DBIR 2026, и утечка 1,5 миллиона агентных API-токенов из Moltbook.

Что делать сейчас

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

2. В этом месяце: переведите хотя бы одного автономного агента с долгоживущих учетных данных на краткоживущие токены, ограниченные конкретной задачей, выдаваемые token service или identity platform, хранимые на уровне исполнения инструментов и никогда не попадающие в контекст модели. Начните с агента с самым широким доступом; обычно это тот, кому кто-то в спешке выдал «временный» слишком широкий scope.

3. В этом квартале: дайте каждому логическому агенту собственную стабильную идентичность, SPIFFE ID там, где есть соответствующая инфраструктура, или уникальный сервисный аккаунт на агента там, где ее нет, привяжите к ней аудит и оповещения и напишите runbook отзыва до того, как он понадобится. Если вы еще только решаете, где вообще должны запускаться агенты, компромисс между локальными и облачными агентами определит, какую часть этой области вы сможете контролировать сами.

FAQ

Что такое идентичность агента в терминах IAM?

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

Почему агенты не могут просто разделять один сервисный аккаунт?

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

Что делают органы стандартизации с идентичностью агентов?

Рабочая группа IETF WIMSE расширяет архитектуру workload identity на ИИ-посредников. Активное предложение требует идентификаторов для каждого агента, где SPIFFE URI выступает рекомендуемым механизмом, вместо зависимости от token scopes. OWASP в декабре 2025 года опубликовал Top 10 for Agentic Applications, выделив identity and privilege abuse в отдельную категорию, а Cloud Security Alliance предлагает framework governance идентичности агентов с рекомендацией уникальной идентичности на каждого агента.

Должны ли учетные данные агента когда-либо попадать в контекст модели?

Нет. Все, что находится в контекстном окне, видно модели и может быть выведено через prompt injection. Принятый шаблон состоит в том, что token service выдает учетные данные во время задачи, уровень исполнения инструментов хранит их между моделью и API, права ограничиваются задачей, а срок жизни остается коротким. Модель запрашивает действие; harness хранит секрет.

Итог

В сфере идентичности любят говорить, что identity является control plane, и агенты проверят эту идею жестче, чем когда-либо делали микросервисы. Направление уже достаточно ясно, чтобы начинать строить под него сегодня: отдельная идентичность для каждого агента, секреты вне модели, токены, срок которых истекает быстрее, чем распространяются инциденты, и аудит, способный ответить «какой агент, от чьего имени, с какой целью». Организации, пострадавшие этим летом, не использовали экзотические конфигурации. Они использовали общие учетные данные и надеялись, что все будет хорошо. Именно этот разрыв нужно закрыть, и большая часть необходимой технологии уже существует.

Если вы переносите идентичность агентов на существующую IAM-среду и хотите подключить к обсуждению практика, это как раз та работа, которой я занимаюсь. Связаться.

Источники

• IETF WIMSE WG, draft-ietf-wimse-arch issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139 (открыт 2026-08-04, получен 2026-08-29)

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/ (опубликовано 2026-07-17, получено 2026-08-29)

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai (опубликовано 2026-05-20, получено 2026-08-29)

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents (опубликовано 2026-06-22, получено 2026-08-29)

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/ (опубликовано 2026-05-20, получено 2026-08-29)

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents (опубликовано 2026-07-20, получено 2026-08-29)

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026 (опубликовано 2026-07-17, получено 2026-08-29)

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846 (опубликовано 2026-08-17, получено 2026-08-29)