Skip to main content

Lakera AI

Supported endpoints: The Lakera v2 integration only supports the chat completions endpoint (/v1/chat/completions). It is not supported for the Responses API, /v1/messages, MCP, A2A, or other proxy endpoints.

Quick Start​

1. Define Guardrails on your LiteLLM config.yaml​

Define your guardrails under the guardrails section

litellm config.yaml
model_list:
- model_name: gpt-5.6-luna
litellm_params:
model: openai/gpt-5.6-luna
api_key: os.environ/OPENAI_API_KEY

guardrails:
- guardrail_name: "lakera-guard"
litellm_params:
guardrail: lakera_v2 # supported values: "aporia", "bedrock", "lakera"
mode: "during_call"
api_key: os.environ/LAKERA_API_KEY
api_base: os.environ/LAKERA_API_BASE
- guardrail_name: "lakera-pre-guard"
litellm_params:
guardrail: lakera_v2 # supported values: "aporia", "bedrock", "lakera"
mode: "pre_call"
api_key: os.environ/LAKERA_API_KEY
api_base: os.environ/LAKERA_API_BASE
- guardrail_name: "lakera-monitor"
litellm_params:
guardrail: lakera_v2
mode: "pre_call"
on_flagged: "monitor" # Log violations but don't block
api_key: os.environ/LAKERA_API_KEY
api_base: os.environ/LAKERA_API_BASE

Supported values for mode​

  • pre_call Run before LLM call, on input
  • post_call Run after LLM call, on input & output
  • during_call Run during LLM call, on input Same as pre_call but runs in parallel as LLM call. Response not returned until guardrail check completes

2. Start LiteLLM Gateway​

litellm --config config.yaml --detailed_debug

3. Test request​

Langchain, OpenAI SDK Usage Examples

Expect this to fail since since ishaan@berri.ai in the request is PII

Curl Request
curl -i http://localhost:4000/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer sk-npnwjPQciVRok5yNZgKmFQ" \
-d '{
"model": "gpt-5.6-luna",
"messages": [
{"role": "user", "content": "hi my email is ishaan@berri.ai"}
],
"guardrails": ["lakera-guard"]
}'

Expected response on failure

{
"error": {
"message": {
"error": "Violated content safety policy",
"lakera_ai_response": {
"model": "lakera-guard-1",
"results": [
{
"categories": {
"prompt_injection": true,
"jailbreak": false
},
"category_scores": {
"prompt_injection": 0.999,
"jailbreak": 0.0
},
"flagged": true,
"payload": {}
}
],
"dev_info": {
"git_revision": "cb163444",
"git_timestamp": "2024-08-19T16:00:28+02:00",
"version": "1.3.53"
}
}
},
"type": "None",
"param": "None",
"code": "400"
}
}

Supported Params​

guardrails:
- guardrail_name: "lakera-guard"
litellm_params:
guardrail: lakera_v2 # supported values: "aporia", "bedrock", "lakera"
mode: "during_call"
api_key: os.environ/LAKERA_API_KEY
api_base: os.environ/LAKERA_API_BASE
### OPTIONAL ###
# project_id: Optional[str] = None,
# payload: Optional[bool] = True,
# breakdown: Optional[bool] = True,
# metadata: Optional[Dict] = None,
# dev_info: Optional[bool] = True,
# on_flagged: Optional[str] = "block", # "block", "monitor", or "inject_system_message"
# advisory_system_message: Optional[str] = None, # custom template, only used with on_flagged: "inject_system_message"
# skip_system_message_in_guardrail: Optional[bool] = None, # exclude role: system from Lakera's inspection
# skip_tool_message_in_guardrail: Optional[bool] = None, # exclude role: tool from Lakera's inspection
  • api_base: (Optional[str]) The base of the Lakera integration. Defaults to https://api.lakera.ai
  • api_key: (str) The API Key for the Lakera integration.
  • project_id: (Optional[str]) ID of the relevant project
  • payload: (Optional[bool]) When true the response will return a payload object containing any PII, profanity or custom detector regex matches detected, along with their location within the contents.
  • breakdown: (Optional[bool]) When true the response will return a breakdown list of the detectors that were run, as defined in the policy, and whether each of them detected something or not.
  • metadata: (Optional[Dict]) Metadata tags can be attached to screening requests as an object that can contain any arbitrary key-value pairs.
  • dev_info: (Optional[bool]) When true the response will return an object with developer information about the build of Lakera Guard.
  • on_flagged: (Optional[str]) Action to take when content is flagged. Defaults to "block".
    • "block": Raises an HTTP 400 exception when violations are detected (default behavior)
    • "monitor": Logs violations but allows the request to proceed. Useful for tuning security policies without blocking legitimate requests.
    • "inject_system_message": Appends an advisory system message to the request and lets the real LLM call proceed (HTTP 200), instead of blocking or allowing silently. See Advisory mode below for how it works and its limitations.
  • advisory_system_message: (Optional[str]) Custom advisory message template, used only when on_flagged: "inject_system_message". Must be a valid str.format() string containing a real {reason} placeholder (an escaped {{reason}} is rejected); an invalid template raises an error when the guardrail is configured, not on the first flagged request. Defaults to a built-in generic message when unset.
  • skip_system_message_in_guardrail: (Optional[bool]) Exclude role: system messages from what's sent to Lakera for inspection. The LLM still receives the full conversation; only Lakera's view is filtered. If unset, falls back to the global litellm_settings.skip_system_message_in_guardrail. See Guardrails quick start for the global setting and Admin UI controls.
  • skip_tool_message_in_guardrail: (Optional[bool]) Same as above, for role: tool messages (tool call results). Falls back to litellm_settings.skip_tool_message_in_guardrail if unset. See Guardrails quick start.

