Build
Guardrails
Workspace policies that constrain cost, models, and inbound content. Create a guardrail once, then attach it to one or more agents from the dashboard — coding agents do not encode provider secrets or OAuth here.
What you can enforce
Budget
Cap spend for a day, week, or month (USD cents). Optionally include BYOK usage in the limit so self-keyed traffic still respects the ceiling.
Model access
Allow all models, allow-list specific providers/models, or block-list — keep production agents on approved SKUs.
Prompt injection
Fast OWASP-inspired heuristics on inbound user text. Action: off, redact, or block the turn.
Sensitive info
Email, phone, SSN, credit card, IP, plus custom regex patterns — each with off / redact / block.
Create and attach
Open the Guardrails area in the cloud dashboard (or the agent Build → Guardrails tab). Define budget, model access, prompt injection, and sensitive-info actions, save the policy, then attach it to the agents that should inherit it.
- Create a named guardrail with the controls you need.
- Attach it to one or more agents (many agents can share one policy).
- Re-run a Test or CLI
run— blocked or redacted turns surface in the run result / Monitor.
Budget attachments can also bridge into the agent's monthly token / spend view so Monitor stays aligned with the same policy.
Actions
| Action | Effect |
|---|---|
| off | Control disabled for that field |
| redact | Replace matches (or injection spans) and continue |
| block | Reject the turn before the model runs |
With coding agents
Keep policy configuration in the dashboard. In the repo, coding agents should document intended constraints in prompt.md / evals, but enforcement for budget, model gates, injection, and PII lives on attached guardrails — see Coding agents.
Repo: tools, prompt, evals that assume policy X Cloud: Guardrails → create policy → attach to agent Verify: rails-agents run … or Dashboard → Test