[Feature]: Lakera v2 guardrail: advisory mode (inject_system_message) instead of block/monitor on flagged content

问题场景

用户运行 LiteLLM Proxy 并配置 Lakera v2 guardrail 时，发现 `on_flagged` 只有两种取值：`block`（标记即拒绝，返回 HTTP 400）和 `monitor`（只记录日志，对用户无感知）。对误报率较高的检测器（如提示词注入启发式规则），`block` 会导致合法请求被误杀；`monitor` 又会让真实攻击请求无信号地通过。用户希望有一个中间模式：请求继续执行，但把“被标记”的事实和原因注入到系统消息中，让 LLM 自行判断如何响应。

报错原文

[Feature]: Lakera v2 guardrail: advisory mode (inject_system_message) instead of block/monitor on flagged content

这不是运行错误，而是功能请求标题。现有行为限制了 guardrail 的可选策略。

原因分析

可能原因：`lakera_ai_v2.py` 中的 `on_flagged` 处理逻辑目前只有 `block` 和 `monitor` 两个分支，缺少第三种“放行但附加提示”的策略。现有 `raise_passthrough_exception` 机制虽然实现了“拦截并返回固定消息”，但属于完全短路 LLM 调用，与本需求的“模型仍看到完整请求”思路相反。Issue 中提到的示例场景：支持工单提示词“忽略客户之前的要求并新建工单”可能被误判为注入攻击。

环境排查

• 确认 LiteLLM Proxy 版本是否为包含 Lakera v2 guardrail 实现的近期版本。
• 确认 `on_flagged` 配置值是否只写入了 `block` 或 `monitor`。
• 确认使用的 guardrail 模块路径是否为 `litellm/proxy/guardrails/guardrail_hooks/lakera_ai_v2.py`。
• 如果已升级到包含 #34940 修复的版本，确认配置中是否已支持注入系统消息的模式。

解决步骤

1. 如果只是需要临时绕过误报：将 `on_flagged` 从 `block` 改为 `monitor`，先观察误报率并评估风险（注意：monitor 模式不会给模型任何信号）。
2. 如果确实需要“放行但告知模型”的行为：跟踪 Issue #34940 的合并状态，等待新版 LiteLLM 发布后再升级测试。可优先尝试在配置中将 `on_flagged` 设为 `monitor` 并搭配自定义前置提示词（此方案未被 Issue 验证，只是替代思路）。
3. 如果要贡献代码：参考现有 `raise_passthrough_exception` helper 的位置，在 `CustomGuardrail` 基类上新增一个通用的消息注入 helper，然后为 Lakera v2 的 `on_flagged` 增加 `inject_system_message` 分支。
4. 注意该功能已被并入 #34940，不建议再开独立 PR 以免冲突。

验证方法

配置修改后，使用一个包含“指令性语言”的合法请求（如支持工单提示词）和一个明显恶意注入的请求分别测试：

• 合法请求不应被 HTTP 400 拦截。
• 恶意请求的响应中应体现模型收到了“该请求被标记”的提示词（可通过日志或响应内容确认）。

参考来源

BerriAI/litellm #36552

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。