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
Organization-level controls
Organization administrators can control which capabilities are available to agents across the organization. This is configured in Agent Management.
| Control | What it does |
|---|---|
| Capability toggles | Enable or disable specific capabilities organization-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 organization uses groups, group administrators can set additional restrictions for their group, but cannot enable capabilities that are disabled at the organization 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. Organization administrators can disable capabilities organization-wide in Agent Management. Per-agent guardrails (like whitelists) are still configured individually.