План действий, если поддержка показала чужой секрет

Если бот поддержки показал пароль или чужие данные, остановите опасные действия, отзовите затронутый секрет и проверьте журналы доступа. Я разбираю, как оценить последствия и восстановить работу, не принимая сам факт инъекции за доказательство полного взлома.

Что считать инцидентом после prompt injection

Prompt injection — ситуация, в которой входной текст или внешний документ влияет на поведение LLM вопреки замыслу приложения. Я не называю это «командой, которая переписывает системный промпт»: модель не обязана считать такую фразу привилегированной инструкцией. Риск возникает на стыке обработки контента и действий приложения. Прямой запрос и скрытая инструкция в странице или вложении — разные пути; последствия зависят от того, какие данные и инструменты доступны. OWASP описывает диапазон от неверного ответа до раскрытия чувствительных данных или вызова доступной функции. Поэтому сама подозрительная фраза ещё не доказывает, что база данных была прочитана. Важная разница: модель может выдать ошибочную фразу без доступа к исходным данным, а приложение может выполнить разрешённое ему действие после такого ответа. В разборе я отдельно фиксирую влияние на текст и влияние на системы. Этот разрез сразу показывает, кого подключать к расследованию: владельца чата, API, хранилища или процесса поддержки. В рабочем отчёте я называю источник, путь и наблюдаемое последствие отдельно. Не пишу «агент слил базу», если подтверждён только один ответ: такая формулировка пугает руководство, но не помогает выбрать действие. Точность здесь важнее эффектного заголовка.

В черновике фигурирует студия «Эталон Групп». Оставляю её только как условный сценарий, а не как реальный случай: подтверждённых сведений об инциденте здесь нет. Если ответ поддержки содержит пароль, ключ или чужую запись, я сначала выясняю маршрут этих данных: они могли попасть в контекст, прийти от подключённого инструмента или добавиться приложением уже после ответа модели. Для исходной инфраструктуры подходит аудит информационной безопасности. Общая профилактика описана в разборе защиты API от инъекций; здесь речь именно о действиях после возможного раскрытия. Чтобы статья не повторяла общий материал о предотвращении инъекций, здесь я не разбираю настройку фильтра по сигнатурам и не приписываю студии реальные потери. Условный пример нужен только для маршрута расследования: секрет замечен в ответе — владелец сохраняет доказательство, проверяет путь данных и решает, какие права отозвать. Так мы обсуждаем проверяемые действия, а не придумываем драму вокруг имени.

• Зафиксировать точный ответ и время
• Проверить, был ли вызван инструмент
• Отделить попытку атаки от успешного доступа

Что отключить и отозвать в первую очередь

Сначала я прекращаю действия, которые способны расширить ущерб. Если агент может читать записи, отправлять письма, менять данные или вызывать внешние функции, временно отключаю именно эти инструменты либо перевожу сценарий на ручную обработку. Останавливать всю поддержку нужно только тогда, когда безопасный режим нельзя включить отдельно. Это сохраняет обычный канал для заявок и одновременно убирает опасную возможность. В плане реагирования NIST важны подготовка, сдерживание, восстановление и последующее улучшение; это рабочий цикл, а не команда «перезапустить и забыть». Если нельзя точечно приостановить инструмент, назначаю временный ручной маршрут и предупреждаю владельца поддержки, какие запросы он должен обработать. Перед отключением отмечаю, какие функции затронуты, кто разрешил переключение и как вернуть их обратно. Иначе временный запрет незаметно становится постоянной аварийной настройкой; она потом живёт дольше, чем причина, по которой её включили. Для переключения заранее нужен ответственный и условие возврата: иначе разные смены включат и отключат функцию по своему усмотрению. Если несколько инструментов используют один ключ, сначала выясняю их зависимости и согласую момент ротации с владельцем сервиса, сохраняя возможность быстро отозвать старый ключ.

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

• Приостановить рискованные инструменты
• Отозвать раскрытый секрет
• Проверить связанные учётные записи

Как установить масштаб возможной утечки

После сдерживания я строю короткую временную линию: запрос пользователя, найденные документы, обращения к инструментам, ответ модели и действия приложения после него. Для каждого шага отмечаю источник и учётную запись. Ищу не только текст ответа, но и чтение записей, выгрузки, отправленные письма и изменения состояния. Если модель лишь повторила инструкцию атакующего, это один результат; если приложение выполнило запрос к данным или отправило их наружу — другой. На этом этапе полезно сверить журналы API и доступа к хранилищу; общий разбор рисков утечки через API помогает не путать текстовый ответ с фактическим обращением к сервису. Сверяю время ответа с журналом сервиса, который должен был предоставить сведения. Уточняю, какие пользователи или процессы могли запустить тот же поиск, и проверяю, ограничивал ли сервис выдачу по владельцу записи. Если из ответа неясно, какая именно строка была использована, запрос уточняю у владельца данных по безопасному каналу. Не отправляю полный пароль или персональную запись в новую заявку «для удобства проверки».

