ИИ уже используется в компаниях шире, чем его видит ИБ. Сотрудники работают с публичными нейросетями, разработчики подключают 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 году? Если компания сегодня почти не контролирует использование ИИ, какие три шага нужно сделать в первую очередь?
Регистрация и подробности — на официальном сайте организатора.
