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 connectors, 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 devices. Built-in guardrails are recommended during configuration and provide coverage for the most common MCP security threats once enabled at the appropriate scope.

​

How Guardrails Work

When an MCP tool call arrives at an Ultra device, the guardrails engine evaluates it against all active guardrails in parallel. Each guardrail inspects the request (tool name, parameters, connector context) and returns a decision. The strictest decision wins.

​

Enforcement Modes

Every guardrail runs in one of three enforcement modes: Ordered by how hard they enforce, the modes rank Monitor < Redact < Block. That ordering is what decides which rule wins when the same guardrail is configured at more than one scope. See Scoping.

​

Scoping

Guardrails can be configured at three levels: This lets you set an org-wide baseline that narrower scopes can tighten. A narrower scope can add restrictions but never remove them: a workspace or device rule is honored when it enforces harder than the organization’s, and discarded when it would weaken it. 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 rules resolve

When the same guardrail is configured at multiple scopes, Ultra picks the rule that runs against live traffic as follows:

• An enabled rule always beats a disabled one. A disabled rule at a broader scope is treated as unconfigured, so Ultra falls through to an enabled rule at a more specific scope. A disabled rule at a narrower scope cannot switch off a guardrail its organization has enabled.
• Among enabled rules, the strictest wins. Monitor < Redact < Block. A workspace rule set to Block under an organization rule set to Monitor wins, because it tightens. A workspace rule set to Monitor under an organization Block is discarded, because it would relax the mandate.
• Scope only breaks a tie. When two enabled rules enforce equally hard, the broadest scope owns the setting: organization, then workspace, then device.
• Disabled rules still apply when nothing is enabled. If no enabled rule exists anywhere, the nearest (most specific) disabled rule becomes the effective configuration and the guardrail does not run.

The winning rule brings its whole configuration with it. A narrower rule that tightens the mode also replaces the broader rule’s other settings, so carry over anything you still want when you tighten at a workspace or device. Rate Limiting is the exception. Its rate limits accumulate instead of resolving to a single scope, so every limit set at every enabled scope applies and a workspace or device adds a tighter local cap rather than replacing the organization’s. Circuit Breaker, despite also being stateful, follows the normal resolution rules.

​

New Organization Defaults

A newly created organization has every built-in guardrail enabled at the organization scope in Monitor mode automatically, alongside anomaly detection. This gives you day-one visibility with no setup, but Monitor mode only records events: nothing is blocked or redacted until you promote a guardrail to a stricter mode. Organizations that existed before this change are not backfilled; enabling guardrails and anomaly detection there is still a manual step. Use dry-run testing to see what each guardrail would catch, then follow When to Change Enforcement Modes to move guardrails to Block or Redact.

​

Built-in Guardrails

Ultra ships with built-in guardrails that are recommended during configuration. These cover the most critical MCP security risks and become active only after you enable them at the organization, workspace, or device scope. You can view the full list, descriptions, and configuration options for each guardrail in the Guardrails page in Ultra Hub.

​

PII & 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 outbound request payload before it reaches the upstream connector, and in the response returned to the client. Redact mode protects the connector and the client. The raw matched values still sync to the Hub, so admin teams retain full visibility for incident response. Default configuration. The catalog recommends this guardrail in Redact mode, and it runs only once a rule enables it at the organization, workspace, or device scope. Once enabled, the high-precision categories are on by default (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-connector 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 connector whose parameters contain those values. Two independent detectors run inside this guardrail:

• Cross-connector 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 connector includes a value that matches indexed content from a previous connector, the call is blocked. Same-connector tool chains are exempt by default (same_server_exempt).
• Tool-sequence blocklist (tool_sequence_blocklist). An explicit list of forbidden (connector.tool → connector.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. The catalog recommends this guardrail in Block mode, and it runs only once a rule enables it at the organization, workspace, or device scope. Once enabled, cross-connector content detection is on by default. 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-connector 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 connector skip the cross-connector check.

​

Circuit Breaker

The Circuit Breaker guardrail protects availability. It watches each upstream connector’s error rate and latency over a rolling window and trips when a connector looks unhealthy, blocking further calls to that connector 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 connector:

• 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 connector are blocked for the cooldown period, with a retry-after hint. The runtime error keeps the wire vocabulary: circuit breaker open for server 'github-mcp': upstream is degraded, retry after 30s.
• 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 connector (or * for a shared breaker across every connector), 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

It is not what a new organization starts with. There, every built-in is enabled at organization scope in Monitor mode regardless of its catalog recommendation, so nothing blocks or redacts before anyone has reviewed it (see New Organization Defaults). In an organization created before that change, a built-in does not run at all until you enable it at a scope. 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 belong here, and a new organization already has them all enabled at this scope in Monitor. Promote the ones you want enforcing to Block or Redact, and enable any that are missing if your organization predates that default.
2. Tighten at the workspace level: Use a workspace rule where a workspace has to enforce harder than the organization does, for example moving a guardrail from Monitor to Block. A workspace rule that would relax the organization’s mode is discarded, so this is not the place to loosen an org-wide mandate.
3. Tighten at the device level: A device rule works the same way at the most granular scope. It is honored when it enforces harder than the workspace or organization rule above it, and discarded when it would weaken one.

​

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 connectors
• Multi-tenant environments: Layer workspace-level and device-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. This guardrail defaults to Block, and Redact is looser than Block, so set it at the scope where the guardrail is currently configured. Setting it at a narrower scope has no effect, because a narrower scope can only tighten

​

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 agent receives an error.
• Monitor: Allow and record. The request proceeds and the event is recorded.
• 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: Flag Unrecognized Connectors

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

1. Name: Flag unapproved connectors
2. Description: Flags tool calls routed to connectors not in the approved list
3. Trigger Conditions:
   • Field: Connector Name | Operator: not equals | Value: approved-connector-1
   • Field: Connector Name | Operator: not equals | Value: approved-connector-2
4. Enforcement Action: Monitor

​

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 device) 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, monitor, or redact)
  • The matched request context: operation, upstream connector, 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 > monitor > allow)
• The highest severity across all evaluations, which for guardrails means error > info. A block is recorded as ERROR and everything else as INFO, so the critical and warning levels the underlying comparator also ranks are not reachable from a guardrail evaluation

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 or ERROR severity
• Timestamp: When the evaluation occurred
• Context: The tool/action being evaluated, the MCP connector it targeted, the MCP agent that made the request, and the outcome (ALLOW, DENY, 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

Only a block raises the severity. Everything else a guardrail records, including a redaction, is INFO. A blocked call is recorded with the outcome Deny. 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