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.
Guardrails are configured per connection, on each MCP connection’s page, alongside the tools that connection exposes. Each tool’s risk classification and assurance level are set on the same page, and its scope under Settings → Customer records; none of them is set on the agent. See Assurance levels. This page covers the guardrails.
An agent calls only the tools assigned to it, and every call is checked against the tool’s risk classification, the assurance level it requires and its declared scope before it runs. Guardrails add control over which of those 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. |
A field chosen under Settings → Customer records as the customer’s CPR number or MitID UUID is hidden automatically from every tool result the agent sees on that connection.
Adding a guardrail
Section titled “Adding a guardrail”Guardrails are configured per MCP connection. To add one:
- Open MCP hub in the sidebar.
- 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 Risk column of the tools table on the connection detail page.
| Classification | Meaning | Example tools |
|---|---|---|
| read | The tool retrieves data and reads nothing personal. | search_products, get_opening_hours |
| read (PII) | The tool retrieves personal data. | get_order, get_customer |
| write | The tool creates or changes data, nothing personal. | update_status, create_ticket |
| write (PII) | The tool creates or changes data that touches personal data. | create_quote, update_address |
| destructive | The tool performs an irreversible or financially material action. | delete_customer, cancel_subscription, issue_refund |
The classification gives each tool its default assurance level, described on Assurance levels. A destructive tool also requires operator approval on every call by default, whether or not a guardrail names it. A tool the connection describes as read-only is first classified read (PII), one it describes as destructive is classified destructive, and every other tool starts as write (PII). Review each tool and adjust the classification to match what it does. A tool with no classification is declined on every call, and so is a tool with no declaration under Settings → Customer records (Finding your customers).
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.