Как выстроить системную безопасность ИИ

Первый тревожный сигнал для ИТ-директора сегодня звучит не из центра мониторинга и реагирования на инциденты (SOC) и не из отчетов по уязвимостям. Он появляется раньше — в момент, когда ИИ-агент впервые получает право что-то сделать в продакшене. Не ответить. Не подсказать. А именно — выполнить действие.

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

Бизнес внедряет ИИ-агентов как инструмент повышения эффективности, но фактически получает новый слой инфраструктуры без выстроенной модели управления.

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

Где компании начинают терять контроль

Первый признак проблем почти никогда не выглядит как инцидент. Он выглядит как удобство: команда подключает агенту доступ к системе управления задачами — «чтобы ускорить процессы». В этот момент кажется, что все работает идеально. Но именно здесь возникает новый контур риска — тихий и почти незаметный.

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

В результате возникает ситуация: полномочия есть, а управляемости — нет.

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

Где искать системное решение

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

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

Именно тогда мы обратились к модели SAIMM (Secure AI Maturity Model), которая позволяет разложить риски по полкам и понять, где у компании действительно есть слабые места. SAIMM выделяет шесть доменов: от управления и данных до безопасности самих агентов и цепочек поставок. Это дает возможность вести диалог с заказчиком предметно: не «нам нужно защитить ИИ», а «давайте посмотрим, на каком уровне зрелости вы находитесь и что нужно сделать для перехода на следующий». 

Подробно подход SAIMM (Secure AI Maturity Model) разбирали в этой статье.

Но даже с хорошей методологией оставался один ключевой вопрос, который мне задавали клиенты: «Хорошо, мы понимаем риски. Но как нам увидеть, что агент делает прямо сейчас? Не в логах „когда-нибудь потом“, а в момент действия. И еще важнее — как остановить это действие, если оно выходит за рамки?»

Этот разрыв между стратегией и реальным контролем в реальном времени — самое больное место.

Как защитить действия ИИ-агентов на практике

Изначально мы пытались адаптировать существующие системы DLP (Data Loss Prevention — предотвращения утечек данных) и логирования, но быстро поняли, что они не подходят. Агенты общаются с моделями на естественном языке, их действия не укладываются в простые сигнатуры. Здесь нужен другой инструмент, который понимает контекст взаимодействия: что агент планировал, какие инструменты вызывал, какие данные получил.

Хорошая новость — такие системы для защиты ИИ-агентов есть. Они делают поведение агентов прозрачным и управляемым в реальном времени. Например, КиберАгентРевью (CyberAgentReview). Эта система не заменяет существующие средства контроля, но хорошо дополняет их, предоставляя недостающий слой видимости на уровне действий агентов.

Расскажу на примере недавнего внедрения в крупной продуктовой компании. У них работало несколько агентов: в разработке, поддержке, аналитике. Формально доступы были настроены, но никто не мог сказать, что именно эти агенты делают в системе управления проектами (Jira) и корпоративной базе знаний (Confluence).

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

Оказалось, что один из агентов, который должен был заниматься исправлением ошибок в коде, регулярно запрашивал доступ к финансовой документации по проекту. В результате анализа мы выяснили, что это происходило не из-за промпт-инъекций, а из-за обобщенной формулировки задачи в исходном промпте. Это классический пример избыточных привилегий. Благодаря системе для защиты ИИ-агентов получилось это увидеть и скорректировать поведение агента до того, как произошла утечка.

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

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

Три момента, которые меняют подход к ИИ

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

• Первый — когда ИТ-директор впервые видит в дашборде реальную картину того, какие данные запрашивают агенты и куда они их передают. Это всегда отрезвляет. Оказывается, что многие представления о безопасности были иллюзией.
• Второй — когда мы показываем, что часть действий можно автоматически блокировать, не полагаясь на дисциплину сотрудников и не замедляя разработку. Это снимает огромный пласт напряжения между командой информационной безопасности и разработчиками.
• Третий — когда CTO понимает, что с таким уровнем контроля он может внедрять новые ИИ-функции без бесконечных согласований с безопасностью. Система становится не стоп-фактором, а энтузиастом инноваций.

Что меняется после выстраивания контроля

Когда контроль над ИИ-агентами выстроен, компания выходит из режима «надеемся, что все работает» и переходит к управляемой прозрачности.

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

Действия агентов становятся наблюдаемыми в реальном времени, а аномалии — управляемыми. Чувствительные данные перестают «утекать по умолчанию», потому что на уровне архитектуры появляются механизмы их фильтрации и ограничения.

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

Для службы безопасности это означает готовность к аудиту и соответствию требованиям регуляторов. Для бизнеса — возможность масштабировать использование ИИ без риска неконтролируемых последствий.

И в этот момент ИИ-агент перестает быть «черным ящиком» внутри компании. Он становится таким же управляемым элементом инфраструктуры, как и любые другие критически важные системы.