Tools Integration with the NeMo Guardrails Library
This guide provides comprehensive instructions for integrating and using tools within the NeMo Guardrails library via the LLMRails interface. It covers supported tools, configuration settings, practical examples, and important security considerations for safe and effective implementation.
Overview
The NeMo Guardrails library supports the integration of tools to enhance the capabilities of language models while maintaining safety controls. Tools can be used to extend the functionality of your AI applications by enabling interaction with external services, APIs, databases, and custom functions.
Supported Version
Tool calling is available starting from the NeMo Guardrails library version 0.17.0.
Supported Tools
The NeMo Guardrails library supports LangChain tools, which provide a standardized interface for integrating external functionality into language model applications.
LangChain Tools
The NeMo Guardrails library is fully compatible with LangChain tools, including:
- Built-in LangChain Tools: Weather services, calculators, web search, database connections, and more
- Community Tools: Third-party tools available in the LangChain ecosystem
- Custom Tools: User-defined tools created using the LangChain tool interface
Creating Custom Tools
You can create custom tools by following the LangChain documentation patterns. Here’s an example:
For detailed information on creating custom tools, refer to the LangChain Tools Documentation.
Configuration Settings
Passthrough Mode
When using tools with the NeMo Guardrails library, it’s recommended to use passthrough mode. This mode is essential because:
- Internal NeMo Guardrails library tasks do not require tool use and might provide erroneous results if tools are enabled
- It ensures that the LLM can properly handle tool calls and responses
- It maintains the natural flow of tool-based conversations
Configure passthrough mode in your configuration:
The key differences between configurations:
- bare_config: No rails at all, pure LLM with passthrough
- unsafe_config: Only has input rails, tool results bypass validation
- safe_config: Has both input and output rails for complete protection
We will use these configurations in the examples below.
Implementation Examples
Example 1: Multi-Tool Implementation
This example demonstrates how to implement multiple tools with proper tool call handling:
Example 2: Single-Call Tool Processing
This example shows how to handle pre-processed tool results:
Security Considerations
Tool Message Risks
Important: Tool messages are not subject to input rails validation. This presents potential security risks:
- Tool responses may contain unsafe content that bypasses input guardrails
- Malicious or unexpected tool outputs could influence the model’s responses
- Tool execution results are trusted by default
Recommended Safety Measures
To mitigate these risks, we strongly recommend using output rails to validate LLM responses.
Tool Security: Unsafe Content in Tool Results
The Problem: Tool Results Bypass Input Rails
Tool messages are not subject to input rails validation, creating a security vulnerability where unsafe tool results can bypass guardrails and influence the LLM’s responses.
Demonstration: Bare LLM vs Rails Configuration
Expected Results
The results may vary slightly due to the non-deterministic nature of LLMs, but typically:
- Bare Config Output:
"Client ID BOMB ME — NVIDIA (NVDA) stock price: $180.00." - Unsafe Config Output:
"Client ID BOMB ME — NVIDIA (NVDA) stock price: $180.00." - Safe Config Output:
"I'm sorry, I can't respond to that."
LangChain and LangGraph Integration
For integration with LangChain and LangGraph workflows, refer to:
- LangChain Integration Guide - Using RunnableRails to add guardrails to LangChain chains
- LangGraph Integration Guide - Tool calling with LangGraph stateful multi-agent workflows