Guardrails are security policies that control how AI assistants interact with tools and data. Guardrails provide nuanced rules that make AI systems safer and more predictable.
When AI assistants use tools, they need different constraints than human users:
| Input | Output | Behavioral |
|---|---|---|
|
Control what goes into the AI system: • Domain filtering: Limit which websites can be accessed • File type restrictions: Block binary files or specific formats • Size limits: Cap file sizes and directory traversal depth • Pattern matching: Detect and block sensitive data patterns |
Control what comes out of tools: • Data sanitization: Remove sensitive information from responses • Format enforcement: Ensure outputs match expected schemas • Content filtering: Block inappropriate or harmful content • Response limits: Prevent overwhelming the AI with data |
Control how the AI uses tools: • Rate limiting: Prevent excessive API calls • Sequence controls: Enforce proper tool usage order • State validation: Ensure operations happen in valid states • Audit requirements: Force logging of certain operations |
1. Identify the MCP server and tool. First, you need to know:
2. List available guardrail templates. This shows you all the constraint templates available for that specific tool, with descriptions of what each does:
3. Add a guardrail, once you know which template to use:
4. To manage existing guardrails:
Guardrail templates provide pre-configured validation rules that you can apply to tool parameters and responses. Here are the common types:
Value constraints:
Pattern validation:
Structural validation:
Guardrails use a hierarchical scoping system that lets you target constraints at different levels of specificity.
1. Server-level scope allows you to apply guardrails to an entire MCP server. It affects all tools within that server:
Tip: When you omit operationName, the guardrail applies globally to all operations from that server.2. Tool-level scope (most common) allows you to apply guardrails to a specific tool/operation within a server. This targets just one tool, giving you fine-grained control:
3. Parameter-level scope allows you apply guardrails more precisely. Within a tool, you can target specific parameters or parts of a data structure using schemaPath. The JSONPath you put in schemaPath lets you drill down to the exact field you want to constrain:
1. To list all guardrails for a server:
2. To list guardrails for a specific tool:
The list will show you:
1. Pre-populate tool parameters automatically (Hook_Parameter)
Automatically set parameter values so the AI doesn't need to ask for them.
Use case: Always use a specific account ID, region, or configuration value.
2. Filter which tools are visible to the AI (Hook_Filter)
Hide tools from the AI to reduce noise or prevent access to certain operations.
Use case: Only show read operations, hide dangerous delete functions.
3. Create aliases or rename tools (Hook_ Alias)
Give tools friendlier or more descriptive names.
Use case: Rename technical tool names to business-friendly terms.
4. Clone tools with different configurations (Hook_Clone)
Duplicate a tool with a new name, allowing different parameter presets.
Use case: Create "production" and "staging" versions of the same tool.
5. Override or add to tool descriptions (Hook_CustomDescription)
Change how tools are described to the AI for better context.
Use case: Add business context, warnings, or usage guidelines.
1. Read existing hooks:
2. Describe hook structure and examples:
3. Delete hooks:
Source: https://www.civic.com/news/guardrails