litellm - 💡(How to fix) Fix [Feature Request]: Support for NVIDIA NeMo Guardrails (Python Library & Proxy API Server) [1 participants]

Is your feature request related to a problem? Please describe. As enterprise adoption of LLMs grows, so does the need for robust, programmable guardrails to ensure output safety, prevent hallucinations, and restrict topic deviation. While LiteLLM currently supports some guardrail providers (like Lakera, Prompt Injection, and Presidio), it lacks native support for NVIDIA NeMo Guardrails, which has become an industry standard for open-source, highly customizable guardrails.

Currently, if we want to use NeMo Guardrails with LiteLLM, we have to run NeMo Guardrails as a separate upstream service or wrap LiteLLM calls in custom code. This adds architectural complexity, increases latency, and prevents us from utilizing LiteLLM's native Proxy Server features (like spend tracking, load balancing, and API key management) as the primary entry point.

Describe the solution you'd like I would like to see native integration of NVIDIA NeMo Guardrails into LiteLLM, specifically within the Proxy API Server and the standard Python library.

Ideally, it would function similarly to existing LiteLLM guardrail integrations, where we can specify a path to the NeMo Guardrails configuration directory in the config.yaml.

Proposed Implementation Idea for Proxy config.yaml:

model_list:
  - model_name: my-secure-gpt
    litellm_params:
      model: openai/gpt-4
      
litellm_settings:
  guardrails:
    - nemo_guardrails:
        config_path: "./nemo_config/" # Path to the Colang and YAML files
        # Optional: Run on input, output, or both
        mode: "both"

Workflow:

1. User sends a request to the LiteLLM Proxy.
2. LiteLLM intercepts the request and passes it to the NeMo Guardrails instance (initialized via the provided config_path).
3. If blocked by the input guardrails, LiteLLM returns an immediate standard error/blocked response.
4. If passed, LiteLLM routes the request to the upstream LLM.
5. (If configured) Output is evaluated by NeMo Guardrails before being returned to the user.

Describe alternatives you've considered

1. Using NeMo Guardrails as the entry point: Running the NeMo Guardrails server and configuring it to call the LiteLLM Proxy as its LLM provider. Drawback: We lose the ability to use LiteLLM's API key management, rate limiting, and user-level spend tracking because LiteLLM only sees a single user (the NeMo server).
2. Custom LiteLLM Middleware: Writing custom callbacks (custom_callbacks) to route requests through NeMo Guardrails. Drawback: Requires maintaining custom Python code rather than relying on a standardized, containerized LiteLLM proxy deployment.

Additional context

• NVIDIA NeMo Guardrails Repo: https://github.com/NVIDIA/NeMo-Guardrails
• Because NeMo Guardrails has a Python API (LLMRails), it should be relatively straightforward to integrate it into LiteLLM's async pre_call_hook and post_call_hook architecture.
• This feature would make LiteLLM incredibly attractive to enterprise teams looking for a unified routing, logging, and safety layer.