Black Kite выявила критические уязвимости у 34,2% проверенных ИИ-компаний

Команда подключает ИИ-помощника к репозиторию, чтобы он разбирал ошибки и предлагал исправления. Помощник получает токен доступа, читает код, иногда запускает команды. Теперь безопасность проекта зависит ещё и от того, как поставщик хранит этот токен и защищает собственную инфраструктуру. Хорошие ответы модели ничего об этом не говорят.

В материале ZDNet от 10 ноября приводятся результаты отчёта Black Kite об ИИ-поставщиках. Из 18 160 проверенных компаний у 34,2% обнаружили хотя бы одну незакрытую критическую уязвимость. Для разработчика и основателя это повод проверить, какие двери уже открыты внешним сервисам: от чтения клиентских обращений до изменения кода и доступа к рабочей инфраструктуре.

Что именно нашли исследователи

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

Помимо критических уязвимостей, исследователи отметили проблемы с DMARC у 61,7% компаний и слабости DKIM у 37,3%. Это механизмы проверки подлинности электронной почты. Ошибки в их настройке могут облегчать подделку писем и фишинг: например, когда сотруднику приходит якобы служебная просьба повторно авторизовать интеграцию.

Ещё 29,7% компаний получили оценку высокой восприимчивости к атакам вымогателей по индексу Black Kite. Здесь важно прочитать цифру правильно: это оценка риска, а не доля организаций, которые уже зашифровали преступники. Аналогично, наличие критической уязвимости само по себе не доказывает, что через неё можно добраться до данных конкретного клиента.

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

Как проблема поставщика становится вашей

Представим помощника поддержки, подключённого к CRM. Для подготовки черновика ответа ему нужны текст обращения и несколько полей карточки клиента. Но при настройке команда выдаёт сервису возможность выгружать всю базу и менять записи: так быстрее запустить пилот.

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

Отдельный разбор MCP-компонентов, который упоминает ZDNet, содержит 1 732 замечания безопасности. Из них 48,8% отнесены к высокому или критическому уровню, включая возможности внедрения кода и команд. Это доля замечаний в отдельном анализе. Из неё нельзя заключить, что уязвимы 48,8% всех MCP-серверов или компаний.

Сам MCP помогает связывать ИИ-приложения с инструментами и бизнес-системами. Практическая проверка здесь касается реализации: кто может вызвать инструмент, какие аргументы он принимает и с какими правами выполняется действие.

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

Начните с перечня ИИ-сервисов, которым уже выданы доступы. Для каждого зафиксируйте владельца внутри команды, доступные данные, разрешённые действия и способ быстро отключить интеграцию. Такой список превращает обсуждение безопасности в понятную инженерную задачу.

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

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

У отчёта есть ограничения: по приведённому пересказу нельзя сравнить риск ИИ-компаний с обычными SaaS-поставщиками или оценить безопасность выбранного продукта. Зато он даёт конкретный повод пересмотреть разрешения. Перед расширением пилота проверьте, соответствует ли доступ сервиса задаче, ради которой вы его подключили.