Guardrails
Writing a custom guardrail
Guardrails are YAML files in a Git repo your team owns. Add a rule for your bank's tokenization gateway in five minutes.
VibeReview's guardrails live in a repository you control. Each rule is a YAML file. Adding a custom guardrail is a Git PR, not a vendor support ticket.
Anatomy of a guardrail
A guardrail YAML names the trigger (file pattern, intent class, or risk category), the policy (what the agent must do), the anti-pattern (what to avoid), the mapping (OWASP, CWE, framework controls), and the severity. Five fields. The agent reads it as instructions.
Example: a tokenization gateway rule
Say your bank requires every customer-PAN write to route through the tokenization gateway at /tokenize. A guardrail fires on file patterns under /payments/ and instructs the agent: PANs must be tokenized at /tokenize before any storage call. The anti-pattern is direct PAN insertion into the database. The mapping is PCI DSS Requirement 3.5.
Reviewing and merging
Open a PR on the guardrails repo. Your AppSec team reviews it like any other code change. Merge. VibeReview reloads the rule on the next prompt. No deploy, no restart, no vendor ticket.