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.

​

How Guardrails Work

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.

​

Enforcement Modes

Every guardrail runs in one of four enforcement modes:

​

Scoping

Guardrails can be configured at three levels, with higher levels taking precedence: This lets you set org-wide baseline policies while allowing workspaces or individual gateways to have stricter configurations where needed. Each guardrail has an Enabled toggle in its detail drawer, under Status. Disabling a guardrail stops enforcement but keeps its configuration, so you can turn it back on later without reconfiguring.

​

How enabled and disabled rows resolve

When the same guardrail is configured at multiple scopes, Ultra picks the row that runs against live traffic using these rules:

• Enabled rows win by specificity. If an enabled row exists at multiple scopes, the most specific scope wins (gateway > workspace > organization).
• Disabled rows do not mask lower scopes. A disabled row at a higher scope is treated as unconfigured: Ultra falls through to the next enabled row at a more specific scope. For example, if you disable a guardrail at the org level but a workspace has it enabled, the workspace configuration runs for gateways in that workspace.
• Disabled rows still apply when nothing more specific is enabled. If no enabled row exists below it, the disabled row at the higher scope is the effective configuration and the guardrail does not run.

​

Built-in Guardrails

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.

​

PII and Personal Data Protection

The PII guardrail scans request parameters and resource URIs for personal data and emits a violation for each match. When run in Redact mode, matched values are replaced with [REDACTED] in the request payload, the response echo, and the audit trail before reaching the upstream server. Default configuration. The guardrail is enabled by default in Redact mode with the high-precision categories turned on (email, US SSN, phone numbers, credit cards with Luhn validation, IBAN, and crypto addresses). Lower-precision or specialized categories that frequently collide with non-PII identifiers are off by default and can be enabled per workspace:

• PHI / Health Information: off by default. Detects labeled health identifiers and medical codes (MRN, patient IDs, ICD-10, CPT, and HCPCS codes). Label-anchored to avoid colliding with ordinary product, ticket, and billing identifiers.
• BIC / SWIFT codes: off by default. Format collides with enum values, error codes, and UUID fragments.
• Public IPv4 addresses: off by default. Many tool calls legitimately reference public IPs.
• Private IPv4 addresses: off by default. Internal network references are rarely sensitive.

