Комментарии 3
Что там про инъекции? Какая защита. Как понял, что пользователь пишет, создается тикет, который идет обработкой LLM. И технически тут может отлично отработать инъекция без доп средств безопасности.
Вы используете mcp для доступа к логам, выгрузкам и т.д. Данные доступ как то по ролям ограничиваете? Какие данные могут быть выгружены и т.д.
Проходят ли логи этап анонимизацииперед тем, как попасть в контекст ll,, чтобы модель случайно не закешировала или не слила эти данные в других диалогах?
Про убийства БД. Вы говорите, что используете селекты для данных с БД. Это реплика БД надеюсь, не продовая? Есть какие то ограничения или валидации запросов, что бы не парализовать базу?
Спасибо за вопросы - по сути всё верно поняли, риски есть. Кратко, как у нас устроено.
Инъекции. Текст тикета действительно попадает в языковую модель, и в описании теоретически можно попытаться "переписать" её поведение. Но в автоматической обработке Jira модель не крутится в свободном цикле "сама решает, что делать дальше" - порядок шагов задан заранее: проверка тикета - выбор маршрута (логи, документация, база) - сбор фактов - формулировка ответа - публикация комментария.
Данные из логов и базы модель не "вытягивает сама по тексту тикета" - их собирают отдельные сервисы. В финальный запрос попадают уже проверенные факты, а не всё подряд. Комментарий в Jira собирается по шаблону, перед отправкой из текста вырезается явно опасное (например, команды изменения базы).
В чате у модели тоже не произвольный доступ ко всему - только заранее описанный набор действий: поиск по документации, разбор логов, запрос к базе и т.д.
Полной защиты от таких атак нет - мы снижаем ущерб тем, что даже "обманутая" модель не может одним текстом тикета выполнить произвольный запрос или опубликовать что угодно.
Доступ через MCP. Система живёт во внутренней сети, снаружи недоступна. Пользуются ею сотрудники команды - разработка, поддержка, аналитика и.тд.
MCP здесь не "прямой провод ко всей инфраструктуре", а прослойка к нашим сервисам. К базе можно обратиться только к заранее разрешённым базам и таблицам, только на чтение, с ограничением числа строк. К логам - только через сервис анализа и только для микросервисов из каталога, а не к произвольному хранилищу.
Персональные данные. Мы не обезличиваем всё перед каждым вызовом модели. При разборе инцидента ей нужны конкретные идентификаторы - иначе ответ бесполезен.
Что делаем:
в модель не отдаём сырые логи целиком - только сжатую таблицу ошибок и короткое резюме;
в логах работы сервисов маскируем чувствительные данные;
Модели используются только для ответа на запрос, без дообучения на наших тикетах и логах. Один диалог не "перетекает" в другой.
База данных. Запросы идут в реплику для чтения, не в основную базу. Дополнительно: роль только на чтение, белые списки таблиц, проверка текста запроса, лимит строк и таймауты на уровне сервиса.
Основную базу таким запросом не положить. Реплику теоретически можно перегрузить тяжёлым запросом - для этого как раз стоят ограничения сверху.
Вот именно так AI и должен входить в процессы не заменять людей, а убирать рутину и помогать быстрее находить решения.
Жизнь после RAG: MCP, логи и автоматический анализ тикетов Jira