69% компаний используют AI-агентов с общими учётными данными. Для бизнеса это не абстрактная угроза, а вполне прикладная проблема: если один агент скомпрометируют или он выполнит лишнее действие, команда потом не сможет нормально восстановить, кто именно и что сделал.
Эту тему на VB Transform 2026 обсуждали технический директор NTT DATA AIVista Мукеш Карки и директор по безопасности и доверию Snowflake Маянк Упадхьяй. Их общий вывод простой: одной машинной идентичности для агента мало. Нужны ещё как минимум точечная авторизация на уровне конкретного действия и журнал операций, который выдержит проверку аудитора.
Цифра 69% показывает не сбой модели, а сбой управления доступом
По данным июньского опроса VentureBeat среди 107 компаний, у 69% организаций AI-агенты где-то в инфраструктуре делят учётные данные. Ещё одна важная цифра: 54% респондентов уже сталкивались с инцидентом или почти-инцидентом, связанным с агентами. И только 32% компаний выдают каждому агенту отдельную ограниченную идентичность.
Проблема здесь приземлённая. Если несколько агентов работают с одним API-ключом или одной сервисной учётной записью, любой сбой превращается в разбор полётов без виновника. В журнале останется ключ, а не конкретный агент. Для ИБ это плохая новость, для внутреннего контроля ещё хуже.
Одного IAM недостаточно, когда агент действует сам
В обычном приложении путь действий более-менее предсказуем: пользователь нажал кнопку, система вызвала конкретный API. У агентных систем логика другая. Агент сам выбирает шаги внутри поставленной цели, перебирает варианты и может зайти дальше, чем планировала команда, если ему заранее выдали слишком широкие права.
Именно поэтому, по словам участников дискуссии, защита не должна заканчиваться на логине и роли в IAM. Нужна проверка каждого чувствительного действия по контексту: что именно делает агент, с какими данными, в какой системе и в рамках какой задачи. Для страхования, финансов и медицины это особенно важно, потому что правила отличаются не только между компаниями, но и между юрисдикциями и типами операций.
Проще говоря, отдельная идентичность для агента — это санитарный минимум, а не готовая защита.
Следующий слой защиты — ограничения, журналирование и контроль инструментов
Snowflake описывает такой подход как многослойную схему: отдельная идентичность агента, ограничения на инструменты и данные, защита модели от непрямых атак через подсказки и полноценное журналирование. Отдельный практический совет — убирать статические секреты и не оставлять агентам долгоживущие ключи там, где можно выдать временные права под конкретную задачу.
Ещё одна боль — так называемый теневой AI. Пока руководство обсуждает эффект от автономных помощников, разработчики уже могут подключить агента к CRM, Jira, файловому хранилищу и внутренней базе знаний через набор плохо документированных прокладок или MCP-серверов с открытым кодом. Если платформа не видит эти связи централизованно, служба безопасности работает почти вслепую.
Отсюда и неприятный компромисс: чем полезнее агент, тем опаснее ошибка. Поэтому для рискованных сценариев компании всё чаще оставляют режим с подтверждением со стороны человека, используют песочницы и выдают права не «на всякий случай», а под конкретную сессию.
Что это значит для рынка России и СНГ
Для русскоязычных команд вывод очень практичный. Если AI-агент уже ходит в корпоративные системы, вопрос нужно ставить не как «есть ли у него доступ», а как «можем ли мы доказать каждое его действие». Это важно и для компаний с жёсткими требованиями по аудиту, и для интеграторов, которые встраивают агентов в клиентские процессы. Иначе первый же спорный инцидент быстро превратит красивую автоматизацию в дорогой внутренний аудит.
Следующий этап рынка выглядит предсказуемо: в 2026 году компании будут сравнивать агентные платформы уже не по качеству демо, а по тому, насколько хорошо они объясняют и ограничивают действия агента в промышленной среде. Оригинал: .