Why guardrails matter
Telling an agent “don’t email external domains” in its instructions is helpful, but not foolproof. LLMs can be tricked, confused, or make mistakes. Guardrails provide a hard limit that works regardless of what the agent thinks it should do. The agent never gets a chance to override this—the check happens at the platform level before the action executes.Capability-specific guardrails
Different capabilities have different guardrail options. Configure these in each capability’s settings.
| Setting | Options | What it does |
|---|---|---|
| Whitelist | Domains or specific addresses | Agent can only email addresses on the list |
| Approval | No / Yes / Not on whitelist | When human approval is required |
Other capabilities
- SMS and Phone calls — Similar guardrails (whitelists, approval, limits). See Email & SMS and Voice for details.
- HTTP requests — Optional approval for each request. See HTTP Requests for details.
Configuring guardrails
- Open the agent and navigate to Capabilities in the sidebar
- Click on the capability you want to configure (Email, SMS, Phone, etc.)
- Set whitelists, approval requirements, and any limits
- Test by trying an action that should be blocked or require approval
Workspace-level controls
Workspace administrators can control which capabilities are available to agents across the workspace. This is configured in Agent Management.
| Control | What it does |
|---|---|
| Capability toggles | Enable or disable specific capabilities workspace-wide |
| Default mode | Whether new capabilities are allowed or blocked by default |
| Custom MCP servers | Allow or block users from adding their own MCP servers |
If your workspace uses teams, team administrators can set additional restrictions for their team, but cannot enable capabilities that are disabled at the workspace level.
Best practices
Start restrictive. Begin with tight guardrails—require approval for external communication, limit capabilities to what’s needed. You can always loosen them as you gain confidence. Use “Not on whitelist” approval. This lets agents work freely within your organization while requiring approval for external contacts. It’s a good balance of autonomy and safety. Review blocked and approved actions. Check the activity log periodically to see what’s being blocked or approved. This helps you identify false positives (legitimate actions being blocked) and tune your configuration. Match guardrails to risk. A customer-facing agent needs tighter guardrails than an internal research assistant. See Risk & Autonomy for guidance on assessing risk.FAQ
Can an agent bypass guardrails through clever prompting?
Can an agent bypass guardrails through clever prompting?
No. Guardrails are enforced by platform code, not LLM reasoning. The agent can’t talk its way past a whitelist check—the platform simply won’t execute the blocked action.
What happens when an action is blocked?
What happens when an action is blocked?
If approval is required, the action goes to the approval queue (see User Approval). If the whitelist is strict (no approval option), the action fails and the agent is notified that the recipient isn’t allowed.
Can I set guardrails that apply to all agents?
Can I set guardrails that apply to all agents?
Yes. Workspace administrators can disable capabilities workspace-wide in Agent Management. Per-agent guardrails (like whitelists) are still configured individually.
Learn more
User Approval
How the approval queue works
Security Agent
LLM-based plan review that complements guardrails
Agent Management
Workspace-level capability controls