Agent guardrails are runtime checks that sit between an AI agent and your customer, deciding what the agent may say, which actions it may take on its own, and which cases go to a person instead. They run on every turn, independently of the model, and they record what they catch.

A guardrail is not an instruction in a prompt. A prompt asks the model to behave a certain way and the model usually complies. A guardrail inspects what the model actually produced, then intervenes before the customer sees it. That difference is what makes a guardrail something you can evidence to a regulator.

The two types of AI agent guardrails

Most people think of guardrails as simply hallucination prevention: checks that stop an agent inventing a refund policy or quoting a rate that does not exist. However, preventing hallucinations is only the baseline function of a guardrail; it has many other functions which matter especially in a regulated industry. In financial services, guardrails run in both directions:

Customer guardrails inspect what the customer says, on every turn. They detect complaints, vulnerability, financial difficulty, and coercion, then hand the conversation to a person or route it into a dedicated procedure. These exist because of Consumer Duty obligations, not because of anything the model might get wrong.

Agent guardrails inspect the reply the agent has drafted, before it is sent. They catch financial promises, out-of-bounds advice, unverified account identifiers, disallowed terminology, and prompt injection. Where the problem is fixable the draft is rewritten, and where it is not the case goes to a human.

At Gradient Labs, more than 20 pre-built financial services guardrails run on every turn. At one large European digital bank they have run 9 million times, on conversations scored at 98% QA against that bank's 95% human benchmark.

What agent guardrails prevent

Guardrails catch four kinds of failure, and only one of them involves the model making something up. An agent can state something untrue, state something true that it was never permitted to say, give advice it is not licensed to give, or act on an instruction planted by the customer rather than set by your policy.

If an agent gets anything above wrong, it can carry heavy consequences. One clear example is tipping off. A customer asks why their account is frozen, and the agent answers accurately: checks are underway for suspicious activity. Every word is grounded in the help centre, and the same sentence sits on the public support site without issue. Repeated inside a live conversation, though, it is a breach of section 333A of the Proceeds of Crime Act 2002.

Grounding the agent in your knowledge base would not have caught this, because the agent was already grounded. Only a check that knows the rule catches it. This is why knowledge-base scoping, which several vendors sell as a guardrail, is a quality control rather than a genuine safety measure.

Guardrails for agents that take actions

An agent that answers questions fails one conversation at a time. An agent that issues refunds, submits chargebacks, or updates accounts can repeat the same error across a queue before anyone reviews it. That widens what a guardrail has to cover:

• Message checks: grounding, tone, required disclosures, prohibited terms, and hallucinated account or payment identifiers
  
  

• Action limits: which tools the agent can call, and under what conditions
  
  

• Approval gates: decisions the agent prepares for a person to sign off, rather than completing alone
  
  

• Escalation triggers: conditions that always route to a human, including vulnerability and complaints
  
  

• Audit trail: every action, data point referenced, tool executed, and reason recorded against the case
  
  

The distinction that matters here is reversibility. A wrong sentence can be corrected in the next message; a wrong payment cannot.

How AI guardrails map to financial regulation

The word "guardrails" doesn't appear in the FCA AI Update, PRA SS1/23, PRA SS2/21, PRIN 2A, and FG22/5, and only once in the EU AI Act, in a recital that carries no obligation. The Bank of England and FCA 2022 machine learning report has a section headed "Safeguards" where a vendor would have written guardrails.

If you are writing a control narrative, the translation is:

The obligation does not change as vocabulary evolves. FCA guidance states that firms using AI remain responsible for ensuring compliance with its rules, and SS1/23 expects firms to satisfy themselves that vendor models have been validated to the same standards they apply internally.

How to evaluate AI agent guardrails

Guardrails carry a cost that is easy to miss. Set too tightly, they push volume back to your team and the automation stops paying for itself. Set too loosely, they fail as a safety measure.

Consumer Duty reframes that trade-off. PRIN 2A.6.2R requires firms to design support that includes "appropriate friction" in customer journeys to mitigate the risk of harm, so a guardrail that routes a vulnerable customer to a person is the rule working as intended.

Four questions worth asking any vendor:

• Who can change a guardrail, and how quickly? If it takes an engineer, every policy change joins a release queue
  
  

• Can a change be tested before it reaches customers?
  
  

• How often does each guardrail fire, and how often is it wrong? Almost no vendor publishes a false-positive rate
  
  

• Do the checks run on every turn? Some frameworks run input checks only on the first agent and output checks only on the last, leaving the tool calls in between unchecked
  
  

Frequently asked questions

Are AI agent guardrails the same as evals?

No. Guardrails run inline, during the conversation, and intervene before the customer sees anything. Evals run offline, after the fact, and measure how well the agent performed. Guardrails ask whether the agent was permitted to say or do something, and evals ask whether it did the job well. Production systems need both.

What happens when a guardrail fires at Gradient Labs?

One of two things. Where the problem is fixable, the draft reply is rewritten and sent. Where it is not, the conversation hands off to a human or routes into a dedicated procedure for complaints or financial difficulty. A rewrite is the default path rather than a guarantee: if the rewrite fails, the case still hands off.

Can we use our own guardrails instead of Gradient Labs’?

Yes. Gradient Labs supports running your own guardrails alongside or in place of the existing ones. Some customers run both sets, so every draft passes two layers of checks. Others disable specific Gradient Labs checks and route drafts through their own policy engine, keeping decisions about what the agent may say inside their own compliance function.

Who is accountable when an AI agent gets something wrong?

The firm. FCA guidance states that firms using AI remain responsible for ensuring compliance with its rules, and PRA SS2/21 is explicit that outsourcing does not reduce regulatory responsibility. A vendor's guardrails do not transfer accountability, which is why the ability to inspect, change, and evidence them matters more than the number of checks on the list.