Восстанавливаю, что именно могло быть доступно: отдельный пароль, токен, данные одной карточки или целая выборка. Проверяю права учетной записи, параметры поиска, ограничения результата и журнал конкретного хранилища. Отсутствие записи в журнале не доказывает, что обращения не было: сначала выясняю, какие события система вообще сохраняла и как долго. При этом нельзя объявлять утечкой каждый неудачный запрос или каждую странную фразу. В отчёте я разделяю подтверждённые действия, возможный охват и неизвестное; это защищает от двух одинаково дорогих ошибок — занижать масштаб и фантазировать о худшем. Если система не сохраняла события чтения или отправки, записываю этот пробел отдельно и не подменяю его догадкой. Восстановить точный масштаб задним числом может быть невозможно; тогда решение о ротации, уведомлении и временном ограничении принимают с учётом наихудшего подтверждаемого охвата. На будущее добавляют журнал фактов операций без тел содержимого: субъект, действие, объект в допустимом виде и итог проверки прав. По каждой затронутой записи проверяю не только факт выдачи, но и аудит самого сервиса: авторизацию, объём результата и последующие изменения. Чувствительные данные классифицирует их владелец, а специалист поддержки получает лишь ту часть сведений, которая нужна для расследования. Так не создаём новую копию инцидента.

• Сопоставить запросы и вызовы функций
• Проверить фактическое чтение и отправку
• Записать подтверждённый охват отдельно от гипотез

Где разорвать путь от текста к данным

Для оценки риска я проверяю сразу три условия: в одном сценарии не должны бесконтрольно соединяться приватные данные, недоверенный контент и канал передачи наружу. Это не формула, которая обещает безопасность, а удобная карта проверки. Если агент читает документ от пользователя, может получить конфиденциальную запись и умеет отправить письмо, инъекция способна связать эти возможности. Если убрать или сузить хотя бы одно звено, последствия обычно проще ограничить. В базе знаний этот принцип описан как «смертельная тройка»; на практике я отмечаю, какие из трёх возможностей реально есть у каждой функции, а не только у диалогового окна. Я раскладываю поток по шагам: откуда пришёл контент, где он хранится, что модель может запросить и куда приложение может передать результат. Недоверенным считается и текст самого пользователя, и материал из письма, базы знаний или внешнего документа. Никакая метка «инструкция компании» не должна появляться у такого содержимого только потому, что его подложили рядом с системным сообщением. У разных источников разные доверительные границы: сотрудник может отправить ошибочный запрос без злого умысла, а вложение может содержать намеренно подготовленный текст. Для расследования это важно: проверяю оба маршрута, даже если исходная фраза пришла из одного чата. Инструкции не становятся безопасными только из-за знакомого оформления.

Полномочия задаются приложением, а не просьбой модели. Инструмент должен сам проверять, разрешено ли текущему пользователю читать конкретную запись, и принимать только ожидаемые типы аргументов. Учётные данные интеграции хранит серверная часть; токен не нужно вставлять в текст, который получает модель. Для опасных изменений добавляют подтверждение человеком, а для чтения — фильтр по правам и ограничение объёма результата. Это конкретные меры из базы: отделять инструкции от данных, проверять вывод и выдавать минимальные привилегии. В правилах для агентных сценариев я отдельно разбираю, почему доступ к системе нельзя выдавать «на всякий случай». Речь не о том, чтобы запретить модели любую полезную работу. Дайте ей возможность запросить ограниченную операцию, а приложение пусть повторно проверит идентичность пользователя и право на конкретную запись. Если действие меняет данные, отправляет сообщение или раскрывает чувствительную информацию, отделите подготовку черновика от окончательного выполнения. Подтверждение должно показывать человеку само действие и его адресата, иначе кнопка становится формальностью.

• Недоверенный текст хранить как данные
• Права проверять на стороне приложения
• Секреты не передавать в контекст
• Опасные действия подтверждать отдельно

Как безопасно восстановить поддержку

