config.yaml calls
POST /v1/evaluate before the upstream model call
and again on the response. Every application already pointing at the proxy is
covered, with no client changes.
The file implements apply_guardrail and a streaming hook. With
incremental_diff, it buffers the chat completion, applies the policy, and
returns the inspected response in streaming format. You do not run a second
HTTP service
Traffic sent directly to a provider bypasses this integration. It also does not
see local agent actions such as shell commands or MCP tools on a developer
machine. For those, use a client integration such as
Cursor or
Claude Code.
Integration capabilities
Before you start
Create the policy in Observe mode. Observe records decisions in Activity
without enforcing them. Review the results, then switch the policy to Enforce.
See Policies.
Set up the custom guardrail file
The guardrail uses thehttpx client and PyJWT, both included with the LiteLLM
proxy, so it requires no additional dependency.
Custom guardrail: trustguard_guardrail.py
Custom guardrail: trustguard_guardrail.py
Mount it and declare it
trustguard_guardrail.TrustGuard is resolved relative to the directory the proxy
runs from, so the file has to sit next to your config.yaml (/app in the
official image). Then declare it:
TRUSTGUARD_API_BASE is the host (https://trustguard.neuraltrust.ai or your
workspace URL). The file appends /v1/evaluate. A value that already includes
that path still works. mode must list both pre_call and post_call for
Input and Output coverage. default_on: true applies the guardrail when a
request does not name it.
Ordinary completions vs streamed completions
Use the same file and the sameconfig.yaml for both shapes of traffic. The
recommended configuration above buffers streamed output until inspection
finishes, including when a policy rewrites tool arguments.
A normal request sends the prompt, then the complete answer. With streamed
block_only, LiteLLM inspects accumulated output during generation. With
incremental_diff, the custom hook inspects the complete answer once before
returning any output
Use this when the client must receive only inspected output:
/v1/chat/completions; it does not provide
buffered output protection for other streaming API formats. Tool results are
inspected when the caller includes them as role: "tool" messages in its next
request. The connector does not execute or intercept local tools
The example explicitly selects incremental_diff. Omitting the setting falls
back to block_only for compatibility. It provides no guarantee that
output is inspected before delivery, and output transformations are discarded
Attribute requests to a user
A proxy usually serves many people through a few keys. The guardrail’sconsumer_id names
the LiteLLM key — its alias, or its owner’s email — so every person behind a shared
key looks the same in TrustGuard. The guardrail also sends the person the request is for,
as attributes.user on /v1/evaluate, and
Activity shows them in the User column: their email, or their id when there is no
email.
The guardrail takes the first source that names someone:
A request that names nobody is sent without
attributes, exactly as before. Values are
trimmed and capped at 256 characters.
To attribute your own clients, have them send x-litellm-end-user-id, or map a header they
already send. LiteLLM then also tracks spend for that end user:
Verified users from Open WebUI
Open WebUI can sign its user with a secret you choose (FORWARD_USER_INFO_HEADER_JWT_SECRET, see Open WebUI).
You run both Open WebUI and LiteLLM, so give the guardrail the same secret:
Verify
Assign an Enforce policy with a Block rule that matches the test prompt:400 with error: "Blocked by TrustGuard" and a trace_id. Use
that id in Activity.
To verify transform, enable a DLP rule and send an email in the prompt. Expect
HTTP 200 and a masked value. To verify streamed redaction, add
"stream": true after setting streaming_transform_mode: incremental_diff.
Reference
Coverage
Output redaction on
stream: true needs streaming_transform_mode: incremental_diff.
Tool content is covered when LiteLLM includes it in the extracted messages.
Enforcement is request-level: a finding blocks the complete LiteLLM request.
What is evaluated
Verdict handling
Configuration
Failure behavior. Connection errors, timeouts, and every non-
200 follow
fail_open:
Attributes
session_id: the conversation key the caller supplied (x-litellm-session-id), else Open WebUI’sX-OpenWebUI-Chat-Id.consumer_id: the virtual key’s alias, then user email, user id, or team alias. The master key resolves to LiteLLM’s proxy admin user id,default_user_id. A key with none of those fields sends noconsumer_id.attributes.user: the person behind the request, when one is named. See Attribute requests to a user.
Troubleshooting
Related
- Policies
- Evaluate API
- TrustGate: buffer a stream before the client sees tokens
- LiteLLM proxy docs