Skip to main content
LiteLLM is an open-source proxy that puts one OpenAI-compatible API in front of many model providers: an application calls a single endpoint, and the proxy routes the request to whichever provider is configured for that model. It centralizes provider keys, spend, and routing. The custom guardrail evaluates requests and responses that pass through the proxy. Traffic sent directly to a provider bypasses this integration. It also does not see local agent actions, such as shell commands or MCP tools invoked on a developer machine. For those, use a client integration such as Cursor or Claude.

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 the httpx client included with LiteLLM, so it requires no additional dependency. The supported enforcement actions are Monitor and Block. This integration does not support redaction.

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, which is /app in the official image. Mount it read-only as a volume, ship it as a ConfigMap with subPath, or bake it into your image. Then declare it in config.yaml:
Here TRUSTGUARD_API_BASE is the full endpoint, {TRUSTGUARD_URL}/v1/evaluate, not only the host.

Choose what gets inspected

An agent client, such as an IDE assistant or an in-house agent loop, can resend the entire transcript on every turn, including the system prompt and earlier tool results. Choose scope based on the context required by your policy and the acceptable payload size. Tool results must keep role: "tool" because the indirect prompt injection detector uses that role. Flattening every message to user disables that check. Agent transcripts can also be large, so measure latency with representative payloads.

Verify

Assign an Enforce policy with a Block rule that matches the test prompt, then send a non-streaming request through the proxy:
The guardrail returns HTTP 400 with error: "Blocked by TrustGuard", the guardrail name, findings, and trace_id. It does not return request_id. Use trace_id to find the same decision in Activity. To verify monitoring before enforcement, set the policy to Observe and LITELLM_LOG=INFO, then send a request that matches a rule. A non-streaming request with both hooks enabled logs an input line followed by an output line:
An input-side block logs status=block without an output line because LiteLLM does not call the model. To verify an output-side block, use a non-streaming request and an Output rule; LiteLLM returns HTTP 400 after the model responds but before returning the completion to the client.

Reference

Coverage

The custom guardrail supports monitoring and blocking for chat-style requests. It does not support redaction, embeddings, image generation, or audio routes. For streaming requests, LiteLLM invokes the output hook with the assembled response after the stream closes. The result is recorded, but it cannot stop tokens that have already been delivered. Input evaluation still runs before the model call. Tool content is covered only when LiteLLM includes it in the messages selected by scope. Tool results must retain role: "tool"; tool declarations and tool calls are not evaluated as separate lifecycle events. Enforcement remains request-level, so a finding in tool content blocks the complete LiteLLM request. With pre_call and post_call enabled, a successful chat request with text input and output adds two calls to TrustGuard. For streaming requests, the output call occurs after the stream closes. Set timeout according to the latency requirements of the proxy. Full comparison: Coverage.

What is evaluated

The pre_call and post_call hooks call POST /v1/evaluate. The assigned policy’s detectors determine the verdict. Configure both hooks to evaluate input and output.
With stream: true, LiteLLM calls the output hook with the assembled ModelResponse after the stream closes. TrustGuard evaluates and records that output, but a block verdict cannot recall tokens already sent to the client. Input enforcement still occurs before the model call.

Verdict handling

Use Monitor or Block actions with this integration. A block response exposes the findings to the caller. Use trace_id to correlate the response with Activity.

Configuration

Define TRUSTGUARD_API_BASE and TRUSTGUARD_API_KEY in the proxy environment, then restart LiteLLM after changing the guardrail file or config.yaml. Failure behavior. The custom guardrail handles connection errors, timeouts, and every non-200 TrustGuard response according to fail_open:
fail_open: true applies to every non-200 response, including 401, 403, 429, and 503. Monitor the TrustGuard unreachable, failing open (traffic NOT inspected) warning if you enable this setting.

Attributes

  • session_id: derived from the LiteLLM request when available
  • consumer_id: derived from the virtual key’s key_alias, user_email, user_id, or team_alias, then from request metadata if those fields are empty
The guardrail sends these values to TrustGuard when it finds a non-empty value. They support conversation grouping and per-consumer attribution in Activity.

Troubleshooting

Experimental: BerriAI/litellm#37165 proposes a native neuraltrust guardrail. It is not part of the setup described on this page.