Response scanning. Tool call responses are not scanned by default because most response payloads legitimately contain the PII the caller requested (HR or CRM lookups, customer records). Enable Scan Responses for PII when tools return untrusted content or when compliance requires bidirectional scanning. Response scanning is capped to the first 256 KB of body data with bounded JSON traversal. Bypass list. The bypass_tools list skips PII detection for matching tools or resources. Use exact names (e.g., salesforce_search) or prefixes ending in * (e.g., workday_*, workday://*). Matching is case-insensitive and applies to both request redaction and response scanning. Use this for internal tools that are expected to handle PII so the guardrail does not interfere with their normal operation.

​

Tool & Server Isolation

The Tool & Server Isolation guardrail stops cross-server exfiltration patterns. It catches cases like an MCP agent that reads a secret from aws-mcp.get_secret and then posts it to slack-mcp.post_message. Detection is session-scoped and stateful: the guardrail watches the values flowing out of each tool response within a session and blocks subsequent calls on a different server whose parameters contain those values. Two independent detectors run inside this guardrail:

• Cross-server content detection (detect_cross_tool_content, on by default). Every tool response is indexed against the session. If a later tool call on a different server includes a value that matches indexed content from a previous server, the call is blocked. Same-server tool chains are exempt by default (same_server_exempt).
• Tool-sequence blocklist (tool_sequence_blocklist). An explicit list of forbidden (server.tool → server.tool) patterns, each with a configurable within_seconds window. Use this to block known-bad chains regardless of payload contents (for example, “never let github.list_secrets precede slack.post_message within five minutes”).

Default configuration. Enabled in Block mode. Cross-server content detection is on. The session content-flow tracker uses a default TTL of 300 seconds; supported range is 1 to 86,400 seconds. Configurable knobs (shown in the guardrail drawer with these labels):

• Detect Cross-Tool Content Flow (detect_cross_tool_content): toggle the cross-server content detector independently of the sequence blocklist.
• Content Flow Session TTL (seconds) (content_flow_session_ttl_seconds): how long a session’s indexed content is retained for matching.
• Blocked Tool-Call Sequences (tool_sequence_blocklist): list of from/to entries describing forbidden tool transitions, each with an optional within-seconds window.
• Exempt Same-Server Flow (same_server_exempt): when true (default), tool chains that stay on the same server skip the cross-server check.

​

Circuit Breaker

The Circuit Breaker guardrail protects availability. It watches each upstream MCP server’s error rate and latency over a rolling window and trips when a server looks unhealthy, blocking further calls to that server until it recovers. This stops a degraded or down upstream from soaking up requests and triggering cascading failures. It runs as a three-state machine, per server:

• Closed (normal): calls flow through while Ultra records request and failure counts over the rolling window.
• Open (tripped): once the failure rate or latency crosses the threshold, calls to that server are blocked with a retry-after hint (for example, circuit breaker open for server 'github-mcp': upstream is degraded, retry after 30s) for the cooldown period.
• Half-open (probing): after the cooldown the breaker admits a small number of probe requests. If they all succeed it closes and traffic resumes; if one fails it re-opens and the cooldown restarts.

Default configuration. Off by default. Enable it where you want availability protection. Configure one or more rules, each targeting a server (or * for a shared breaker across every server), with these settings shown in the guardrail drawer: Each rule can set its own enforcement mode; when omitted it inherits the guardrail’s mode. If several rules trip at once, the strictest mode wins.

​

Guardrail Categories

Guardrails are organized into categories that map to different areas of MCP security:

​

Choosing Your Guardrail Configuration

​

Default Protection

Built-in guardrails are recommended during configuration and run in Block mode, with the exception of PII and Personal Data Protection, which defaults to Redact so matched values are masked rather than blocking the request. 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.

​

Scoping Flow

When configuring guardrails, work from broad to specific:

1. 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 their default enforcement modes at the org level.
2. 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.
3. 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.

​

When to Change Enforcement Modes

​

Adding Guardrails Beyond Defaults

Consider enabling additional guardrails if your environment involves:

• Custom internal tools: Create custom guardrails (see below) to enforce organization-specific policies on tool names, parameters, or servers
• Multi-tenant environments: Layer workspace-level and gateway-level guardrails to isolate tenants
• Compliance requirements: Check the framework coverage tags on each guardrail to map your coverage against AARM, SAFE, and AUIC-1 frameworks
• Sensitive data workflows: Switch credential protection to Redact mode if you need requests to proceed but want secrets masked

​

Custom Guardrails

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.

​

Creating a Custom Guardrail

1. Navigate to Guardrails in the Ultra Hub sidebar
2. Click + Create Custom Guardrail in the top-right corner
3. Fill in the guardrail details:
   • Name: A descriptive name (e.g., “Block /secrets directory access”)
   • Description: What the guardrail does and why

​

Trigger Conditions

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: Available operators:

​

Enforcement Action

Choose the enforcement action for your custom guardrail:

• Block: Hard block with denial receipt. The request is stopped and the client receives an error.
• Alert: Notify but allow action. The request proceeds and a warning event is generated.
• Monitor: Log only, no notification. The request proceeds silently.
• Redact: Mask sensitive data in transit. Matched content is replaced with [REDACTED].

​

Example: Block Access to Secrets Directory

To create a guardrail that blocks any tool call attempting to access files in a /secrets/ directory:

1. Name: Block /secrets directory access
2. Description: Prevents any tool from reading or writing files in the /secrets directory
3. Trigger Conditions:
   • Field: Any Parameter | Operator: contains | Value: /secrets/
4. Enforcement Action: Block

​

Example: Alert on Unrecognized Servers

To get notified when tool calls hit a server outside your approved list:

1. Name: Alert on unapproved servers
2. Description: Flags tool calls routed to servers not in the approved list
3. Trigger Conditions:
   • Field: Server Name | Operator: not equals | Value: approved-server-1
   • Field: Server Name | Operator: not equals | Value: approved-server-2
4. Enforcement Action: Alert

​

Example: Restrict command execution to internal users

To block execute_command tool calls from users outside your organization:

1. Name: Block external users from execute_command
2. Description: Only users with a @company.com email can run execute_command
3. Trigger Conditions:
   • Field: Tool Name | Operator: equals | Value: execute_command
   • Field: User Email | Operator: not ends with | Value: @company.com
4. Enforcement Action: Block

​

Deleting a Custom Guardrail

To remove a custom guardrail you own, open its detail panel from the Guardrails page and click Delete, then proceed through the confirmation dialog. The action is restricted to owners and admins at the scope where the guardrail was created; inherited custom guardrails are read-only at lower scopes. Deleting a guardrail stops new evaluations immediately, but existing audit log entries for past evaluations are preserved. Built-in guardrails cannot be deleted: they can only be disabled or re-scoped.

​

Dry-run testing

Before enforcing a guardrail in production, you can dry-run it against historical traffic to preview what it would catch. Dry-run evaluates a guardrail against stored traces at the selected scope and returns which requests would have triggered, without affecting live traffic. Dry-run works for built-in and custom guardrails, whether they are currently enabled or saved as a disabled draft.

​

Running a dry-run

1. Navigate to Guardrails in the Ultra Hub sidebar
2. Select a scope (organization, workspace, or gateway) and open a guardrail to reveal the Test this guardrail panel
3. Choose a range using the preset buttons or Custom range
4. Click the run button to evaluate the guardrail

The panel header shows the Target scope and a status indicator (Ready, Running, Draft ready, Save & test, or Unsaved).

​

Range selection

Pick how much historical traffic to evaluate: Open Custom range to enter an exact event count or hour value within the supported limits.

​

Results

Dry-run returns the following, which stay visible in the drawer until you change scope, switch guardrails, or run again:

• Traces evaluated: Total number of historical traces tested
• Would trigger: Number of traces that would have been caught
• Events: Details of each trace that would have triggered. Each event shows:
  • The action that would be taken (block, alert, monitor, or redact)
  • The matched request context: operation, upstream server, tool name, and timestamp
  • A human-readable explanation of why the guardrail fired (for example, “path matched a path traversal rule”)
  • Trigger details (expandable): each individual match that fired, showing the rule that triggered (for example, “Path traversal”), the field that was inspected (for example, “path”), and the matched value
• Evaluation errors: Grouped error messages with sample trace IDs if any evaluations failed during the test

​

Testing unsaved edits and disabled built-ins

The dry-run panel can test guardrail configurations that are not currently live:

• Unsaved edits. If you have pending changes, the button reads Save & test. Clicking it persists your edits and immediately runs a dry-run against the new configuration.
• Disabled built-in guardrails. Built-in guardrails do not need to be enabled to be tested. When you adjust the configuration of a disabled built-in, the button reads Save draft & test: the panel saves the configuration as a disabled draft (no enforcement) and runs the dry-run against that draft. Use this to size the impact of a built-in before turning it on.

​

When to use dry-run

​

Viewing Enforcement Events

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.

​

Grouped evaluations

When multiple guardrails evaluate a single request, their results share the same trace_id and are displayed as a single collapsible row in the audit log. The group row shows:

• A Guardrail [N] badge indicating how many evaluations occurred
• The strongest outcome across all evaluations (deny > redact > alert > monitor > allow)
• The highest severity across all evaluations (critical > error > warning > info)

Click the expand arrow to reveal every individual evaluation in the group. Each evaluation card shows the guardrail name, enforcement mode, severity, and match count. Click any card to open the full Audit Detail panel for that evaluation. This grouping keeps the audit log readable when many guardrails are active. A single tool call that triggers five guardrails appears as one row instead of five.

​

Audit detail

Clicking a guardrail event (or an individual evaluation inside a group) 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, MONITOR, 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

​

Severity mapping

Each tool call generates one guardrail event per active guardrail. These events share a trace_id and are grouped into a single expandable row in the audit log.

​

Next Steps