fedorthinks
Все заметки

SECURITY · 1 июля 2026 г.

У твоих агентов есть логины, которыми никто не владеет

В этом году компании наплодили миллионы ИИ-агентов, и каждому нужны креды, чтобы вообще что-то делать — прочитать базу, отправить письмо, дёрнуть API. Слоя управления этими кредами пока нет. Итог: 68% организаций не могут надёжно отличить действия агента от действий человека, а живые креды пишут в прод без единого ответственного. Настоящая проблема безопасности агентного предприятия — не prompt injection. Это identity.

У твоих агентов есть логины, которыми никто не владеет

Любой разговор о безопасности агентов зациклен на эффектных атаках — prompt injection, отравление инструментов, фейковый баг-репорт, угоняющий кодинг-агента. Это всё реально. Но тихая, скучная и куда более крупная проблема вот в чём: твои агенты логинятся, и этими логинами никто не владеет.

Популяция взорвалась; управление — нет

Чтобы сделать что-то полезное, агенту нужны креды — ключ, чтобы прочитать базу, токен, чтобы отправить письмо, скоуп API, чтобы записать на приём. В этом году организации наштамповали их миллионами. Только пользователи Microsoft Copilot Studio создали больше миллиона агентов; Salesforce отчитались о ~$440M агентной выручки. Каждый такой агент, с точки зрения безопасности, — новый пользователь с паролем, только его никто не онбордил, им никто не владеет, и он никогда не уходит.

А систем, чтобы управлять этой популяцией, ещё нет. Okta выяснили, что 68% организаций не могут надёжно отличить активность ИИ-агента от активности человека. Cloud Security Alliance назвали это прямо: «Вакуум управления non-human identity». Поэтому identity для агентного ИИ доминировал и на RSAC, и на Identiverse в этом году.

Агент, которого не отличить от человека, — это агент, которого не проаудитить, не отозвать и не подчинить политике. Это не проблема ИИ. Это неуправляемый аккаунт.

Почему это хуже хитрой атаки

Для эксплойта с инъекцией нужен атакующий, который что-то смастерит. Для этого риска не нужен никто. Он просто лежит: кред с широким доступом, которым пользуется софт, действующий сам по себе, и логируется он как человек — так что, когда в 3 ночи что-то ломается, ты не можешь ответить на единственные важные вопросы. Какой агент это сделал? Кто его задеплоил? К чему ему было можно? Кого выключать? Если агент делит сервисный аккаунт или человеческий токен, честный ответ на все четыре — «мы не знаем».

Относись к агенту как к сотруднику, а не как к общему ключу

Решение — не продукт, который покупаешь; это дисциплина, которую ты уже знаешь по управлению людьми:

  • Своя личность. У каждого агента — отдельная, полноценная identity, никогда не общий сервисный аккаунт и не одолженный человеческий токен. Не можешь назвать агента за действием — не можешь им управлять.
  • Минимум привилегий, под задачу. Агент записи трогает записи. Не таблицу зарплат, не админ-API. Большинство утечек — это просто слишком широкие креды, ждущие плохого дня.
  • Владелец и срок. У каждой identity агента есть человек-владелец и срок жизни. Агенты, пережившие свою цель, — это неуправляемые аккаунты следующего аудита.
  • Аудируемость и отзыв. Ты видишь ровно, что делал каждый агент, и можешь убить его доступ одним движением — не роняя вместе с ним аккаунт человека.

Это тот же принцип, к которому я возвращаюсь ради безопасности агентов: минимум привилегий и жёсткая граница бьют любое обещание на уровне промпта. Identity — это тот же минимум привилегий, только для актора, а не для действия.

Итог

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

Дай каждому агенту свою scoped-identity, владельца и рубильник — до того, как перестанешь понимать, кто из них только что записал в прод.

Комментарии

Пока нет комментариев

Войдите, чтобы участвовать в разговоре.

Будьте первым, кто оставит мысль.