Перейти к основному содержимому

Передача данных в LLM и меры защиты

Какие данные CodeGraph могут попасть в запрос к LLM-провайдеру и как настроить DLP, маршрутизацию, аудит и профиль развёртывания.

Корпоративная эксплуатация

CodeGraph отправляет выбранному провайдеру system_prompt и user_prompt. В зависимости от сценария в них могут находиться запрос пользователя, фрагменты кода, сформированные сводки или структурированные данные CPG. Перед вызовом провайдера runtime применяет настроенные проверки политики и DLP. Состав передаваемых данных определяется сценарием и действующей DLP-политикой.

Фактический путь запроса

Запрос проходит следующие этапы:

  1. Вызывающий сценарий передаёт system_prompt, user_prompt, контекст операции и настройки провайдера.
  2. Проверка политики определяет действующие ограничения и наличие согласования.
  3. DLP до запроса сканирует объединённые тексты инструкций и запроса.
  4. Настроенное действие DLP — BLOCK, MASK, WARN или LOG_ONLY.
  5. Маршрутизация AI FinOps выбирает целевого провайдера.
  6. CodeGraph передаёт провайдеру подготовленные тексты инструкций и запроса.
  7. В обычном generate DLP проверяет ответ перед возвратом вызывающему коду.

SecureLLMProvider выполняет эту последовательность для сценариев, которые вызывают провайдера через обёртку. Сканер обрабатывает system_prompt и user_prompt. Дополнительные аргументы **kwargs передаются провайдеру отдельно. Для вложений и других данных в этих аргументах настройте проверку в вызывающем сценарии.

В generate DLP проверяет готовый ответ и применяет маскированный текст сканера перед возвратом вызывающему коду. Маскирование найденных совпадений применяется для всех меток действия, включая MASK. В generate_stream фрагменты передаются сразу, а после завершения потока DLP проверяет собранный ответ и регистрирует находки. Уже переданные фрагменты сохраняют исходный текст. Для проверки ответа до выдачи используйте обычную генерацию с настроенным DLP или накопление и фильтрацию потока в клиентском сценарии.

Сканирование запроса включают dlp.enabled и dlp.pre_request.enabled в конфигурации безопасности. При отключённом сканировании провайдер получает исходные тексты запроса.

В get_embeddings провайдер также получает тексты. Обёртка объединяет их для проверки DLP, применяет фильтрацию при наличии сканера и передаёт подготовленные тексты в target_provider.get_embeddings. Модель и маршрут векторных представлений (embeddings) настраиваются отдельно от генерации. Зафиксируйте адреса обеих операций в профиле развёртывания.

Что может пересечь границу провайдера

Что может пересечь границу провайдера
Данные Могут передаваться? Обязательная мера
Запрос пользователя и системные инструкции Да Ограничение цели, доступ, DLP и аудит.
Выбранные фрагменты кода или diff Да, если сценарий включил их в запрос Классификация, минимальная область данных, разрешённый профиль и DLP.
Символы, пути, находки и сводки из CPG Да Считать чувствительными инженерными данными, сокращать объём и журналировать.
Секреты, токены, учётные данные и регулируемые идентификаторы Не должны передаваться намеренно BLOCK или MASK, управление секретами и процесс инцидента.
Полное содержимое репозитория или базы Не прикладывается автоматически отдельным объектом Убедиться, что вызывающий сценарий не встроил его в system_prompt или user_prompt.
Ответ провайдера Возвращается через CodeGraph DLP после ответа, метаданные аудита и ограниченное хранение.

Профили развёртывания

Профили развёртывания
Профиль Граница передачи Решение оператора
Локальная модель Запрос остаётся в настроенной локальной среде выполнения модели. Проверить хост, хранение модели, журналы и локальный доступ.
Удалённый провайдер под управлением заказчика Тексты уходят на утверждённый адрес провайдера заказчика. Зафиксировать владельца, регион, хранение, обучение, шифрование и контакты для инцидента.
Публичный SaaS-провайдер Тексты покидают инфраструктурную границу заказчика. Требовать явную классификацию и согласование; передавать минимально необходимый контекст.

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

Поведение DLP

Настройте категории данных и действия сканера по руководству DLP. Применяются следующие действия:

  • BLOCK отклоняет запрос до вызова провайдера.
  • MASK заменяет найденные значения и передаёт изменённые тексты запросов.
  • WARN фиксирует обнаружение, но может разрешить запрос.
  • LOG_ONLY записывает событие и разрешает запрос.

При обнаружении совпадений сканер выбирает наиболее строгое действие из настроек совпавших категорий и pre_request.default_action. Порядок приоритета: BLOCK, MASK, WARN, LOG_ONLY. Например, категория с LOG_ONLY и действие по умолчанию WARN дают итоговое WARN.

WARN и LOG_ONLY передают исходный текст и регистрируют обнаружение. MASK заменяет совпадения с включёнными шаблонами и категориями. Для каждой категории чувствительных данных настройте шаблоны и проверьте их на контрольном значении. В запрос включайте контекст, необходимый для выбранной задачи.

Проверка перед пилотом

  1. Определите сценарии, которым разрешён провайдер, и поля запроса для каждого из них.
  2. Классифицируйте исходники, находки, пути, персональные данные, учётные данные и идентификаторы заказчика.
  3. Проверьте DLP до запроса и после ответа в действующей конфигурации.
  4. Для категорий высокого риска назначьте BLOCK или утверждённый MASK.
  5. Подтвердите адрес провайдера, арендатора, регион, сроки хранения, использование для обучения, шифрование и журналы доступа.
  6. Проверьте блокировку или маскирование на синтетическом контрольном секрете. Не используйте настоящие учётные данные.
  7. Убедитесь, что записи аудита содержат ограниченные метаданные, а не чувствительные запросы.
  8. Добавьте утверждённый профиль и подтверждения в пакет готовности к пилоту или релизу.

Если данные могли уйти провайдеру

  1. Остановите или перенаправьте затронутый сценарий.
  2. Сохраните идентификатор запроса и метаданные DLP и аудита, не копируя секрет в отчёт.
  3. Замените скомпрометированные учётные данные и выполните процедуру удаления или инцидента у провайдера.
  4. Найдите код, добавивший данные в запрос, и ограничьте передаваемые данные или измените политику.
  5. До восстановления маршрута повторите проверку с синтетическим контрольным значением.

Связанные материалы: Эксплуатация DLP и SIEM.

Сообщить об ошибке в документации