Enforce security policies on every MCP tool call with built-in and custom guardrails
Ultra Guardrails let you define and enforce security policies across your MCP infrastructure. Every tool call passes through the guardrails engine before reaching upstream servers, giving you real-time protection against credential leakage, destructive actions, input manipulation, and more.Guardrails are configured in Ultra Hub and automatically synced to all connected gateways. Built-in guardrails are recommended during configuration, protecting your environment from the most common MCP security threats out of the box.
When an MCP tool call arrives at an Ultra gateway, the guardrails engine evaluates it against all active guardrails in parallel. Each guardrail inspects the request (tool name, parameters, server context) and returns a decision. The strictest decision wins.
Every guardrail runs in one of four enforcement modes:
Mode
Behavior
Block
Prevents the request from reaching the upstream server. The client receives an error with the guardrail name and reason.
Alert
Allows the request but generates a warning-level audit event. Use this to monitor potential issues without disrupting workflows.
Monitor
Allows the request and records the event silently. Use this for visibility without notifications.
Redact
Allows the request after masking matched content in both the request and response. Matched values are replaced with [REDACTED].
Guardrails are fail-closed. If an evaluation error occurs or an evaluator is unavailable, the request is blocked regardless of the configured enforcement mode.
Ultra ships with built-in guardrails that are recommended during configuration. These cover the most critical MCP security risks and require no configuration to start protecting your environment. You can view the full list, descriptions, and configuration options for each guardrail in the Guardrails page in Ultra Hub.
Guardrail
Category
Description
Parameter Validation and Input Sanitization
Input Protection
Validates tool call parameters against type constraints, range limits, and dangerous patterns like path traversal (../), dangerous CLI flags (--exec, --privileged), shell injection, and command chaining. Supports configurable allowed-directory restrictions and per-parameter blocklists.
Credential and Secret Protection
Data Protection
Detects and blocks access to credential files (.env, .aws/credentials, .ssh/id_*, and more), secrets in tool parameters (API keys, tokens, private key headers), and cloud metadata endpoints. Automatically redacts matched secret values in audit log entries.
In-Line Authorization and Destructive Action Blocking
Access Control
Blocks destructive actions before they reach target systems. Covers destructive tool names (delete_*, drop_*, rm_*), dangerous SQL and shell operations in parameters, code/git write tools, and financial/payment tools. Each category can be independently enabled or disabled.
Rate Limiting
Infrastructure
Configurable request rate limits per MCP server to prevent resource exhaustion and enforce usage quotas. Define rules with per-server or wildcard limits using fixed time windows.
Built-in guardrails are recommended during configuration and run in Block mode. For most organizations, enabling all built-in guardrails provides strong baseline security with no additional setup required. Before adding custom guardrails or changing enforcement modes, consider your team’s workflows.
When configuring guardrails, work from broad to specific:
Start at the organization level — Set your baseline security posture. The built-in guardrails are recommended here. Most organizations should keep them all enabled in Block mode at the org level.
Adjust at the workspace level — If certain teams need different policies (for example, a development workspace where destructive actions are acceptable for testing), override specific guardrails at the workspace level.
Fine-tune at the gateway level — For individual gateways that need special treatment, apply gateway-level overrides. This is the most granular scope and is useful for edge cases.
Beyond the built-in guardrails, you can create custom guardrails to enforce organization-specific security policies. Custom guardrails use the same evaluation engine and enforcement modes as built-in guardrails.
Trigger conditions define when the guardrail fires. Each condition has three parts: a field, an operator, and a value. You can add multiple conditions joined with AND logic using + Add condition (AND).Available fields:
Field
Description
Tool Name
The name of the MCP tool being called
Server Name
The upstream server handling the request
Resource URI
The resource being accessed
Any Parameter
Matches against all parameter values
Parameter…
Matches against a specific named parameter
Trigger conditions match against values at any depth in the request parameters, not just top-level fields. If a tool call includes nested objects or arrays, the condition will evaluate against values found within them as well.
Every guardrail evaluation is recorded as a GUARDRAIL event in the audit log, regardless of outcome. You can view these in the Audit Log page alongside TOOL CALL events.Clicking a guardrail event opens the Audit Detail panel, which shows:
Event type and severity — GUARDRAIL badge with INFO, WARNING, or ERROR severity
Timestamp — When the evaluation occurred
Context — The tool/action being evaluated, the MCP server it targeted, the MCP client that made the request, and the outcome (ALLOW, BLOCK, ALERT, REDACT)
User Identity — Name, email, and user ID of the person whose request triggered the evaluation
Raw details — Full JSON including the guardrail’s enforcement mode, guardrail ID, which guardrail was evaluated (e.g., parameter-validation, credential-protection), type (builtin or custom), any matches, request context, and trigger details
Each tool call generates one guardrail event per active guardrail, so you will typically see multiple GUARDRAIL events at the same timestamp corresponding to a single TOOL CALL event.
