Tool Output Redaction в 2026: как скрывать чувствительные данные до того, как их увидит модель и trace

Короткая версия

Хорошая tool-output redaction policy в 2026 обычно определяет:

1. Какие поля модель вообще не должна видеть
2. Какие поля можно показывать только в masked виде
3. Какие raw values можно хранить только в restricted zone
4. Какой safe summary нужен вместо полного payload
5. Какие redaction rules привязаны к конкретному tool type

Что особенно важно

• редактировать output лучше до prompt assembly, а не только до логирования;
• разные tools требуют разные safe views;
• reviewer UI и traces не должны автоматически получать raw payload;
• redaction без schema discipline быстро расползается по ad hoc regex-правилам.

Достаточно ли замаскировать tool output только в observability-логах?

1. Tool output опасен из-за fan-out

Один payload может попасть сразу в несколько мест:

• в следующий model step;
• в trace span;
• в retry state;
• в approval packet;
• в human review queue;
• в incident archive.

Именно поэтому redaction на выходе tool-а почти всегда выгоднее, чем попытка чистить всё позже в каждом downstream слое.

2. Safe view важнее raw payload

Для большинства tool-ов полезно проектировать два представления:

Raw output

Полный ответ для ограниченного forensic/debug use.

Safe output

Сокращённая и очищенная версия для:

• prompt assembly;
• orchestration logic;
• обычной observability;
• reviewer summary.

3. Redaction лучше строить schema-first

Особенно полезно заранее помечать поля как:

• allowed;
• masked;
• restricted;
• drop entirely.

Такой подход лучше, чем только regex-based cleanup, потому что:

• он воспроизводим;
• легче тестируется;
• не зависит от случайного формата строки;
• хорошо работает для JSON и typed API responses.

4. Review и observability тоже требуют отдельного safe layer

Даже если модель видит safe output, нельзя автоматически считать, что:

• reviewer должен видеть raw payload;
• traces можно хранить без ограничений;
• approval packet может подтянуть полный tool response.

Часто полезно иметь три слоя:

1. model-safe output;
2. reviewer-safe output;
3. restricted raw output.

5. Что особенно часто ломают команды

Same payload everywhere

Один и тот же JSON идёт в модель, trace, review UI и incident storage.

Regex-only masking

Правила хрупкие и пропускают structured sensitive fields.

No per-tool policy

CRM, browser и payment tools обрабатываются одинаково.

Raw output in retries

Повторные шаги снова и снова таскают по pipeline чувствительные данные.

No ownership for redaction rules

Никто не отвечает за поддержание safe views после изменения tool schema.

6. Какие метрики полезны

Минимальный dashboard обычно включает:

• percent of tool calls with schema-aware redaction;
• raw-to-safe size reduction ratio;
• review packets containing restricted fields;
• traces blocked by sensitive-output policy;
• redaction misses found in audits;
• tools without declared output policy.

Пример output policy

tools:
  billing_lookup:
    fields:
      customer_email: masked
      last4: masked
      fraud_notes: restricted
      refund_eligible: allowed
      order_status: allowed

Простой redaction hook

def redact_tool_output(tool_name, payload, policy):
    tool_policy = policy["tools"][tool_name]["fields"]
    safe = {}
    for field, value in payload.items():
        mode = tool_policy.get(field, "drop")
        if mode == "allowed":
            safe[field] = value
        elif mode == "masked":
            safe[field] = "***"
    return safe

Практический совет: проектируйте tool output так, будто downstream модель, trace store и review queue по умолчанию небезопасны для raw payload. Тогда redaction становится базовым свойством архитектуры, а не поздней косметикой.