What are AI agent guardrails?

AI agent guardrails are rules that check or control what an agent does, either before it acts (blocking a request) or after it responds (blocking, redacting, or holding the output). They range from security filters that catch known-bad content to business-logic rules that catch a well-formed but incorrect decision.

What's the difference between AI security guardrails and business-logic guardrails?

Security guardrails, the kind tools like Lakera or NVIDIA NeMo Guardrails focus on, catch prompt injection, jailbreak attempts, and PII or secret leakage: content that is recognizably bad regardless of context. Business-logic guardrails catch an agent making a confident, well-formatted, policy-violating decision, like approving a refund outside the return window, that isn't a security problem at all. The response is safe. It's just wrong for your business.

Do I need security guardrails if I already have business-logic guardrails, or vice versa?

Both, for different reasons. A prompt injection attempt and a policy-violating refund approval are different failure classes with different detection methods; a tool built for one typically doesn't catch the other. Most production agent stacks that take real actions need a security layer for adversarial input and a policy layer for correctness against actual business rules.

Can a guardrail catch a wrong tool call argument?

Yes, if it's written to check the argument against the rule that governs it, such as a refund amount exceeding a ceiling or a discount code applied outside its valid window. Generic content-safety guardrails don't check this, because a wrong argument isn't unsafe content: it's a well-formed function call with an incorrect value.

AI Agent Guardrails for Production: Beyond Security Filters

Name: Zespan
Brand: Zespan
Availability: InStock

Search "AI agent guardrails" and most of what comes back is about stopping prompt injection, jailbreaks, and PII leakage. That's a real and necessary category. It's also not the failure mode that's actually costing production teams money.

An agent that approves a $4,000 refund against a $2,000 policy ceiling isn't a security incident. Nothing was injected, nothing was jailbroken, no secret leaked. The response is safe, well-formatted, and confidently wrong. A guardrail built to catch adversarial content has nothing to say about it.

What security guardrails actually catch

Tools in this category — Lakera, NVIDIA NeMo Guardrails, Guardrails AI, and similar — are built around a specific threat model: an adversarial or malformed input trying to manipulate the model into doing something it shouldn't. Their core job:

Prompt injection: a user or a retrieved document embedding instructions designed to override the agent's actual task
Jailbreak attempts: inputs crafted to get the model to bypass its safety training
PII and secret leakage: the agent including a credit card number, an API key, or personal data in a response where it shouldn't
Toxic or off-brand content: output that's harmful, offensive, or outside acceptable topics

This is real, necessary protection, and if you're exposing an agent to untrusted input, you need it. It's also a narrow slice of what goes wrong with an agent that takes real actions in production.

What security guardrails don't catch

None of the categories above cover an agent that's doing exactly what it was asked, safely, in a well-formed response, while getting the actual business decision wrong:

Approving a refund outside the policy window. Nothing unsafe about the content. It's just not true that the customer qualifies.
Calling a tool with a wrong argument. A refund-issuing tool called with amount: 4000 when the policy ceiling is 2000. The function call is syntactically correct and safe. The value is wrong.
Quoting a stale price or an incorrect delivery date. Confidently stated, well-formatted, factually wrong.
Skipping a required disclosure or escalation. The agent doesn't say anything harmful; it fails to say something it was supposed to.
Making a decision it wasn't authorized to make at all, correctly or not — approving a claim, waiving a fee, committing to a delivery date — where the real question isn't "was this safe" but "was this agent allowed to decide this."

A security-focused guardrail has no rule for any of this, because none of it is adversarial. It's a correctness problem against your specific business logic, and generic guardrail tools have no way to know what your business logic is.

Why this distinction matters for production agents

If your agent only summarizes documents or answers general questions, security guardrails plus decent prompting may be most of what you need — the blast radius of "gave a slightly wrong answer" is limited. The calculus changes once an agent takes real actions: issuing refunds, approving claims, quoting prices, committing to terms, making calls. At that point, a well-formed but policy-violating decision has the same real-world cost as a security breach, sometimes worse, because it's harder to detect. A jailbreak attempt at least looks suspicious in the transcript. A confidently wrong refund approval reads exactly like a correct one.

This is the same distinction covered in how to know when an AI agent is wrong in production: the failure that costs you money doesn't look like a failure. It looks like a normal, successful, safe transaction that happens to be wrong.

What a business-logic guardrail actually checks

Where a security guardrail pattern-matches against known-bad categories, a business-logic guardrail is written against your actual policy:

$ zespan policy test --against last:7d

refund_over_policy_limit     caught 47    wrongly blocked 2
personal_data_in_reply       caught 118   wrongly blocked 0
medical_advice_boundary      caught 6     wrongly blocked 31

refund_over_policy_limit isn't a category any general-purpose safety tool ships with, because it's specific to one company's refund ceiling. It has to be authored against the actual rule, and — because a rule written in isolation can block more legitimate requests than it catches — tested against real traffic before it's trusted to run. That process is covered in how to test a guardrail before deploying it.

Note that personal_data_in_reply sits in the same list: a genuinely security-shaped rule (don't leak PII) alongside a business-logic rule (don't approve an over-limit refund) and a policy-boundary rule (don't give medical advice). In production, these aren't separate systems maintained by different teams with different tools; they're all rules against a response, evaluated the same way, on the same request path.

Running both without adding a second system

The practical version of this isn't "replace your security guardrails." It's running business-logic guardrails on the same enforcement path, so a request gets checked against both without a second integration, a second proxy hop, or a second place for policies to drift out of sync. Zespan's guardrails compile every rule, security-shaped or business-logic, into one bundle the SDK evaluates in-process, with no added latency (see why guardrails need to run without added latency for why that matters especially for real-time agents). Rules live as code in your own repository, move from dry run to warn to block, and only start blocking once they've been tested against real traffic.

The takeaway

"AI guardrails" isn't one category. Security guardrails catch adversarial and unsafe content; they're necessary and they're not sufficient for an agent that takes real actions on your behalf. The failure mode with real financial and reputational cost is usually the second kind: an agent confidently, safely, and incorrectly making a decision it had no business making. If your guardrail strategy stops at prompt injection and PII, that's the half of the problem that doesn't show up in your incident reports until a customer, a regulator, or a chargeback tells you about it.