docs(enkryptai): drop unsupported deployment_name, detectors, block_on_violation

[devin-ai-integration]

Summary

docs/proxy/guardrails/enkryptai.md documented three litellm_params that the EnkryptAI guardrail never uses: deployment_name ("Sent via X-Enkrypt-Deployment header"), detectors (per-detector config sent to the API), and block_on_violation: false ("log violations but don't block", a "Monitor Mode" section).

In litellm/proxy/guardrails/guardrail_hooks/enkryptai/enkryptai.py, EnkryptAIGuardrails.__init__ only reads api_key, api_base and policy_name; everything else lands in self.optional_params and is never consumed. _call_enkryptai_guardrails posts payload = {"text": prompt} with the apikey header and an optional x-enkrypt-policy header, so no X-Enkrypt-Deployment header or detector config is ever sent. The pre/post/during-call hooks unconditionally raise ValueError(...) when attacks_detected, so there is no monitor mode. The fields exist on the EnkryptAIGuardrailConfigModel type and are forwarded by enkryptai/__init__.py but have no effect.

This PR removes the "Using Deployments" and "Monitor Mode" sections, the three rows from the Configuration Options table, the block_on_violation sentence under Error Handling, and the detectors block from the policy_name example, replacing them with a short note that detection is controlled by the policy referenced in policy_name and that any violation blocks the request.

Fixes LIT-7290
https://linear.app/litellm-ai/issue/LIT-7290/docs-proxyguardrailsenkryptaimd-lines-178-200-deployment-name

Link to Devin session: https://app.devin.ai/sessions/6e14c5796a2045afb5dbb28da26459d3
Open in Devin Desktop: https://app.devin.ai/desktop/session/6e14c5796a2045afb5dbb28da26459d3?variant=devin

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
litellm	Ready	Preview	Sep 8, 2026 8:51pm UTC

[devin-ai-integration]

Live validation of this docs change against litellm main (aa2219d, v1.103.0), proxy run from source with uv run litellm --config .... No EnkryptAI credentials are available, so the EnkryptAI /guardrails/policy/detect endpoint was stubbed with a local HTTP server on 127.0.0.1:9977 that records every header and body it receives and returns summary.policy_violation: 1 only when the text contains BLOCKME. The LLM call is real (openai/gpt-4.1-mini, real OpenAI key). Nothing in litellm was modified

Config: one guardrail with the OLD docs snippet (deployment_name: production, block_on_violation: false, detectors: {toxicity, nsfw}) and one with the NEW docs snippet (policy_name: my-custom-policy), both default_on: false and selected per request via "guardrails": [...]

for g in enkryptai-old-monitor enkryptai-new; do for p in "Say hi" "BLOCKME please"; do
curl -s -w "HTTP %{http_code}\n" localhost:4077/v1/chat/completions -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H 'Content-Type: application/json' \
  -d "{\"model\":\"gpt-4.1-mini\",\"messages\":[{\"role\":\"user\",\"content\":\"$p\"}],\"guardrails\":[\"$g\"],\"max_tokens\":10}"
done; done

Results

== OLD monitor-mode config, clean prompt ==
HTTP 200  "Hi! How can I help you today?"
== OLD monitor-mode config, violating prompt (block_on_violation: false) ==
HTTP 500  {"message": "Guardrail failed: 1 violation(s) detected\n\n- POLICY_VIOLATION:\n  Policy: stub-policy\n  Explanation: stub violation", ...}
== NEW config, clean prompt ==
HTTP 200  "Hi! How can I help you today?"
== NEW config, violating prompt ==
HTTP 500  {"message": "Guardrail failed: 1 violation(s) detected ...", ...}

What the stub actually received from litellm (apikey redacted)

OLD: headers {content-type, apikey}                                   body {"text": "Say hi"}
OLD: headers {content-type, apikey}                                   body {"text": "BLOCKME please"}
NEW: headers {content-type, apikey, x-enkrypt-policy: my-custom-policy} body {"text": "Say hi"}
NEW: headers {content-type, apikey, x-enkrypt-policy: my-custom-policy} body {"text": "BLOCKME please"}

So with the old snippet no X-Enkrypt-Deployment header is sent, the detectors block never reaches the API (payload is only {"text": ...}), and block_on_violation: false still blocks the request with the same error as the default. The proxy debug log confirms the three params are parsed into litellm_params but EnkryptAIGuardrails.__init__ only consumes api_key, api_base, policy_name. The new text (policy controls detection, x-enkrypt-policy is the only extra header, any violation blocks) matches observed behavior

Also checked: the file still exists on docs main, the only later change to it (#1431, master key placeholders) touches different lines and GitHub reports the branch mergeable, CI is 4/4 green. One nit outside this PR's scope: the violation surfaces as HTTP 500 (ValueError in the hook), which the Error Handling section describes only as "raises an exception"