69% предприятий подвержены риску нарушений безопасности ИИ

При поддержке NTT DATA AIVista

Июньское исследование VentureBeat показало, что 69% предприятий до сих пор используют ИИ-агентов, которые делят учетные данные между собой — практика, сопряженная с более высоким уровнем инцидентов безопасности и потенциальных угроз.

Однако на конференции VB Transform 2026 технический директор NTT DATA AIVista Мукеш Карки (Mukesh Karki) и директор по безопасности и доверию в Snowflake Маянк Упадхьяи (Mayank Upadhyay) заявили, что наведение порядка с идентификацией — это лишь первый шаг. Чтобы безопасно развертывать автономные системы в масштабе предприятия, организациям также необходимы авторизация на уровне действий и защищенные от несанкционированного вмешательства журналы аудита, встроенные в каждое взаимодействие агента.

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

Почему общие учетные данные приводят к инцидентности ИИ-агентов

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

«В мире традиционного ПО человек куда-то кликает, программа выполняет вполне детерминированное действие, и вы точно знаете, какой API она вызовет, — пояснил он. — Но в мире агентов у программного обеспечения есть собственный “мозг”, и оно постоянно перестраивает себя на ходу. Если вы дадите такой программе больше полномочий, чем ей требуется для конкретной цели, агенты в силу своей природы будут экспериментировать, станут пробовать самые разные подходы, и это приведет к непредвиденным побочным эффектам».

По его словам, внедрение единого статического ключа API лишь усугубляет риски.

«Это крайне неудачный паттерн, когда у вас есть один ключ API, вы “вшиваете” его в агента, и он общается с определенным SaaS-сервисом от имени кого угодно. В результате вы наделяете агента суммой всех возможных привилегий пользователей», — пояснил он, отметив, что вторая проблема носит судебно-технический характер, поскольку «если что-то пойдет не так, вы просто не сможете отнести это на счет конкретного агента».

Ограниченные по области учетные данные — лишь отправная точка в регулируемых отраслях

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

«В условиях регуляторной среды агент без четко ограниченных (scoped) учетных данных просто не сможет работать, и точка, — подчеркивает Карки. — Наличие таких учетных данных — это лишь старт. На практике действуют два уровня ограничений: первый связан с юрисдикцией, в которой работает агент, а второй — с правилами конкретной организации».

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

«Простых ограниченных учетных данных недостаточно, поскольку проверка должна осуществляться на основе конкретных действий и правил в момент совершения каждого шага», — поясняет эксперт.

Где рушится аналогия между сотрудниками и ИИ-агентами

По словам Карки, аналогия с сотрудниками применима лишь до определенного предела. Агентам по-прежнему необходимо усваивать уникальный контекст организации — точно так же, как это делает новичок. Но в отличие от людей, предприятия объективно не могут выстроить доверительные отношения с тысячами агентов с течением времени.

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

Упадхьяи предложил отвести агентам более скромную ступень в организационной иерархии.

«Относитесь к ним как к стажерам, — посоветовал он. — У них благие намерения, но они не всегда понимают, что делают, поэтому за ними нужно присматривать по мере того, как вы постепенно выстраиваете доверие».

На платформе Snowflake администраторы могут устанавливать общеплатформенные защитные механизмы (например, режим «только чтение»), в то время как разработчики дополнительно сужают разрешения агента при запуске каждой новой сессии.

Трехуровневый подход к управлению ИИ-агентами

У экспертов нет сомнений в том, где именно должен осуществляться контроль.

«Управление должно происходить при каждом действии агента и находиться вне пределов самого агента, — поясняет Карки. — Только так вы сможете впоследствии доказать, что агент совершил именно то действие, на выполнение которого имел право».

Упадхьяи разделяет систему управления на три уровня:

Уровень агента охватывает идентификацию, разрешения на использование инструментов и управление протоколами MCP (Model Context Protocol).

Уровень модели защищает от косвенных промпт-инъекций и позволяет запускать модели внутри виртуального частного облака (VPC) клиента, благодаря чему подсказки остаются невидимыми для провайдера модели.

Уровень данных отвечает за принцип наименьших привилегий, архитектуру без дублирования данных (zero-copy) и контроль доступа на основе ролей (RBAC).

Для корректной работы агентов надзор необходим на всех трех уровнях.

Что предприятиям следует проверить в первую очередь

Компаниям, проводящим аудит управления существующими ИИ-агентами, Упадхьяи рекомендует начать с двух шагов. Первый — аудит разрешений для статических секретов, поскольку это крупнейший устранимый вектор атак. Второй — борьба с теневым ИИ с помощью шлюза MCP, чтобы разработчики больше не запускали кустарные опенсорсные серверы MCP «под столом», а администраторы имели полную прозрачность в отношении того, кто и с каким MCP-сервером взаимодействует.

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

«Многое из этого невозможно внедрить задним числом, когда агентская система уже функционирует, и станет еще сложнее, если вам придется доказывать аудиторам, почему агент повел себя именно так, — объясняет он. — Доказуемость необходимо закладывать с самого нуля еще на этапе проектирования системы».

Спонсорские материалы — это контент, подготовленный компанией, которая оплачивает публикацию или имеет деловые отношения с VentureBeat, и они всегда четко маркируются. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.