Кризис Видимости ИИ: Почему Команды Безопасности Летят В Слепую и Почему Им Не Нужно

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

Как отрасль, мы коллективно отключаем наши мозги, когда речь идет о基本ных принципах безопасности и наблюдаемости вокруг ИИ. Команды безопасности летят в слепую, но им не нужно быть.

Миф о Системных Промптах и Безопасном Инструментарии

Распространенный миф в области ИИ заключается в том, что мы можем контролировать поведение агента, просто сказав ему вести себя. Системные промпты являются консультативными, а не принудительными. В вышеупомянутом инциденте системные правила ИИ явно указывали никогда не выполнять разрушительные команды, но агент нарушил свои собственные заявленные ограничения и выполнил наиболее необратимое действие.

Мы должны работать под предположением, что ИИ не “знает” ничего на самом деле. Атаки против ИИ являются социальной инженерией, за исключением того, что цель глупее среднего человека. Любой, кто имеет опыт проведения тестирования на проникновение, понимает, насколько сложно для организаций защититься от атак социальной инженерии. Теперь наши компьютеры также уязвимы.

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

Черный Ящик Аудита ИИ

Если ИИ выходит из-под контроля или манипулируется, то выяснение того, что он сделал, является кошмаром. Инструменты ИИ обычно не предоставляют журналов аудита. Если вы достаточно удачливы, чтобы быть на корпоративном уровне, журналы, которые вы получаете, являются сильно неполными. Например, вы можете получить расплывчатое событие, в котором говорится, что пользователь “использовал ИИ Gen.” и получаете только базовые метрики, в которых подробно описываются входные и выходные токены.

Ни один из них не помогает аналитику безопасности ответить на фундаментальный вопрос: Что именно выполнил этот агент?

Раскрытие ИИ: Как Перестать Летать В Слепую

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

Вот как вы можете использовать свою текущую инфраструктуру, чтобы обнаружить активность ИИ:

• Анализ DNS: Анализ журналов DNS для запросов к известным доменам служб ИИ может помочь обнаружить использование ИИ в вашей среде.
• Списки угроз: Этот подход требует поддержания обновленного списка угроз доменов, связанных с платформами ИИ или поставщиками моделей.
• Ресурсы сообщества: Существуют проекты и блокировочные списки сообщества, которые можно изменить в таблицы поиска для программного использования.
• Отслеживание SSL: Аналогичный подход может использовать журналы SSL для отслеживания имен серверов, хотя он обеспечивает немного меньше детализации, поскольку не записывается полный URL.
• Телеметрия конечных точек: Вы можете использовать инструменты, такие как Sysmon, для подсчета дочерних процессов и поиска высоких создателей оболочек, что является сильным индикатором потенциальных агентов ИИ, выполняющих команды на конечной точке.

Слепое пятно, требующее активных изменений в вашем сборе данных, – это сами промпты. О чем пользователи просят ИИ? Загружают ли они какие-либо потенциально чувствительные документы, создавая проблемы с соблюдением требований? Ответы на эти вопросы, вероятно, требуют сбора запросов API к поставщику; веб-прокси, прокси LLM, инструменты сбора данных от поставщиков журналов и SIEM. Они могут удалить завесу, блокирующую этот ценный источник данных.

Новая Угроза: Злонамеренные Серверы MCP

Протокол контекста модели (MCP) появился как способ указать, как приложения ИИ интегрируются с внешними инструментами и источниками данных. Хотя он стандартизирует подключения, он также вводит огромные новые векторы атак через “Злой MCP” серверы.

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

Студенты обычно используют свой злонамеренный сервер, чтобы инструктировать ИИ, что он находится в “режиме обслуживания” и должен передать данные во вторичный инструмент для “журнала аудита”, что приводит к эксфильтрации данных. Некоторые из них более креативны со своими промптами, чем другие, но все они обычно успешны.

Возвращение Контроля

Чтобы правильно проаудитовать активность ИИ в реальном мире, вам нужен прокси для перехвата запросов ИИ и инструмент сбора журналов, способный обрабатывать огромные JSON-пayloads. С этой видимостью вы можете обнаружить и устранить угрозы. Вы не можете полагаться исключительно на поставщиков ИИ, чтобы предоставить слой безопасности. Принудительное исполнение должно жить в системах вашей организации, а не в абзаце текста, который мы надеемся, что модель решит выполнить. С хорошим решением сбора журналов команды безопасности имеют телеметрию; пора им начать ее запрашивать. вы можете обнаружить и устранить угрозы. Вы не можете полагаться исключительно на поставщиков ИИ, чтобы предоставить слой безопасности. Принудительное исполнение должно жить в системах вашей организации, а не в абзаце текста, который мы надеемся, что модель решит выполнить. С хорошим решением сбора журналов команды безопасности имеют телеметрию; пора им начать ее запрашивать.