Две трети компаний получили ИИ внутри чужого софта, не зная об этом
Две трети компаний получили ИИ внутри чужого софта, не зная об этом Инженер по безопасности Rodrigo Martinez Pinto разбирает данные отчёта Wiz «State of AI in the Cloud 2026»: 68% организаций, у которых ИИ-модели работают на собственной инфраструктуре, получили их через стороннее программное обеспечение. Проще говоря: две из трёх компаний не решали запускать ИИ — модель «заехала» внутри купленного продукта, и служба безопасности о ней не знала. Типичный сценарий по автору: компания покупает обычный корпоративный инструмент, например платформу для внутренних знаний. Внутри него уже лежат скачанная модель, локальный рантайм — программа, которая запускает модель, — база для поиска по документам и набор инструментов для ИИ-агентов. Ничего из этого не было в требованиях к закупке, никто не проверял модель и её настройки — оно просто работает. Другие цифры отчёта: 90% обследованных сред содержат какой-то самостоятельно размещённый ИИ, 80% — серверы MCP (мост, через который ИИ-агенты вызывают внутренние сервисы компании), 80% — ИИ-помощники в редакторах кода. Автор подчёркивает: большинство этого ИИ пришло «пассажиром», а не осознанным решением. Почему это не обычная проблема уязвимостей, как с log4j в 2021 году. Во-первых, модель — это непрозрачный набор весов: код не прочитаешь, поведение можно только наблюдать. Во-вторых, атака идёт через текст и данные — например, через внедрение инструкции в документ, который модель читает. В-третьих, привычные инструменты проверки (реестры компонентов, сканеры кода) модели, инструменты агентов и утечки данных просто не видят. Конкретные риски по автору: ИИ-поиск по внутренним документам может по специально составленному запросу выдать данные через границы доверия; избыточно наделённые полномочиями MCP-серверы дают агентам путь к внутренним системам в обход сетевой защиты; расхождение между «ИИ в трёх одобренных системах» и реальными сорока вылезет на аудите, в том числе по европейскому закону об ИИ; и, наконец, модель, скачанная из внешнего хранилища, может оказаться подменённой — такие случаи с Hugging Face и PyPI уже бывали. Автор отмечает, что у всех сценариев есть публичные прецеденты. Ответ, по мнению автора, не героический: шесть направлений работы на один квартал небольшой командой. Найти ИИ в своей среде отдельным сканированием (обычные инструменты его пропускают); завести «ИИ-паспорт» — перечень моделей, их источников, лицензий и доступа к данным; разделить в управлении ИИ, который вы поставили сами, и ИИ, приехавший с вендором; изолировать унаследованный ИИ в сети и не давать ему доступ к рабочим данным без явного разрешения; следить не за настройками, а за тем, что ИИ реально делает; и добавить в опросники вендоров прямые вопросы о встроенных моделях. Автор честно приводит возражения. «У нас уже есть проверка вендоров» — но она почти наверняка не спрашивает про встроенные модели. «68% — маркетинговая цифра Wiz» — возможно, у Wiz свой интерес, но вывод совпадает с данными Verizon DBIR и Unit 42, хотя точное число зависит от методики. Затраты автор оценивает как низкие: поиск дешёвый, перечень начинается с таблицы, вопрос вендору — один абзац. Дешевле сделать сейчас, чем после инцидента. Общий вывод автора: это повторение старого сценария — S3-бакеты в 2016-м, Heartbleed в 2014-м, log4j в 2021-м: технология расползается по инфраструктуре быстрее, чем её начинают контролировать. Громкого ИИ-инцидента пока не было, но автор считает его вопросом времени, и предлагает использовать цифру 68% как аргумент для руководства, чтобы спокойно провести проверку заранее. Это мнение автора-инженера, а не измеренный результат внедрения. Источник: https://hackernoon.com/securing-inherited-ai-models-runtimes-and-tools-inside-vendor-software