Guardrails

Guardrails are technical constraints enforced by platform code—not by LLM reasoning. This is a critical distinction: even if an agent is manipulated through prompt injection or given conflicting instructions, guardrails cannot be bypassed. The platform simply won’t execute the action.

​

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.

​

Email

A typical setup is restrict-on with “send inside” and “ask outside” — the agent can email known contacts freely, and you review anything new. When restriction is off, you instead get a single “ask before every email” toggle. See User Approval for how the approval flow works.

​

Other capabilities

• SMS and Phone calls — Same allow-list plus inside/outside-list approval model. See Email & SMS and Voice for details.
• HTTP requests — Optional approval for each request. See HTTP Requests for details.

​

Configuring guardrails

1. Open the agent and navigate to Capabilities in the sidebar
2. Click on the capability you want to configure (Email, SMS, Phone, etc.)
3. Choose whether to restrict recipients, configure the allow-list, and set the inside-list and outside-list rules
4. 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 Workspace management under the Capabilities tab. They can also limit which LLM models agents may pick for new work under Workspace management → Model selection (models disabled platform-wide by Abundly cannot be turned on there). Capabilities disabled at the workspace level cannot be enabled by individual agents. Workspace administrators can also configure attack detection notification behavior in Workspace → Settings.

​

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. Combine an allow-list with “ask for approval” outside it. This lets agents work freely with known contacts inside your organization while routing anything new through you. 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

​

Learn more