Сеть, в которой живут агенты: кто нажал Enter и как это проверить

К 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 агентов, делающих платёжные операции, требование «второй фактор на каждое действие» теряет операционный смысл – ГОСТ 57580 написан не про эту реальность.

Ни один существующий примитив не закрывает задачу: «агент X действует от имени человека Y в scope Z на TTL T минут с возможностью субделегирования и полным аудитом каждого шага в цепочке».

Новые векторы угроз: атака на агентскую плоскость

Параллельно с identity-кризисом появился отдельный класс атак, который классический NGFW и SIEM не видят, потому что не понимают семантику взаимодействия LLM с инструментами.

 

Объединяет всё это одно: атакующему не нужны 0-day, малварь и обход EDR. Достаточно валидных учётных данных и доверенного агента, которого аккуратно «попросили» сделать что-то не то.

Аутентификация живого пользователя: от точки к непрерывности

Первая часть ответа касается людей. Привычная схема «один раз ввёл пароль и второй фактор – дальше работаешь» в мире, где за твоим терминалом могут сидеть агенты, перестаёт быть осмысленной.

CAPTCHA обходится любым ботом с пачкой бесплатных прокси. Device fingerprinting обходится. Поведенческая биометрия первого поколения будет сломана агентами в следующем цикле – не потому что защита плохая, а потому что агенты научились имитировать человека лучше, чем средний человек умеет доказывать, что он человек.

Реалистичный ответ – continuous authentication: непрерывная фоновая верификация, при которой identity подтверждается не одним событием логина, а потоком сигналов в течение всей сессии. Конкретно:

1. Behavioral biometrics в фоне. Ритм печати, паттерны мыши, манера прокрутки, тайминги переключения окон. Машинное обучение строит индивидуальный профиль за 2–4 недели пассивного наблюдения.

2. Периодическая физиологическая биометрия. На критичных операциях – подтверждение лица или отпечатка через FIDO2-устройство. Не на каждом клике, а по риск-движку: смена IP, доступ к чувствительной системе, аномалия в behavioral-профиле.

3. Risk-based step-up. Низкий риск – пропускаем. Средний – step-up MFA. Высокий – терминируем сессию и принудительно перепроверяем человека.

4. Привязка к устройству и среде. 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 требует уникальной идентификации каждого человека с доступом к платёжным данным. ФСТЭК и ЦБ РФ работают с терминами «пользователь», «субъект доступа», где субъект по умолчанию – человек. ГОСТ 57580 требует 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.

Защита должна быть готова.