AI guardrails are controls that inspect what goes into a model and what comes back, and act on what they find — blocking, redacting, rewriting or flagging. They sit around the model rather than inside it, which is what makes them governable: a guardrail has a policy, a version and a record, where a model's own refusal behavior has none of those.
Input side and output side do different jobs
Input guardrails examine the prompt before it reaches the model: sensitive data detection, topic restriction, jailbreak patterns, instruction-shaped content arriving from a retrieved document. They prevent.
Output guardrails examine the completion before it reaches the caller: leaked training data, sensitive content the model assembled from permitted parts, tool calls the model decided to make. They contain.
Teams commonly deploy the first and skip the second, which leaves the failure mode that matters most in an agentic system. An injection that succeeds produces its effect on the way out, not on the way in — see indirect prompt injection.
How they differ from model alignment
A model's own refusal behavior is trained in. It cannot be versioned, differs between providers, changes when the provider updates the model, and produces no record an auditor can read. It is a property of a vendor's artifact, not a control your institution operates.
A guardrail is a control you own. It has a rule expressed as policy as code, a version identifier written into every decision, and an entry in a tamper-evident log. When an examiner asks what prevented an action, the first cannot answer and the second can.
They also differ in where they fail. Alignment degrades quietly under adversarial pressure. A guardrail either fired or did not, and the record says which.
Where they have to sit
A guardrail implemented in application code governs that application. Another team ships without it, and an agent calling the same model bypasses it entirely. Placed at the gateway, on the request path every caller shares, it governs the estate — which is the same coverage argument as DLP for AI and the reason guardrails belong in the control plane rather than the SDK.
Two design points decide whether they hold. Deny must override allow, or a permissive rule silently defeats a restrictive one. And the guardrail must be able to redact and coach as well as block, because a control that only refuses gets routed around, and a control that is routed around governs nothing.
Smartflow's guardrails are configured in the visual policy editor and enforced inline — see the enterprise AI firewall guide, APERION Shield for the local runtime case, and platform capabilities for the control set.
Related terms
Prompt injection · Jailbreak · DLP for AI · Runtime governance · Full glossary
Put this in the path of your own agents.
Policy enforced inline between your agents and every model and tool they reach, with a record bound to the human who owns it.
Request a Demo Read the docs