Последняя заметка Microsoft по безопасности указывает на простой сценарий отказа в AI-развертываниях: мощные AI- и agentic-инструменты переносят на cloud-native инфраструктуру быстрее, чем успевают нормально защитить.
Проблема не всегда в новом exploit. В случаях, которые описывает Microsoft, атакующим не были нужны zero-day или глубокая техника, специфичная для модели. Им был нужен открытый сервис, слабая или отсутствующая authentication и достаточно встроенных возможностей за этим сервисом, чтобы превратить доступ в реальный ущерб.
Microsoft называет этот класс проблем “exploitable misconfiguration”. Термин важен, потому что отделяет обычный долг по hardening от таких настроек, которые создают готовый путь атаки. Доступный из интернета UI или API сам по себе еще не означает взлом. Но если он управляет внутренними инструментами, pipelines, доступом к данным или code execution, и при этом не имеет правильной authentication и authorization, сама конфигурация становится vulnerability.
Что, по словам Microsoft, они наблюдали#
Microsoft сообщает, что выводы основаны на агрегированных и анонимизированных сигналах Microsoft Defender for Cloud. Эти сигналы показали AI-сервисы, публично доступные со слабой или отсутствующей authentication. Microsoft говорит, что в некоторых таких случаях атакующие активно злоупотребляли этим.
Перечисленные последствия серьезны: remote code execution, credential theft и доступ к чувствительным внутренним инструментам и данным. Общая нить здесь — не один конкретный баг продукта. Это форма развертывания.
AI- и agentic-приложения переходят из экспериментов в production workflows. Они часто подключаются к ticketing systems, HR systems, repositories, data stores, automation pipelines и cloud infrastructure. Поэтому их открытые поверхности становятся гораздо ценнее, чем у обычного тестового web app.
Kubernetes находится в центре паттерна, который описывает Microsoft. Многие AI workloads работают на cloud-native инфраструктуре, и Microsoft говорит, что Kubernetes становится предпочтительным operating layer для таких workloads. Это не делает Kubernetes причиной проблемы. Но это означает, что ошибки в service exposure, ingress, authentication, secrets и workload identity могут напрямую перейти в AI-системы с широкими операционными возможностями.
Microsoft также заявляет, что сигналы Defender for Cloud показывают: более половины эксплуатаций cloud-native workloads, включая AI applications, происходят из-за misconfigurations. Это широкий сигнал, а не замена assessment для конкретной среды. Но он поддерживает главный тезис: для многих организаций первая проблема AI security не является экзотической. Это открытая инфраструктура, за которой стоит слишком много полномочий.
Что делает AI misconfiguration пригодной для эксплуатации#
Полезный тест простой: может ли outsider без authentication или со слабой authentication добраться до сервиса, который способен выполнять значимые действия?
Microsoft определяет риск как сочетание public exposure и отсутствующей или слабой authentication и authorization. Практический результат может включать remote code execution, раскрытие чувствительных данных или вмешательство в pipelines и artifacts.
Именно поэтому безопасность AI applications не может останавливаться на model safety reviews. Многие agentic systems созданы для действий. Они вызывают tools. Они читают внутренние systems. Они создают tickets. Они запрашивают repositories. Они запускают workflows. Они могут выполнять code или pipeline jobs.
Если такая control surface открыта, атакующему может не понадобиться взламывать модель. Он может использовать приложение ровно так, как оно было развернуто.
В этом и сложность категории. Система может работать именно так, как настроена, и при этом оставаться небезопасной. Default service type, public load balancer, оставленный открытым demo UI или пропущенная настройка authentication во время быстрого rollout — этого может быть достаточно.
MCP servers наглядно показывают риск#
Microsoft выделяет Model Context Protocol, или MCP, как один из примеров. MCP позволяет AI agents обнаруживать внешние tools и data sources и взаимодействовать с ними стандартизированным образом. MCP servers могут работать локально или быть доступны удаленно, в том числе через Server-Sent Events и streamable HTTP.
Protocol поддерживает механизмы authorization, включая OAuth, но Microsoft отмечает, что он не навязывает их использование. Это важное различие. Поддержка authentication — не то же самое, что безопасное развертывание.
Microsoft сообщает, что наблюдала несколько удаленно открытых MCP servers, развернутых без authentication. В этих случаях unauthenticated access позволял напрямую взаимодействовать с чувствительными внутренними tools, включая ticketing systems, HR systems и private code repositories.
Более глубокая проблема, описанная Microsoft, — execution context. Некоторые небезопасные реализации MCP server выполняют действия tools в security context сервера, а не в context пользователя или agent. Если у такого сервера широкие внутренние privileges, unauthenticated caller может унаследовать доступ, которого у него никогда не должно было быть.
Microsoft говорит, что сигналы Defender for Cloud показывают: 15% удаленных MCP servers являются серьезно небезопасными и допускают unauthenticated access. Это не значит, что каждый MCP deployment уязвим. Но это показывает, насколько быстро новый integration layer может стать внешним входом во внутреннюю среду.
Практический вывод#
Главная проверка для команд, которые разворачивают AI agents, MCP servers и AI-enabled workflows: составьте inventory всех AI-facing endpoints и явно ответьте на три вопроса для каждого из них.
- Доступен ли endpoint из интернета или из слишком широкой internal network zone?
- Есть ли на нем обязательная authentication и authorization, а не только “security by obscurity” или network guesswork?
- Какие действия может выполнить сервис после входа: читать данные, запускать code, дергать tools, менять tickets, обращаться к repositories или запускать pipelines?
Если endpoint может выполнять значимые действия, он не должен быть публичным без strong authentication, least privilege и audit logging. Для MCP servers это особенно важно: remote MCP endpoint без auth нужно считать критическим security issue, пока не доказано обратное.
Минимальный практический baseline выглядит так: запретить публичный unauthenticated access, закрыть ненужные ingress и load balancers, включить per-user или per-agent authorization, ограничить tool permissions, не запускать tools в чрезмерно привилегированном server context, хранить secrets через managed secret stores, проверять Kubernetes service exposure и регулярно сканировать внешнюю поверхность.
Для production AI systems полезно добавить отдельный deployment gate: никакой agentic service не выходит в production, пока не проверены public exposure, identity, authorization, secrets, logging и blast radius. Это обычная cloud security дисциплина, но для AI она становится срочной, потому что agentic systems часто получают доступ к действиям, а не только к данным.
Вывод Microsoft прагматичен: многие AI-инциденты можно предотвратить не новым классом защиты для моделей, а базовой инженерной гигиеной — закрыть лишнее, включить authentication, урезать privileges и видеть, какие AI-сервисы вообще доступны извне.