ИИ уже используется в компаниях шире, чем его видит ИБ. Сотрудники работают с публичными нейросетями, разработчики подключают AI-ассистентов, SaaS получает AI-функции, а корпоративные помощники — доступ к документам, API и внутренним системам. В результате часть AI-сценариев появляется быстрее, чем компания успевает их обнаружить и включить в привычный контур безопасности.
Пока ИИ только отвечает на запросы, многое можно контролировать на уровне данных, промптов и доступа к моделям. Но с появлением AI-агентов задача меняется: модель уже может обращаться к MCP-серверам, вызывать инструменты и выполнять реальные действия от имени пользователя или системы. Одного LLM/AI Firewall в такой архитектуре уже может быть недостаточно.
В эфире AM Live разберём, как обнаружить Shadow AI и выстроить контроль от запроса к модели до действий агента. Обсудим возможности и границы LLM Firewall, защиту MCP и tool calls, управление правами AI-агентов, интеграцию с IAM, PAM, DLP, SIEM и API Security. И отдельно поговорим о том, кто внутри компании должен отвечать за этот новый контур безопасности.
- ИИ уже внутри, но видит ли его ИБ
- Можно ли вообще составить полный реестр ИИ, который используется в компании, или часть сервисов всё равно останется невидимой?
- Хватит ли SWG, CASB, DLP, EDR и контроля API, чтобы обнаружить Shadow AI, или нужен отдельный AI Discovery?
- Что делать с несанкционированными AI-сервисами: блокировать или контролировать?
- Допустим, мы обнаружили сотню AI-сервисов. По каким трём признакам понять, какие из них проверять и ограничивать в первую очередь?
- Что сегодня считать AI-активом компании: только модель или всю цепочку - от промпта и RAG до памяти, API и инструментов агента?
- Когда недостаточно защищать только доступ к модели и приходится отдельно защищать саму модель, её конфигурацию, инфраструктуру и цепочку поставки?
- Если модель выдала опасный для бизнеса ответ, кто должен первым получить сигнал и иметь право остановить систему?
- В какой момент AI-риск становится заметно выше: когда модель получает внутренние данные, память, доступ к API - или когда начинает действовать без подтверждения человека?
- Модель отвечает. Агент действует
- Какие функции сегодня обязательны для полноценного LLM / AI Firewall?
- Как пилотировать LLM Firewall, чтобы проверить его в реальной инфраструктуре, а не на красивом демо?
- Можно ли вообще обещать защиту от prompt injection или честнее говорить только о снижении риска успешной атаки?
- Что LLM Firewall не видит, если стоит только между приложением и API модели?
- LLM Firewall должен сам принимать решение allow / deny или передавать AI-контекст в существующие IAM, DLP, PAM, SIEM и API Security?
- Нужно ли журналировать каждый промпт и ответ - или так компания сама создаёт хранилище самых чувствительных данных?
- Что должен контролировать Agent Runtime Security?
- Нужна ли AI-агенту собственная цифровая идентичность или он всегда должен действовать от имени пользователя?
- Можно ли давать агенту постоянные привилегии или права должны выдаваться под конкретное действие и на ограниченное время?
- Как проверять MCP-серверы и инструменты, которым агент получает право доверять?
- Какие действия агенту нельзя разрешать без подтверждения человека?
- Что вы считаете следующей большой поверхностью атаки в AI-системах?
- Итоги и прогнозы
- Через два-три года LLM Firewall и Agent Runtime Security останутся отдельными классами решений или их функции уйдут в DLP, SWG, IAM/PAM, API Security и крупные security-платформы?
- Какое решение в AI Security, принятое сегодня, с наибольшей вероятностью окажется ошибкой к 2029 году?
- Если компания сегодня почти не контролирует использование ИИ, какие три шага нужно сделать в первую очередь?
Приглашенные эксперты:
|
|
Вячеслав Валькович Руководитель развития облачных AI-сервисов, ITGLOBAL.COM, корпорация ITG |
 |
Никита Беляевский Руководитель отдела аудита Безопасности ИИ-систем, HiveTrace |
 |
Денис Каракай Владелец продукта Гарда AI Security, «Гарда» |
Модераторы:
|
|
Илья Самофеев CEO,red_mad_robot |