Unlike most other guardrails that run via a direct hook on the raw request, Lakera v2 honors both skip flags directly; most direct-hook guardrails do not. See Where the skip flags apply for the full picture across guardrails.

Masking in place preserves both skip flags and every other field on a message (a tool message's tool_call_id, an assistant message's tool_calls, name, cache_control, and so on): only the message's own content is rewritten, and a message excluded by either skip flag is left completely untouched at its original position rather than being dropped. Lakera v2 still degrades to blocking, rather than masking, in two narrower cases where a redacted result can't be safely written back: when a message carries non-string (multimodal) content, or when the request combines chat completions messages with a Responses API input field or carries a Responses API instructions field, since there's no single field masking can safely target there.

Advisory mode​

on_flagged: "inject_system_message" is for detectors prone to false positives, for example a prompt-injection heuristic tripping on legitimate instructional language, where the operator wants the LLM itself to weigh whether a flag is real rather than hard-blocking every flagged request or allowing it with no signal at all.

litellm config.yaml
guardrails:
- guardrail_name: "lakera-advisory"
litellm_params:
guardrail: lakera_v2
mode: "pre_call"
on_flagged: "inject_system_message"
# advisory_system_message: "Custom template with a {reason} placeholder"
api_key: os.environ/LAKERA_API_KEY
api_base: os.environ/LAKERA_API_BASE

On a flag, the guardrail appends a system message to the request and the real LLM call proceeds normally (HTTP 200). With the default template, that message reads:

The user's latest message was flagged for {reason} by a content safety guardrail. This may be a false positive. Use your judgment: respond helpfully if the request is legitimate, or decline if it is not.

{reason} is filled in from Lakera's own detector breakdown, for example "a potential prompt injection attempt", "personally identifiable information", or "policy-violating content". Set advisory_system_message to override the wording, keeping a real {reason} placeholder in the template.

For a Responses API request, the advisory is appended to instructions when that field is present, not to input: instructions is the developer-set, privileged system-level field, while input is caller-controlled and a caller could otherwise include text telling the model to disregard a trailing warning appended there. instructions is inspected the same way, so a flag originating there still triggers the advisory correctly.

A PII-only flag is masked in place rather than getting the advisory message: there is no reason to show the model raw PII to deliver an advisory note, and masking already resolves the concern on its own. The advisory message is reserved for flags advisory mode can't otherwise resolve, such as a prompt-injection heuristic.

Advisory mode has two limitations tied to when in the request lifecycle the guardrail runs:

  • mode: "during_call" is not supported. during_call runs the guardrail concurrently with the LLM request with no barrier between the two, so there is no reliable point at which to append the advisory before the request is dispatched. Configuring on_flagged: "inject_system_message" with a mode that includes during_call raises an error when the guardrail is configured. Use mode: "pre_call" instead.
  • mode: "post_call" behaves like on_flagged: "monitor". By the time a post-call guardrail runs, the LLM has already produced its response, so there is nothing left to inject the advisory into. The flag is logged and the response is returned unchanged.
🚅
LiteLLM Enterprise
SSO/SAML, audit logs, spend tracking, multi-team management, and guardrails — built for production.
Learn more →