[Bug]: Prompt Injection Detection Issues

快速结论：这是 LiteLLM Proxy 内置 prompt injection 检测功能同时出现两类故障的场景——启用 heuristics_check: true 时同步相似度计算阻塞 FastAPI 事件循环，导致健康检查探针超时、K8s Pod 被重启；而 llm_api_check: true 因类继承错误从未真正执行。[Bug]: Prompt Injection Detection Issues 通常发生在配置了 detect_prompt_injection 回调的代理环境下，优先排查这两条代码路径。

适用环境：Issue 确认的运行环境为 LiteLLM Proxy，部署于 Kubernetes，使用默认 worker 数量（1）；配置项涉及 heuristics_check、llm_api_check、reject_as_response。Issue 未提供具体 Python、CUDA、显卡或依赖版本信息。

最快修复方案：暂无确认的一步修复方案。Issue 评论给出的临时规避手段是：不要依赖 llm_api_check（它不会运行），如确需 LLM 检测，请自行将其接为真正的 CustomGuardrail 回调，而不是通过 prompt_injection_params 启用。

注意事项：评论指出仅把 check_user_input_similarity 移到 asyncio.to_thread() 只能解决事件循环饥饿，无法解决 SequenceMatcher 本身的 O(n*m) 复杂度；超长输入仍会长时间占用线程池 worker，建议同时限制进入关键词循环的输入长度。上述线程池方案属于评论中的建议，尚未在 Issue 中确认合入。

问题场景

用户在 LiteLLM Proxy 中启用内置 prompt injection 检测回调 detect_prompt_injection，并配置 prompt_injection_params 后触发问题：

配置 heuristics_check: true 时，单次请求耗时 60–90 秒，事件循环被阻塞，所有其他请求无法处理，Kubernetes 的 liveness/readiness 探针失败，Pod 被重启。
配置 heuristics_check: false 且 llm_api_check: true 时，LLM API 检测路径完全不可达，请求不经过任何基于 LLM 的检测。

问题代码位于 litellm/proxy/hooks/prompt_injection_detection.py。

报错原文

[Bug]: Prompt Injection Detection Issues

Request → heuristics check starts → event loop blocked →
health probes timeout → K8s marks pod unhealthy → pod restart

# Problem 2
async def during_call_hook(self, ...):
    for callback in litellm.callbacks:
        if isinstance(callback, CustomGuardrail):  # ← Only CustomGuardrail!
            guardrail_task = callback.async_moderation_hook(...)

原因分析

Issue 指出两个独立缺陷：

启发式检测阻塞事件循环。async_pre_call_hook 中直接调用同步方法 check_user_input_similarity()，其中包含三层嵌套循环并对每个关键词执行 SequenceMatcher，属于 CPU 密集型同步调用。在异步函数内执行会阻塞整个 FastAPI 事件循环，健康检查端点无法响应，进而被 K8s 判定为不健康并重启 Pod。
LLM API 检测路径不可达。_OPTIONAL_PromptInjectionDetection 继承了 CustomLogger，但 async_moderation_hook（含 llm_api_check 逻辑）只在回调对象是 CustomGuardrail 实例时才会被 during_call_hook 调用。类继承不匹配导致该分支永不执行，且没有任何报错提示，属于静默失效。

评论补充认为，类继承不匹配是更严重的问题，因为用户以为 llm_api_check: true 已提供防护，实际完全没有 LLM 检测，静默失效的 guardrail 比没有 guardrail 更危险。

环境排查

确认 LiteLLM Proxy 版本及 litellm/proxy/hooks/prompt_injection_detection.py 的实际内容，核对类定义与 hook 调用逻辑是否已被修复。
检查 litellm_settings.callbacks 是否包含 detect_prompt_injection，以及 prompt_injection_params 中 heuristics_check 和 llm_api_check 的取值。
确认运行环境的 worker 数量（Issue 场景为默认值 1），worker 数越少，事件循环阻塞影响越明显。
若部署在 Kubernetes，检查 liveness/readiness 探针的超时设置与 Pod 重启记录，观察是否与请求高峰期相关的重启。
确认是否存在超长用户输入进入启发式检测，因为 SequenceMatcher 复杂度与输入长度直接相关。

解决步骤

先判断当前使用的是哪条检测路径：若依赖 llm_api_check 提供防护，应按评论建议停止依赖该配置，改为接入真正的 CustomGuardrail 回调；这是一种规避方式，不是 Issue 中已验证的官方修复。
若必须使用启发式检测，可优先尝试按评论建议将 check_user_input_similarity 移入 asyncio.to_thread()，避免阻塞事件循环；同时限制进入关键词循环的输入长度（例如只对用户输入的末尾 N 个字符执行启发式检查），以控制最坏情况延迟。
在修复或规避完成前，若部署在 Kubernetes，可考虑临时放宽 liveness/readiness 探针阈值或增加 worker 数量以降低单次阻塞导致 Pod 重启的概率；这类调整只是缓解，不能根治问题。
跟进上游修复进度：Issue 已被标记并关闭，但评论显示问题在一段时间内仍存在，需确认所用版本是否已合入修复，必要时升级到包含修复的版本。

验证方法

启用 heuristics_check: true 后发起一次请求，同时调用健康检查端点：若探针能在常规超时内正常返回，说明事件循环不再被阻塞。对 llm_api_check 路径，可将 llm_api_fail_call_string 设为 UNSAFE 并发送明确的注入型输入，确认请求确实被拦截；若仍放行，说明 LLM 检测路径依然未执行。同时检查 K8s 中 Pod 是否还会出现与探针超时相关的重启。