Platform
QuadRails defines guardrails once, enforces them on every agent at runtime, observes every decision through OXP and retires controls when the evidence says they no longer work.
guardrail:
id: GR-TC-001
name: "Restricted tool enforcement"
category: tool-calling
trigger:
event: tool_call_requested
condition: "tool_name IN restricted_tools"
enforcement:
mode: BLOCK # BLOCK | MODIFY | ESCALATE | LOG
escalation_target: security-team
thresholds:
max_calls_per_minute: 30
circuit_breaker: 3
scope:
applies_to_rings: [2, 3]
meta:
owner: platform-governance
approved_by: security-leadFour pillars
Guardrails fail quietly when nobody owns them. Every QuadRails control belongs to a pillar, is tested on a schedule and has a written condition for when it changes or retires.
Owned by platform governance and security engineering.
Owned by the AI evaluation team.
Owned by FinOps.
Owned by platform and SRE.
The Observability and Explainability Platform records every action and verdict, so each pillar's test runs on evidence instead of opinion.
Guardrail categories
Rule-based guardrails are fast and predictable. Semantic guardrails use a model to catch meaning that rules miss. A model judge can tighten a decision but never loosen a rule.
Prompt injection, jailbreaks, toxicity and out-of-scope requests.
Before the prompt reaches any agent
BLOCK · REWRITE · WARN · LOG
PII masking, hallucination checks, schema and confidentiality.
After the response, before delivery
BLOCK · REDACT · REPHRASE · LOG
Source validation, document permissions, groundedness and poisoning.
On every knowledge-base query and result
BLOCK · FILTER · REDACT · LOG
Tool allow-lists, argument limits, restricted tools and rate limits.
Between the tool decision and execution
BLOCK · MODIFY · ESCALATE · LOG
Resource quotas, sandboxing, timeouts, write controls and an off switch.
Continuously while the agent runs
HALT · THROTTLE · SANDBOX · ALERT
Goal alignment, step-level checks, budget pre-flight and scope creep.
After a plan is made, before it runs
REJECT · PRUNE · ESCALATE · LOG
Agent identity, trust gating, signed messages and delegation rights.
At every agent-to-agent hand-off
BLOCK · QUARANTINE · VERIFY · LOG
Guardrail lifecycle
Every guardrail is one YAML policy in a single schema, rolled out in stages and measured before it is allowed to block.
Write the guardrail as policy: category, trigger, mode, thresholds, scope, owner. The author can't approve their own policy.
Sandbox first, then shadow it against production traffic in log-only mode before it touches a request.
Trigger, block and false-positive rates, plus latency overhead, tracked per guardrail in OXP.
Retire when false positives stay above 15% or nothing triggers for 30 days. Retirement is an approved, audited change.
QASA, Agent Security Authorization
QASA puts a policy sidecar beside every client, agent and tool server. Each tool call is checked at token exchange, and only approved tools appear in the token the agent receives.
tool_not_selected_by_llmno_llm_calls_made_by_apptool_intent_mismatchMeta-governance
Teams write their own guardrails. QuadRails validates every one at load time and rejects anything that weakens the enterprise baseline, like an admission controller for AI policy.
OWASP coverage
Every OWASP agentic risk has primary coverage from at least one guardrail category, and most from two or more.
We'll run one of your agents through QuadRails and walk you through every decision it made.