Decionis
Execution Authority · Compared: Model guardrails

Decionis vs model guardrails

Guardrails decide whether a prompt or a response is safe — injection, leakage, toxicity, off-policy content — inside the AI layer, in real time. Decionis decides whether the action the agent then takes may execute: allow, hold for a person, or block, with a signed record of the decision. Most agent deployments need both, and neither does the other's job.

The short version

Different questions, different tools

Choose Decionis when…

the risk is in what the agent does, not in what the model says: a clean, on-topic response that ends in a purchase over budget, a deploy to production, a refund issued twice. You need a judgement about that action, evaluated against your own policy at the moment it is proposed, a named person pulled in when the rules require one, and a record afterwards that someone outside your stack can verify.

Choose model guardrails when…

you are defending the model itself and the content passing through it: prompt injection, jailbreaks, sensitive-data leakage in outputs, toxicity, hallucinated or off-policy content, and the attack surface of a public-facing assistant. Guardrail libraries and AI security platforms are built for exactly that, sit where the tokens flow, and see things a per-action gate never sees.

Running both

A guardrail verdict is a fact the authority evaluation can read, not a substitute for it. Run guardrails where the model is; run Decionis where the action leaves — the tool call, the checkout, the deploy — and pass the guardrail's signal in as evidence. Then a hostile prompt that slips past the filter still meets a gate that evaluates the action on its own facts, and a clean prompt that produces an unauthorised action is refused for what it does rather than for what it said.

What the category is shipping

What this box is shipping for agents — and what it hands to Decionis

Check Point (Lakera)

Check Point completed its acquisition of Lakera and, with Google Cloud, describes a real-time decision layer for agents that moves from access control to outcome control — evaluating agent behaviour as it happens rather than only permissions.

Checked 2026-09-06 · Lakera — From access control to outcome control (retrieved 6 Sep 2026)

F5 AI Guardrails

F5 completed its acquisition of CalypsoAI and ships the result as F5 AI Guardrails and F5 AI Red Team: runtime protection for models and agents against injection and jailbreaks, and detection of sensitive-data leakage and policy violations.

Checked 2026-09-06 · F5 — completes its acquisition of CalypsoAI (retrieved 6 Sep 2026)

Operant AI

Operant's Semantic Firewall reads the intent behind each agent action and enforces an allow, block or redact decision inline, in real time. That is a semantic security signal at the inline control point; the public page does not describe a signed, independently verifiable record of what was authorised and what then executed.

Checked 2026-09-07 · Operant AI — Semantic Firewall (retrieved 7 Sep 2026)

Google (Gemini Enterprise Agent Platform)

Google's Semantic Governance Policies act as an intent gate: each proposed tool call is evaluated against the user's intent and business rules before it runs, enforced through Agent Gateway. Google's own documentation says the engine uses an LLM, that LLMs are probabilistic, and that verdicts may not be accurate — which is why a semantic verdict enters an execution authority as a signal and never as the final permission boundary.

Checked 2026-09-22 · Google Cloud — Semantic governance policies overview (retrieved 22 Sep 2026)

Each of these is an input to the authority decision, not a substitute for it — see “Running both” above.

Side by side

Where the two differ

DimensionDecionisModel guardrails
Question answeredMay this specific action execute, now, under this policy — and under whose approval?Is this input or output unsafe, hostile, or out of policy?
Unit of controlOne intended action with its amounts, target and context.A prompt, a response, or a tool-call payload, read as content.
Where it runsOutside the application that proposed the action, inline before the commit.Inside the AI layer, on the tokens as they flow — a gateway or a library the model is wrapped in.
What it readsThe action's own facts — amount, margin, counterparty, environment — against versioned policy.The text: patterns, classifiers, attack and anomaly signatures, sometimes a second model's judgement.
Human involvementA named person approves when policy requires it, bound to the specific action.Block, allow, or flag for review; a person sees the content, not a held action.
Evidence afterwardsA signed Decision Dossier per action that someone who does not run Decionis can re-derive.A security event log inside the platform — what was detected, not what was permitted and why.
The bypass problemThe gate sits on the action, so it holds whatever produced the action — a model, a script, a person.An agent that reaches the tool from outside the wrapped model reaches it unfiltered.
Asked directly

The questions this choice comes down to

Our guardrails already block risky tool calls. Isn't that authority?

It is a filter, and a good one to have. It decides on the content of the call, inside the layer the model runs in, and it records what it detected. Authority decides on the action against your policy — this amount, this counterparty, this environment — from outside the application, and records what was permitted and under whose approval in a form a counterparty can verify. The two answer different questions, and an agent that reaches the tool from elsewhere meets only the second.

The category, in full

Is Decionis 'outcome control'?

Outcome control needs an outcome you can point to. A real-time decision layer inside the AI stack can judge behaviour as it happens and log what it judged, and that log lives inside the platform that made the judgement. Decionis produces a signed record of the decision — policy version, inputs, verdict, approver — that re-derives outside the stack, and it refuses the action rather than scoring it. If the phrase means governing what happens rather than what is said, that is the third box, and this is what the third box ships.

Verify a dossier yourself

Do we still need guardrails if we run Decionis?

Yes. Decionis does not inspect prompts, detect injection or stop a model leaking data in a response, and it does not try to. Keep the guardrails on the model; put authority on the actions whose failure you would have to explain — payments, deploys, refunds, discounts, agent tool calls — and feed the guardrail's signal into the evaluation as evidence.

What teams gate first

How does a guardrail signal reach the decision?

As a fact in the request context, like any other signal. A policy can require a clean guardrail verdict before allowing an action, escalate when the verdict is uncertain, and block outright when it is hostile — and the dossier records which verdict it read, so the chain from detection to decision is checkable afterwards.

What the dossier records

See a governed decision before you change anything

Run a scenario in the sandbox and download the signed Decision Dossier it produces, or install shadow mode and watch what would have been held on your own traffic.

Start Now