После отзыва секрета я устраняю причину его доступности. Убираю пароль из контекста и истории, если он там оказался; прекращаю повторную подачу старых диалогов и документов; проверяю тестовые стенды, снимки и диагностические выгрузки, куда мог попасть тот же текст. Если пароль хранится в приложении для работы интеграции, приложение использует его самостоятельно, а модели передаёт только результат разрешённого действия. Секрет вне текста модели всё ещё требует защиты: инструмент с широким доступом может получить те же данные по вызову. Поэтому одного перемещения переменной в хранилище недостаточно. Сверяю историю и кэш с тем, что увидел пользователь: некоторые приложения сохраняют контекст отдельно от основного диалога. Если в тесте использовали настоящий секрет, удаляю тестовую копию и проверяю, что она не попала в отчёт или резервную диагностику. Для замены выбираю новый уникальный секрет, проверяю доступ сервисной учётной записи и отмечаю, где старое значение ещё могло быть задано вручную.

Затем проверяю новый маршрут на обычном запросе и на запрещённом. Поддержка должна продолжать отвечать на безопасные вопросы, но отказать в чтении чужой карточки и не выполнять изменение без проверки прав. Я также проверяю, очищены ли копии чувствительного ответа из тестовых логов и доступны ли журналы администратору, который разбирает случай. Хранить все диалоги целиком ради «полной наблюдаемости» — так себе идея: такие логи становятся ещё одним местом утечки. Оставляйте только нужные события, ограничивайте доступ и редактируйте секреты до записи. Больше текста в журнале не означает больше контроля. Если исправление требует отключить функцию полностью, так и пишу владельцу: временно недоступен конкретный вид операции, обычные консультации продолжаются. Не маскирую отказ выдуманным ответом и не возвращаю инструмент только ради красивого показателя доступности. Критерий возврата заранее понятен: права проверяются приложением, секрет не раскрывается в текстовом контексте, а подтверждение и аудит работают в нужном маршруте. Если уведомлять пользователей о временном ограничении, объясняю конкретно: какая операция недоступна, какие альтернативы остаются и кто принимает срочные обращения. Не обещаю, что инцидент не повторится; сообщаю, что проверено и какой контроль добавлен. Это честнее и полезнее, чем объявлять систему «полностью защищённой».

• Удалить секрет из контекста и копий
• Ограничить доступ к журналам
• Проверить безопасный и запрещённый сценарии

Как проверить исправление и закрыть разбор

Я проверяю не только слова вроде «игнорируй предыдущие инструкции», но и реальные границы приложения: прямой запрос, вложенный документ, результат поиска и ответ инструмента. Для каждого сценария задаю ожидаемое поведение: какие данные можно показать, какие поля скрыть, какой инструмент вызвать, где требуется подтверждение. Затем тестирую полезный обычный запрос рядом с атакующим, чтобы фильтр не превратил поддержку в кирпич. OWASP рекомендует регулярные adversarial-тесты и проверку границ доверия; при этом сама фильтрация не даёт доказательства, что все варианты инъекции пойманы. Тестовые примеры берут из реальных границ приложения, но сами данные должны быть синтетическими: тест не должен повторно разнести настоящий пароль по средам. Для каждого ожидаемого отказа задаю также разрешённый соседний кейс, иначе чрезмерно широкий фильтр выглядит успешным, просто запретив работу. Отдельно проверяю, что результат функции не становится инструкцией для следующего шага и не выполняет побочное действие без контроля. Для каждого теста сохраняю ожидаемый результат и фактическое действие, а не только оценку модели. Например, отказ считается успешным, когда приложение не читает чужую запись и не отправляет данные; вежливая фраза «не могу помочь» сама по себе ничего не доказывает. Проверка должна охватывать границу доступа.

В конце фиксирую причину, владельца исправления и дату повторной проверки после изменения модели, инструмента или источника данных. Проверяю, что технические журналы позволяют восстановить факт вызова без записи лишнего содержимого, а уведомления доходят до ответственного сотрудника. Обязательного единственного формата мониторинга для всех приложений нет: объём наблюдения выбирают по риску и требованиям хранения данных. Если обнаружено чтение или отправка информации, дальше действую по внутреннему плану реагирования и договорам, а не по универсальному совету из статьи. Защитный фильтр — хороший досмотрщик; охранником всей архитектуры он не становится. Критерии пересмотра лучше привязать к конкретному изменению: появился новый инструмент, источник документов, тип секрета или маршрут отправки — сценарии проверяют заново. Владелец фиксирует результат, известные ограничения и путь эскалации, если снова появляется чувствительный ответ. Записи о закрытии должны отвечать на простой вопрос: что именно подтвердили, что изменили и кто проверит это после следующего обновления.

• Проверить прямой и косвенный ввод
• Повторить тесты после изменения доступа
• Записать владельца и срок пересмотра
• Закрыть подтверждённые последствия отдельно

Частые вопросы