Guardrails
Guardrails are safety controls that govern how agents interact with your connected business systems. They let you set rules on individual tool calls: requiring approval before a high-value action runs, blocking certain operations entirely, hiding sensitive fields from results, or flagging calls for review after they run.
There is no dedicated Guardrails page in Settings. Guardrails are a per-connection construct: you configure them on each MCP connection, alongside the tools that connection exposes. Which tools an individual agent may call, and at what risk and assurance level, is set separately on that agent. This page covers the connection-level guardrails.
Without guardrails, an agent can use any tool assigned to it, with no restrictions. Guardrails give you control over which calls proceed on their own and which ones need a person.
Why guardrails matter
Section titled “Why guardrails matter”When you connect a business system through the MCP hub, its tools become available to your agents. An order-management connection might expose tools such as “create_refund”, “update_order”, and “get_customer”. Some of these are low-risk lookups. Others can change data or trigger financial transactions.
Guardrails let you draw the line. You decide which actions an agent can take on its own and which ones need a person to review first. For example:
- Refunds over a certain amount need manager approval.
- Agents should never delete customer records.
- Customer phone numbers should be hidden from the agent.
- High-value quotes should be flagged for a person to review after the agent creates them.
The four guardrail types
Section titled “The four guardrail types”Each guardrail uses one of four policy types. Choose the type that matches the level of control you need.
| Type | What happens | When to use |
|---|---|---|
| Require approval | The tool call is paused. An operator must approve or reject it before it runs. | High-value or irreversible actions, such as refunds above a threshold or contract changes. |
| Deny | The tool call is blocked entirely. The agent receives a denial and cannot retry. | Operations that should never happen automatically, such as deleting accounts or overriding pricing. |
| Mask | The tool call runs, but the fields you name are hidden from the result before the agent sees it. | Sensitive data the agent does not need, such as raw phone numbers, national ID numbers, or internal cost prices. |
| Escalate | The tool call runs normally, but the conversation is flagged for a person to review afterwards. | Situations that need oversight after the fact, such as a denied return for a valued customer or a warranty claim that exceeded coverage. |
Adding a guardrail
Section titled “Adding a guardrail”Guardrails are configured per MCP connection. To add one:
- Go to Settings, then MCP Hub.
- Select the connection you want to add a guardrail to. This opens the connection detail page.
- Scroll down to the Guardrails section.
- Select Add guardrail. A panel opens on the right side of the page.
- Fill in the guardrail fields, described below.
- Select Add guardrail to save.
The guardrail takes effect immediately. Any future tool call that matches its criteria is governed by it.
Guardrail fields
Section titled “Guardrail fields”| Field | Description |
|---|---|
| Tool | Choose which tool this guardrail applies to. Select a specific tool from the list, such as “create_refund”, or choose All tools to apply the guardrail to every tool on this connection. |
| Action | The policy type: Require approval, Deny, Mask, or Escalate. |
| Condition | An optional expression that decides when the guardrail activates. When left empty, the guardrail applies to every call of the selected tool. See “Conditions” below. |
| Fields to mask | Shown only when the action is Mask. A comma-separated list of field names to hide from the tool’s result, such as “email, phone”. |
Conditions
Section titled “Conditions”A condition lets you create guardrails that only activate in specific situations rather than on every call. By default, a guardrail applies to every call of the selected tool. Select Add condition to restrict it.
The condition builder has three fields in a single row:
| Field | What to enter |
|---|---|
| Field name | The name of the argument you want to check, such as “amount”, “total”, or “quantity”. This is the name your business system uses for the value. |
| Operator | How to compare the value. Options include: equals, does not equal, is greater than, is less than, is at least, is at most, and contains. |
| Value | The threshold or value to compare against, such as “5000”, “delete”, or “premium”. |
For example, to require approval for refunds over 5,000, enter: amount / is greater than / 5000.
Some common condition setups:
| Field | Operator | Value | Effect |
|---|---|---|---|
| amount | is greater than | 5000 | Activates when the amount exceeds 5,000 |
| quantity | is at least | 100 | Activates when quantity is 100 or more |
| status | equals | shipped | Activates when status is “shipped” |
| (no condition) | Activates on every call |
If you are unsure which field names your tool uses, check the tool description on the connection detail page. It usually mentions the key arguments and their names. You can also ask your technical team or MCP server provider for the field names.
Advanced conditions
Section titled “Advanced conditions”Conditions use a sandboxed expression language. The condition builder covers common cases, but you can write expressions directly for more complex rules. Expressions can reference args (the tool input), result (the tool output, for Escalate only), and context (conversation and account context).
The syntax supports dot notation (args.order.total), comparisons (>, <, >=, <=, ==, !=), boolean operators (and, or, not), arithmetic (args.quantity * args.unit_price > 50000), and quoted strings (context.account.tier == "vip").
| Expression | What it does |
|---|---|
args.total > 50000 | Activates when the total exceeds 50,000 |
args.quantity > 100 and args.unit_price > 500 | Activates when both quantity and unit price exceed their thresholds |
args.quantity * args.unit_price > 50000 | Activates when the calculated order value exceeds 50,000 |
context.account.tier == "vip" | Activates for valued accounts regardless of the tool arguments |
Risk classification
Section titled “Risk classification”Each tool on a connection has a risk classification that describes the type of operation it performs. You set this in the tools table on the connection detail page by choosing from the list next to each tool.
| Classification | Meaning | Example tools |
|---|---|---|
| Read | The tool only retrieves data. It does not change anything. | get_order, search_products, get_customer |
| Write | The tool creates or modifies data. | create_quote, update_status, send_notification |
| Destructive | The tool deletes data or performs an irreversible action. | delete_customer, cancel_subscription, issue_refund |
Risk classification helps you and your team understand at a glance what each tool does. It also informs the safety pipeline: destructive tools are strong candidates for an approval gate. All tools default to “write” when first discovered, so review each tool and adjust the classification to match what it actually does.
The approval flow
Section titled “The approval flow”When a guardrail with the “Require approval” type activates, the tool call is paused and the conversation is handed to an operator. Here is what happens from the operator’s side:
- The agent reaches a tool call that matches an approval-gate guardrail, for example a refund of 8,000 against a threshold of 5,000.
- The tool call does not run. The conversation pauses.
- An Approval needed card appears in the conversation view, showing which tool was called, what arguments were passed, and why the guardrail triggered.
- The operator reviews the details and selects Approve or Reject.
- If approved, the agent resumes and the tool call runs with the original arguments.
- If rejected, the agent receives a denial and continues the conversation without that action. It may offer the customer an alternative or explain that the request needs to be handled another way.
The approval flow keeps a person in the loop for high-stakes actions while everyday operations continue automatically.
Managing guardrails
Section titled “Managing guardrails”All guardrails for a connection are listed in the Guardrails section of the connection detail page. Each guardrail shows the tool it applies to, the policy type, and any condition or masked fields.
To remove a guardrail, select the delete control next to it. The change takes effect immediately.
You can add multiple guardrails to the same connection. For example, you might have an approval gate on “create_refund” when the amount exceeds 5,000, a deny rule on “delete_customer” for all calls, and a mask rule on “get_customer” that hides the phone and email fields.
Examples
Section titled “Examples”Here are some common guardrail configurations:
Approve large refunds. Tool: create_refund. Action: Require approval. Condition: amount / is greater than / 5000. Any refund above 5,000 needs operator approval.
Block account deletion. Tool: delete_account. Action: Deny, no condition. No agent can ever delete an account through this connection.
Hide personal contact details. Tool: get_customer. Action: Mask. Fields to mask: email, phone. The agent can look up customer records but will not see raw email addresses or phone numbers in the result.
Flag denied returns for review. Tool: process_return. Action: Escalate, no condition. Every return the agent processes is flagged for a person to review after the fact.