> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ultra.security/llms.txt
> Use this file to discover all available pages before exploring further.
# Guardrails
> 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.
## 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:
| Mode | Behavior |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Block** | Prevents the request from reaching the upstream server. The client receives a structured error with the guardrail name, the rule that fired, a redacted excerpt of the matched content, and a remediation hint so the agent can recover or surface a useful message to the user. |
| **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.
### Scoping
Guardrails can be configured at three levels, with higher levels taking precedence:
| Scope | Description |
| ---------------- | ------------------------------------------------------------------------------------------------- |
| **Organization** | Applies to all workspaces and gateways in your org. Org-level settings override everything below. |
| **Workspace** | Applies to all gateways in a workspace. Overrides gateway-level settings. |
| **Gateway** | Applies to a single gateway. Most granular scope. |
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 are recommended in the catalog, but a built-in only runs when it has been explicitly enabled at the organization, workspace, or gateway scope. Catalog defaults describe the recommended starting configuration; they do not activate a guardrail on their own.
## 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.
| 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. |
| **PII and Personal Data Protection** | Data Privacy | Detects personally identifiable information (PII) in tool call parameters and resource URIs, including email addresses, US Social Security numbers, phone numbers, credit cards (Luhn-validated), IBANs, cryptocurrency wallet addresses, BIC/SWIFT codes, and IPv4 addresses. Optional, default-off PHI detection covers labeled health identifiers and medical codes (medical record numbers, patient IDs, ICD-10, CPT, and HCPCS codes). Each category is independently toggleable, and a per-tool or per-resource bypass list lets you exempt internal tools that legitimately handle PII (such as HR or CRM lookups). |
| **Tool & Server Isolation** | Isolation | Tracks the values an MCP session has read from one server and blocks them from being written to a different server in the same session. Stops cross-server exfiltration patterns where an agent reads sensitive data from one tool and then sends it to a second one. Also supports a forbidden tool-sequence blocklist (for example, `github.read_repo → slack.post_message`). |
| **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. |
| **Circuit Breaker** | Infrastructure | Watches each upstream server's error rate and latency and automatically blocks traffic to a server that is failing or slow, then probes for recovery before restoring it. Protects against cascading failures and resource exhaustion during an upstream outage. |
### 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.
PII categories are detected via regular expressions, with additional validation for high-noise patterns: credit cards are validated against the Luhn check digit, IBANs are restricted to country codes in the SWIFT registry, and BIC codes are validated against ISO 3166-1 alpha-2 country codes. Some structurally similar strings (like long base58 hashes resembling Bitcoin addresses) can still false-positive: start in **Alert** mode if you are unsure how the guardrail will behave against your traffic.
### 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:
| Setting | Default | Description |
| -------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------- |
| **Server** | | MCP server to protect. Use `*` for a shared breaker across all servers. |
| **Window (seconds)** | `60` | Rolling window over which error rate and latency are measured. |
| **Minimum Requests** | `20` | Minimum requests in the window before the breaker can trip, so small samples don't trip it. |
| **Error Rate Threshold** | `0.5` | Fraction of failing requests (0 to 1) that trips the breaker once the minimum is met. |
| **Latency Threshold (ms)** | `0` | Requests slower than this count as failures. `0` disables latency-based tripping. |
| **Cooldown (seconds)** | `30` | How long the breaker stays open before probing for recovery. |
| **Half-Open Probes** | `3` | Probe requests allowed while half-open. The breaker closes when all probes succeed and re-opens on the first failure. |
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:
| Category | Description | Built-in Guardrails |
| -------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| **Input Protection** | Validates and sanitizes incoming tool call parameters | Parameter Validation and Input Sanitization |
| **Data Protection** | Prevents credential leakage and secret exposure | Credential and Secret Protection |
| **Data Privacy** | Detects and protects personally identifiable information, including optional health information (PHI) | PII and Personal Data Protection |
| **Access Control** | Enforces authorization and blocks destructive actions | In-Line Authorization and Destructive Action Blocking |
| **Isolation** | Tracks content flow across servers within a session and blocks cross-server data movement | Tool & Server Isolation |
| **Output Safety** | Filters and validates tool call responses | None |
| **Infrastructure** | Rate limiting, circuit breaking, and availability protection | Rate Limiting, Circuit Breaker |
## 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
| Scenario | Recommended Mode |
| ---------------------------------------------------- | ---------------------------------------------------------------- |
| Production environments with sensitive data | **Block**: Prevent threats from reaching upstream servers |
| New deployment, evaluating guardrail coverage | **Alert**: See what would be caught without disrupting workflows |
| Development or staging environments | **Monitor**: Log everything for visibility, allow all requests |
| Handling sensitive data that must not appear in logs | **Redact**: Mask matched content in requests and responses |
### 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:**
| 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 |
| **User ID** | The authenticated user's identity ID. Empty string for unauthenticated requests. |
| **User Email** | The authenticated user's email address. Empty string for unauthenticated requests. |
| **User Name** | The authenticated user's display name. Empty string for unauthenticated requests. |
| **Client ID** | The MCP client name from the connection handshake (e.g., `claude-desktop`, `cursor`). Empty string when unknown. |
| **Client Version** | The MCP client version from the connection handshake (e.g., `1.2.3`). Empty string when unknown. |
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.
User and client identity fields are always present in the evaluation context. When the request is unauthenticated or the client identity is unknown, these fields contain an empty string. Keep this in mind when writing regex conditions: patterns that match empty strings (like `.*`) will match unauthenticated requests.
**Available operators:**
| Operator | Description |
| --------------- | ---------------------------------------------- |
| equals | Exact match |
| not equals | Does not match exactly |
| contains | Value includes the specified string |
| not contains | Value does not include the specified string |
| starts with | Value begins with the specified string |
| not starts with | Value does not begin with the specified string |
| ends with | Value ends with the specified string |
| not ends with | Value does not end with the specified string |
| matches regex | Value matches a regular expression pattern |
| in list | Value is one of a comma-separated list |
| greater than | Numeric comparison |
| less than | Numeric comparison |
When matching against email domains, prefer **not ends with** over **not contains**. For example, `not ends with "@company.com"` correctly blocks `attacker@company.com.evil.com`, while `not contains "@company.com"` would let it through because the substring match succeeds.
### 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.
Dry-run is not available for guardrails whose evaluator is stateful across requests (currently **Tool & Server Isolation** and any other content-flow guardrail). These guardrails record live session state during evaluation, so replaying them against historical traces would pollute the running session tracker and skew real-traffic decisions. The dry-run controls are hidden on the detail panel for these guardrails.
### 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:
| Range type | Presets | Custom range |
| --------------- | ------------- | ---------------- |
| **Last events** | 100, 250, 500 | 1 to 1000 events |
| **Past time** | 1h, 1d, 3d | 1 to 168 hours |
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.
A disabled draft has no effect on live traffic. It only stores the configuration so the dry-run engine has something to evaluate against. To start enforcing the draft, enable the guardrail from the detail panel.
### When to use dry-run
| Scenario | Why dry-run helps |
| --------------------------------- | --------------------------------------------------------------------------------------- |
| Enabling a new built-in guardrail | Save a disabled draft, dry-run it, and review the impact before flipping it on |
| Tuning rate-limit thresholds | See how different `requests_per_window` and `window_seconds` values affect real traffic |
| Changing enforcement modes | Understand what would change if you move from Monitor to Block |
| Custom guardrail validation | Verify your trigger conditions match the intended requests |
Start guardrails in **Monitor** mode, run a dry-run after a few hours of traffic, review the results, then promote to **Block** once you are confident in the coverage.
## 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
| Outcome | Severity | Description |
| ----------- | -------- | ---------------------------------------------- |
| **Allow** | INFO | Guardrail evaluated and found no issues |
| **Monitor** | INFO | Guardrail matched but is in monitor mode |
| **Alert** | WARNING | Guardrail matched and generated a notification |
| **Redact** | WARNING | Guardrail matched and masked sensitive content |
| **Block** | ERROR | Guardrail matched and prevented the request |
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
LLM-powered security analysis for MCP tool calls
View guardrail enforcement events alongside all MCP activity
Control who can configure and view guardrails
Monitor guardrail activity in the web dashboard