Последнее десятилетие руководители служб безопасности выстраивали защиту вокруг людей и кода. Практики shift-left позволяли выявлять уязвимости на ранних этапах разработки. Zero trust уменьшала радиус поражения при боковом перемещении. Инструменты для разработчиков добавляли ограждения прямо в IDE. Архитектура была надёжной — для предприятия, где код писали люди и приложения запускали люди.
Такого предприятия больше не существует.
AI-агенты переходят из исследовательских проектов в рабочие нагрузки такими темпами, к которым большинство служб безопасности не были готовы. Они действуют автономно, напрямую потребляют токены и API, принимают решения без человеческих контрольных точек и оставляют аудиторский след, только если кто-то догадался его потребовать.
Модель shift-left, возлагавшая на разработчиков ответственность за выявление проблем безопасности до развёртывания, не способна уловить то, что происходит в потоках живого инференса, внутри реестров моделей или в решениях, которые агент принимает во время выполнения.
Векторы атак стали новыми. Инструментарий за ними не поспевает. И традиционный ответ — добавить ещё один контроль на стороне разработчика — не закроет разрыв.
Что ваше текущее инструментальное обеспечение не видит
Вот честная инвентаризация того, что существующие инструменты безопасности упускают на предприятии, использующем ИИ:
Промпт-инъекция внедряет вредоносные инструкции в потоки живого инференса. Ни один инструмент SAST или DAST её не обнаруживает — они создавались для статического кода, а не для динамических взаимодействий с моделями или AI-нагрузок.
Отравление модели происходит, когда модели загружаются из реестров без проверки подписи или подтверждения происхождения. Эквивалентных средств контроля для процедур подписания программного обеспечения, которые большинство предприятий уже применяют к артефактам кода, не существует.
Утечки данных в процессе инференса раскрывают PII и интеллектуальную собственность через ответы моделей — без аудиторского следа и встроенных средств контроля, оставаясь невидимыми для инструментов DLP, расположенных на сетевом уровне или уровне конечных точек.
Теневое распространение ИИ означает, что разработчики и команды используют несанкционированные модели, полностью обходящие управление данными и средства DLP.
Ни один из этих сценариев не является гипотетическим. Все они активны на предприятиях, которые начали развёртывать AI-нагрузки, не обновив свою архитектуру безопасности.
Платформа — самая всеобъемлющая граница доверия
Ответ на этот вызов — архитектурный, а не процедурный. Нельзя натренировать защиту от промпт-инъекции. Нельзя аудитом устранить отравление модели на ежеквартальных проверках. Единственная поверхность контроля, обладающая достаточным охватом, глубиной и возможностью принуждения, — это сама платформа.
Platform Engineering 2.0 определяет четыре поверхности контроля, которые внедряют безопасность ИИ и конфиденциальность данных на уровне платформы:
Управление моделями: версионированный реестр моделей с отслеживанием происхождения, шлюзами утверждения и мониторингом дрейфа. Каждая модель в production имеет цепочку хранения. Ни одна модель не разворачивается без проверки подписи.
Безопасность промптов: санитизация ввода и фильтрация вывода на уровне платформы. Принудительные границы контекста, предотвращающие распространение атак внедрения через конвейеры инференса — на уровне инфраструктуры, а не приложения.
Изоляция данных и конфиденциальность: границы данных на уровне арендаторов с шифрованием в покое и при передаче, а также политики DLP, встроенные непосредственно в конвейеры инференса — включая обнаружение PII и маскировку в реальном времени. Также необходимы конвейеры и ограждения для обработки данных и соответствующие средства контроля конфиденциальности.
Аудит инференса: полный аудиторский след каждого AI-инференса с пояснительными результатами и отчётами о соответствии требованиям. Не снимок на определённый момент времени — непрерывная запись в реальном времени, охватывающая действия как людей, так и агентов.
В совокупности они превращают платформу в границу доверия для ИИ. Безопасность располагается глубоко в инфраструктуре — невидимая и неизменяемая по умолчанию. Конфигурации обеспечивают наименьшие привилегии, mTLS, микросегментацию и автоматическую ротацию секретов, не требуя от разработчиков их настройки. Соответствие требованиям становится непрерывным, а не периодическим.
Агенты — новая проблема идентификации
Агентный ИИ (Agentic AI) вводит нечто, с чем службам безопасности придётся столкнуться напрямую: новый класс нечеловеческих идентификаций, действующих внутри вашего предприятия. AI-агенты потребляют API, а не интерфейсы. Им нужны разрешения с ограниченной областью действия, учётные данные нечеловеческих субъектов, бюджетные и исходящие ограничения. Ключевые компоненты управления: MCP-совместимые API для обнаружения агентов, политические ограждения, ограничивающие действия агентов предварительно одобренными шаблонами, аудит, фиксирующий всю цепочку решений, и механизмы эскалации, направляющие неопределённые решения человеку-рецензенту.
Если ваша стратегия управления идентификацией и доступом пока не учитывает идентификации агентов, в ней есть пробел — и этот пробел будет расширяться по мере масштабирования агентных развёртываний.
Что это значит для CSO
Безопасность структурно перестаёт быть задачей уровня разработчика. Средства контроля, работавшие, когда единственными действующими лицами в системе были люди, недостаточны для среды, где агенты принимают решения, потребляют ресурсы и взаимодействуют с вашими наиболее чувствительными конвейерами данных — зачастую без участия человека.
Уровень защищённости ваших корпоративных AI-развёртываний будет в значительной степени определяться зрелостью вашей функции платформенной инженерии. Это не технологическое решение, которое можно делегировать изолированной платформенной команде. Это архитектурное решение в области безопасности, которое должно быть в повестке CSO.
Запрос конкретен: привлеките руководство платформенной инженерии. Требуйте прозрачности в том, как управляются AI-нагрузки, как управляются идентификации агентов и встроены ли четыре поверхности контроля безопасности ИИ — управление моделями, безопасность промптов, изоляция данных и аудит инференса — в платформу или оставлены на усмотрение отдельных команд.
Если ответ — последнее, вы определили свой самый срочный пробел в безопасности.
Для получения всеобъемлющей структуры по встраиванию безопасности в платформу эпохи ИИ прочтите полный документ: Platform Engineering 2.0: An Evolution for the AI Era, написанный в соавторстве с Broadcom и PlatformEngineering.org.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Tanya O'Hara
