Block Generation Security Note

1. Область чувствительности данных

Во входе могут оказаться:

  • внутренние инструкции;

  • domain-specific правила;

  • черновые product policies;

  • фрагменты prompt logic, которые не предназначены для широкого распространения.

Поэтому input следует рассматривать как потенциально чувствительный authoring контент.

2. Основные риски

Ключевые риски:

  • пользовательский prompt может содержать конфиденциальные формулировки;

  • внешний provider видит содержание инструкции;

  • generated output может содержать нежелательные, небезопасные или недостаточно проверенные фрагменты;

  • логирование AI request/response может случайно зафиксировать чувствительный контент.

3. Граница внешнего провайдера

Важно фиксировать:

  • prompt payload уходит во внешний provider boundary;

  • политика retention определяется выбранным provider;

  • TextFoundry не должен документироваться так, как будто provider является внутренней доверенной подсистемой.

4. Хранение и retention

Нужно исходить из того, что:

  • содержимое prompt может покидать локальную систему;

  • retention policy должна быть проверена для каждого используемого провайдера;

  • AI payload не должен сохраняться локально без необходимости и явной причины.

5. Доступ и логирование

Обязательные практики:

  • не логировать API keys;

  • не логировать чувствительные prompt payloads целиком;

  • не сохранять secrets в traces или status messages;

  • не путать пользовательские данные и безопасные технические метрики.

6. Обязательные меры контроля

Базовые меры:

  • не отправлять секреты в prompt;

  • review output до сохранения;

  • считать external provider недоверенной внешней границей;

  • сохранять human-in-the-loop workflow;

  • не публиковать generated block автоматически.

7. Специфические product-риски

Особые риски для этой функции:

  • автор может воспринять AI draft как уже проверенный контент;

  • generated block может попасть в библиотеку с недостаточной ручной проверкой;

  • revision mode может непреднамеренно изменить важные policy-formулировки.

Меры:

  • explicit review-before-save;

  • отсутствие auto-publish;

  • ручная проверка важных блоков отдельно.