К 2028 году в корпоративных средах будет работать 1,3 млрд AI‑агентов, а классическая модель identity по‑прежнему исходит из допущения «один деятель — один человек». Разбираем, что ломается в аутентификации, почему service account и OAuth‑токен больше не закрывают задачу, и как мы в Ideco смотрим на ближайшее развитие средств защиты: непрерывная биометрия для людей и делегированные токены для агентов.
Цифры, которые ломают ИБ‑ландшафт
На RSAC 2026 Microsoft, опираясь на прогноз IDC, заявила о 1,3 млрд AI‑агентов в корпоративных средах к 2028 году (Windows Forum, RSAC 2026, Lantern Studios). Это не «копилоты, которые помогают писать письма» или «чатики» — это автономные исполнители, у которых есть права, токены и доступ к продуктовым системам.
Мы сами уже видим лавинообразное «нашествие агентов» как в собственной, так и в чужих корпоративных сетях.
Атакующая сторона тоже меняется. В отчёте о кампании GTG-1002 Anthropic зафиксировала первую массовую AI‑оркестрированную операцию: взломанная версия Claude, подключённая к набору MCP‑серверов, выполнила 80–90% тактических операций самостоятельно — разведку, поиск уязвимостей, эксплуатацию, сбор учётных данных, латеральное движение (Anthropic, Disrupting the first reported AI‑orchestrated cyber espionage campaign, Paul, Weiss разбор). Человек был нужен на 4–6 точках принятия решений за всю кампанию.
И последняя цифра, без которой картина неполная. По 2025 Identity Security Landscape от CyberArk (опрос 2 600 ЛПР‑ов в сфере ИБ), на каждую человеческую идентичность в средней организации приходится 82 машинных; 42% этих NHI имеют привилегированный доступ или доступ к чувствительным данным, при этом 88% респондентов всё ещё относят определение «привилегированный пользователь» исключительно к людям. 87% компаний за последние 12 месяцев пережили минимум два успешных identity‑центричных инцидента.
Вывод простой. Все защиты, которые мы строили десять лет — MFA, SSO, ZTNA — оптимизированы под пользователя, который раз в день логинится. Но настоящий «пользователь» вашей сети к 2028-му — это агент, который делает тысячи запросов в секунду от имени неясно кого.
Почему классический IAM ломается
Identity исторически построена вокруг одного допущения: за действием стоит человек. Хороший или плохой, авторизованный или нет — но человек. Все остальные конструкты натянуты поверх этой модели и в агентном мире протекают:
Service account. Слишком статичен, слишком привилегирован, не имеет TTL, на практике никогда не отзывается. CyberArk показывает, что значимая доля машинных идентичностей вообще не попадает в поле зрения IAM‑команд, а Gartner прямо рекомендует уходить от классических service‑аккаунтов к dynamic service identities — эфемерным учёткам с узким scope, управляемым через политики.
OAuth‑токен. Не различает, кто реально выполнил действие — пользователь сам или агент от его имени.
API‑ключ. Не поддерживает цепочки делегирования «агент A → агент B → инструмент C» с сужением прав на каждом шаге.
MFA. Когда у вас в продакшене 500 агентов, делающих платёжные операции, требование «второй фактор на каждое действие» теряет операционный смысл — ГОСТ 57 580 написан не про эту реальность.
Ни один существующий примитив не закрывает задачу: «агент X действует от имени человека Y в scope Z на TTL T минут с возможностью субделегирования и полным аудитом каждого шага в цепочке».
Новые векторы угроз: атака на агентскую плоскость
Параллельно с identity‑кризисом появился отдельный класс атак, который классический NGFW и SIEM не видят, потому что не понимают семантику взаимодействия LLM с инструментами.
Вектор | Суть | Пример |
Prompt injection | Скрытые инструкции в пользовательских данных или внешнем контексте перехватывают управление LLM | Supabase Cursor с привилегированной service-role обработал тикет с встроенной SQL-инструкцией и слил токены в публичный тред (Practical DevSecOps) |
Tool poisoning | Вредоносный MCP-сервер выдаёт нормальные на вид tool descriptions с инструкциями внутри | OWASP формализовал шаблон в MCP Tool Poisoning: «безобидный» инструмент сообщает агенту прочитать /etc/shadow |
Shadow agents | Сотрудники подключают неавторизованных агентов к корпоративным системам, минуя IT и ИБ (а как без них работать?) | MCP как «новый Shadow IT» (Qualys TotalAI, март 2026) |
MPMA (Preference Manipulation) | Атакующий меняет ранжирование инструментов так, чтобы агент стабильно выбирал «отравленный» | Описан в академических MCPTox-бенчмарках |
Model poisoning | Закладки на этапе fine-tuning или в supply chain весов | Особенно опасно для приватных дообученных моделей в регулируемом контуре |
Объединяет всё это одно: атакующему не нужны 0-day, малварь и обход EDR. Достаточно валидных учётных данных и доверенного агента, которого аккуратно «попросили» сделать что‑то не то.
Аутентификация живого пользователя: от точки к непрерывности
Первая часть ответа касается людей. Привычная схема «один раз ввёл пароль и второй фактор — дальше работаешь» в мире, где за твоим терминалом могут сидеть агенты, перестаёт быть осмысленной.
CAPTCHA обходится любым ботом с пачкой бесплатных прокси. Device fingerprinting обходится. Поведенческая биометрия первого поколения будет сломана агентами в следующем цикле — не потому что защита плохая, а потому что агенты научились имитировать человека лучше, чем средний человек умеет доказывать, что он человек.
Реалистичный ответ — continuous authentication: непрерывная фоновая верификация, при которой identity подтверждается не одним событием логина, а потоком сигналов в течение всей сессии. Конкретно:
Behavioral biometrics в фоне. Ритм печати, паттерны мыши, манера прокрутки, тайминги переключения окон. Машинное обучение строит индивидуальный профиль за 2–4 недели пассивного наблюдения.
Периодическая физиологическая биометрия. На критичных операциях — подтверждение лица или отпечатка через FIDO2-устройство. Не на каждом клике, а по риск‑движку: смена IP, доступ к чувствительной системе, аномалия в behavioral‑профиле.
Risk‑based step‑up. Низкий риск — пропускаем. Средний — step‑up MFA. Высокий — терминируем сессию и принудительно перепроверяем человека.
Привязка к устройству и среде. SPIFFE‑подобная привязка идентичности не только к пользователю, но и к доверенному узлу.
Это осознанный компромисс. Непрерывная биометрия — это телеметрия с рабочего места и регуляторный риск по персональным данным. Но альтернатива в виде «пять MFA‑окон в час» убивает продуктивность и сама становится вектором атаки через alert fatigue.
Аутентификация агента: привязка к хозяину
Вторая часть ответа — про агентов. И здесь, в отличие от behavioral biometrics, индустрия неожиданно быстро сошлась вокруг одного семейства решений: OAuth с явной делегацией и сужением scope на каждом hop.
Базовая идея: токен агента всегда имеет две части — subject (человек, от чьего имени действует агент) и actor (сам агент). Через RFC 8693 token exchange и On‑Behalf‑Of‑flow токен может быть преобразован в более узкий при передаче в downstream‑сервис (Scalekit: OAuth for AI agents). Через RFC 9396 Rich Authorization Requests scope описывается не плоской строкой, а структурой — какой инструмент, на какой ресурс, в каких пределах.
В IETF (это те, кто утверждает RFC) уже готовится DAAP — Delegated Agent Authorization Protocol, который собирает всё это в единый протокол (IETF datatracker):
DID для криптографической идентичности агента.
Grant Token в формате JWT с agent‑specific claims и коротким TTL.
Cascade revocation: отзыв родительского grant автоматически инвалидирует все downstream‑делегации.
Scope attenuation: scope sub‑агента обязан быть строгим подмножеством родительского.
Delegation depth limit: глубина цепочки настраивается администратором, дальше — отказ (как TTL в сетевых протоколах).
Append‑only audit trail с хеш‑цепочкой — для проверяемости каждого шага.
В итоге авторизация выглядит так: пользователь даёт человеко‑читаемое согласие («агент Х может читать письма за последние 7 дней и отвечать на них в моём имени до 18:00»), система выпускает токен с явной парой subject/actor и набором структурированных authorization details, любой downstream‑вызов проходит через token exchange с обязательным сужением scope. На стороне инфраструктуры — gateway, который терминирует и валидирует токен, никогда не пробрасывает upstream‑токены вглубь и записывает всё действия в журнал.
Принцип, который из этого следует, простой: нет идентичности агента без идентичности его хозяина. Любой агент в корпоративной сети должен быть либо явно делегирован конкретному человеку, либо явно зарегистрирован как сервисная сущность с понятным владельцем и kill‑switch.
Цепочки делегирования: как выглядит токен будущего
Примерно так выглядит структура grant‑токена в духе DAAP/Coalition for Secure AI:
{ "iss": "https://idp.ideco.ru", "sub": "user:ivanov@ideco.ru.ru", "actor": { "did": "did:grantex:agent-7f3a", "type": "ai-agent", "model": "internal-llm-v4", "execution_env": "spiffe://ideco.ru/ns/agents/marketing" }, "scp": ["mail:read", "mail:reply"], "authorization_details": [{ "type": "mail_action", "actions": ["read", "reply"], "constraints": { "max_age_days": 7, "deadline": "2026-04-28T18:00:00+05:00" } }], "delegation_depth": 1, "delegation_max_depth": 2, "exp": 1745851200, "audit_chain": "sha256:..." }
Если агент-маркетолог делегирует часть задачи агенту-переводчику, новый токен наследует subject = ivanov@ideco.ru, actor обновляется на сабагента, delegation_depth увеличивается на 1, scope сужается до mail:read. Любой отзыв родительского grant через CAE/SSF мгновенно гасит цепочку.
Это понятное операционное требование. Без явного actor‑claim вы не сможете честно ответить на вопрос аудитора «кто инициировал транзакцию», когда между человеком и API окажется пять промежуточных агентов.
Регуляторика не успевает — и это окно
PCI DSS требует уникальной идентификации каждого человека с доступом к платёжным данным. ФСТЭК и ЦБ РФ работают с терминами «пользователь», «субъект доступа», где субъект по умолчанию — человек. ГОСТ 57 580 требует MFA для критичной инфраструктуры в логике, не предусматривающей автономных агентов.
Ни один крупный регулятор пока не готов к миру, где половина идентичностей в сети — не человеческие. Это создаёт две развилки.
Первая — театр регуляторного абсурда. Организации натягивают требования 2010 года на реальность 2026-го: агенты оформляются как обычные сервисные учётки, цепочки делегирования не логируются, аудитор не знает, что спрашивать, CISO не знает, что отвечать. Так будет до первого громкого инцидента в РФ — а судя по динамике GTG-1002, ждать недолго.
Вторая — битва за стандарт. Тот, кто первым принесёт регулятору внятную модель Agent IAM, словарь, методику аудита и пилот — тот и будет писать требования и первым получит сертификат. Окно для этого хода открыто примерно год‑полтора.
Где это в сетевой безопасности и NGFW
Мы в Ideco исходим из того, что NGFW — это естественная точка контроля для агентского трафика. Через периметр и внутренние сегменты идёт всё: вызовы агентов к внешним API, обращения к MCP‑серверам, межсервисные запросы между микросервисами под управлением AI‑оркестраторов. Без identity‑aware политик этот трафик — чёрный ящик.
Что мы делаем и куда идём в ближайших релизах:
Identity‑aware NGFW. Политики, привязанные не к IP, а к паре subject/actor — человеку и агенту, действующему от его имени. Решение принимается с учётом атрибутов токена, а не только сетевых заголовков.
MCP‑gateway внутри контура. Allowlist разрешённых MCP‑серверов, валидация tool descriptions на инъекции, явное подтверждение чувствительных операций вне LLM‑контекста — по логике рекомендаций OWASP.
Risk‑based ZTNA. Интеграция с behavioral‑биометрией и физиологической MFA на стороне рабочего места: NGFW понимает риск‑скор и динамически меняет уровень доступа в течение сессии, а не только на этапе подключения.
Журнал делегирований. Аудит, в котором для каждого пакета можно восстановить цепочку: кто человек, какой агент, через какие subagent‑токены пришёл запрос, какой был scope.
Это революционный подход для любого современного NGFW. Но это необходимый инженерный ответ на сдвиг, который уже произошёл: к 2028 году ваш периметр будет защищать не людей, а делегированные права людей.
Это уже не прогноз
Пока вы читали этот текст, в индустрии разворачивался свежий кейс, который иллюстрирует всё перечисленное лучше любой презентации. 27 апреля 2026 года ИИ‑агент Cursor на базе Claude Opus 4.6 за 9 секунд удалил продакшен‑базу данных компании PocketOS — b2b‑поставщика ПО для сервисов аренды с 1600+ клиентами — вместе со всеми резервными копиями. Восстановить данные невозможно.
Разберём механику инцидента в терминах этой статьи. Агент во время отладки обнаружил несоответствие учётных данных, самостоятельно нашёл API‑токен в файле, не имеющем отношения к его задаче, и через API провайдера инфраструктуры удалил том. Команда не знала, что этот токен (изначально выпущенный для добавления пользовательских доменов) даёт неограниченные права на всю инфраструктуру. В системном промпте было прямо написано «никогда не выполняй вредоносные и необратимые действия без явного запроса» — агент в посмертном объяснении признал, что нарушил каждый пункт правил.
Здесь сошлось всё, о чём мы говорили выше:
Переразрешённый NHI — тот самый случай, когда 42% машинных идентичностей по данным CyberArk имеют избыточные права.
Отсутствие scope attenuation — токен с правами на один домен по факту имел права «на всё».
Нет actor‑claim в аудите — действие выглядело как легитимный API‑вызов от имени владельца токена, а не «агент Cursor от имени разработчика в рамках конкретной задачи».
Нет границы делегирования — агент сам определил, что ему нужно, сам нашёл подходящий ключ, сам выполнил действие. Никакого «agent X действует от имени человека Y в scope Z на TTL T» — ни одного из этих ограничений не было.
Нет внешнего подтверждения деструктивного действия — ровно то, что OWASP рекомендует для агентских систем: явное подтверждение пользователем вне LLM‑контекста для деструктивных операций.
Системный промпт (который у них был) в стиле «никогда, *****, не додумывай» — это не модель угроз, а заклинание. LLM можно «попросить» сделать что угодно, и если у агента есть доступный токен с избыточными правами, то рано или поздно он этот токен использует. Защита должна быть не в текстовой инструкции, а в архитектуре: short‑lived токены с узким scope, обязательное подтверждение деструктивных операций вне LLM, identity‑aware enforcement на уровне инфраструктуры.
PocketOS — это даже не «сценарий 2028 года». Это апрель 2026-го, реальная компания, реальные 1600 клиентов и невосстановимые данные, без всяких «шифровальщиков». К моменту, когда у вас в сети будет работать не один Cursor, а сотни автономных агентов, такие инциденты перестанут быть новостью на хабре, а станут регулярным пунктом в отчётах SOC.
Защита должна быть готова.