Security & Policies
Rules agents can't talk their way past, checked before every action.
- Input, output and retrieval rails
- QASA authorizes every tool call
- Policy over policy at load time
Runtime governance for multi-agent systems
QuadRails observes every agent action and runs it on four pillars: security and policies, evals, cost and performance. Underneath them, OXP traces and explains every decision, so you can prove each control works.
Why QuadRails
Most frameworks let any agent call any tool. There is no clearance, no gate and no record of why it was allowed.
Dashboards show what happened. They don't stop what shouldn't happen, and they can't tell you whether a guardrail would have caught it.
Policies are written for reviewers. Engineering has no way to enforce them on every agent, in every team, at every step.
The platform
Each rail is a set of controls with an owner, a test and a reason to change it. All four sit on one observability foundation, because a guardrail you can't trace is a guardrail you can't trust.
Rules agents can't talk their way past, checked before every action.
Proof that an agent is good enough to ship, and stays that way.
Budgets enforced before the model runs, not discovered on the invoice.
Controls that stay fast enough to leave on in production.
OXP, the Observability and Explainability Platform, traces every action, tool call and verdict, scores each session and explains every decision.
Test scenarios
Run your multi-agent system against the same scenario twice, with guardrails off in an isolated sandbox and on in a protected run. Compare the outcome, the trace and the cost.
User asks for an account summary. The agent proposes delete_records.
Tool executes. 412 synthetic records removed.
No record of why the call was allowed.
Blocked before the backend. Zero calls made.
Reason: tool not in the agent's manifest for this task.
A retrieved file tells the agent to export customer data to an outside address.
Agent follows the hidden instruction and sends the export.
The retrieved text was treated as trusted.
Source marked untrusted. Export blocked.
The trace shows exactly where the instruction came from.
User asks to clean up old records. The agent proposes an irreversible delete.
Records deleted on the agent's reading of “clean up”.
Nobody was asked.
Paused for a person to approve, edit or reject.
The approver sees the evidence, not the agent's summary of it.
User asks for an account balance. The agent proposes get_balance.
Balance returned.
Same answer, no evidence trail.
Allowed in 14 ms. Balance returned.
Not everything gets blocked: in-scope work runs at full speed.
An agent loops on repeated model calls past the team's daily cap.
Calls continue until someone notices the bill.
Spend is reconciled weeks later.
Reservation fails at the cap. Agent throttled.
Routed to a cheaper approved model or stopped, per policy.
How it works
QuadRails intercepts execution before a tool fires, after a model responds and whenever one agent hands work to another. Deterministic rules decide first; a model judge can only add restrictions.
A prompt, plan, tool call or hand-off to another agent.
A QASA sidecar beside the agent catches it.
Identity, scope, budget and intent are checked.
Allow, block, modify, escalate or throttle.
Only approved tools appear in the agent's token.
The decision and its evidence land in OXP.
Security coverage
Every risk has a primary control, and most have two. No single guardrail is enough on its own.
Built by Quadrant Technologies
Healthcare, finance and public sector: guardrail profiles mapped to risk tiers, with a full audit trail.
One policy engine for every team's agents, without slowing anyone's release.
Guardrails that travel with the agent from development to production.
A QuadRails session runs your agent through real scenarios with guardrails off and on, and hands you the traces.