Guardrails for LLMs in banking: essential measures for secure AI use

Guardrails for LLMs in banking are the controls around a model or agent that decide what it may read, say and do. They screen input for personal data and prompt injection, restrict retrieval to what each user may see, check outputs against policy, require a person's approval before risky actions, and record every step for audit. Banks need all of these layers, because a filter on the model's answer does nothing to stop an agent from taking a wrong action.

This guide explains the risks guardrails address, the types of guardrails and where each one sits, and how to put them in place in a regulated bank.

Why do banks need guardrails for LLMs?

A bank's LLM application touches customer data, makes statements customers may rely on, and increasingly acts in core systems. Each of those creates a specific risk:

Data exposure. Account numbers, card data and personal details can leak into prompts sent to external models, into logs, or into answers shown to the wrong person.
Wrong answers that bind you. A confident but incorrect statement about a fee, rate or policy is a conduct risk.
Prompt injection. Attackers hide instructions in messages, emails or documents that an agent reads, trying to override its rules.
Excessive agency. An agent with broad tool access can move money, change records or send messages nobody approved.
Unfair outcomes. Credit and pricing decisions influenced by a model must not discriminate, and adverse decisions need specific reasons.
Regulatory exposure. Supervisors expect traceability, human oversight and documented controls for any model that affects customers.

These risks map closely to the industry's reference list, the OWASP Top 10 for LLM applications, which ranks prompt injection, sensitive information disclosure and excessive agency among the most serious.

What happens without guardrails?

Courts and tribunals already treat a chatbot's words as the company's words. In Moffatt v. Air Canada, a Canadian tribunal ruled in 2024 that the airline was responsible for its website chatbot's incorrect explanation of its bereavement fare policy, and ordered it to compensate the customer. The airline argued the chatbot was responsible for its own statements; the tribunal rejected that.

For a bank, the equivalent is an assistant that misstates an overdraft fee, promises a rate or gives what sounds like investment advice. Other public incidents, such as support bots coaxed into swearing at customers or into "agreeing" to absurd deals, show how quickly a missing guardrail becomes a reputational problem.

What are the types of LLM guardrails?

Guardrails sit at five points in the path from a user's request to an agent's action:

Layer	What it checks	Banking example
Input	PII, prompt injection, off-topic or abusive requests	A customer pastes a full card number into chat, and the message is routed to a secure flow
Retrieval	Which documents and records the agent may read	A branch employee's assistant cannot retrieve private banking files
Output	Grounding, format, policy and tone	An answer about fees must cite the current fee schedule
Action	Which tools the agent may call, and with what approval	A payment reversal waits for an operations manager to approve the exact amount
Monitoring	Every step, verdict and cost, after the fact	Compliance reviews a flagged conversation step by step

Input and output checks are what most people mean by guardrails. For agents, the action layer matters most, because it is where a mistake stops being words and becomes a transaction.

Which guardrails matter most for banks?

Sensitive data detection. Detect account numbers, card numbers, national IDs and other personal data before text reaches an external model or a log, and route flagged messages deliberately.
Prompt injection detection. Screen user messages and, just as important, the documents and emails an agent reads during KYC, onboarding or complaints handling.
Grounded answers. Answer only from approved sources, such as current product terms and policies, and cite them.
No unsolicited advice or commitments. Check outputs for investment advice, rate promises or statements outside the approved script, and hand those conversations to a person.
Least-privilege tools. Give each agent only the tools and data its task needs, with read-only access by default.
Human approval on consequential steps. Payments, account changes, filings and customer letters wait for sign-off, and the reviewer can edit the exact fields before approving.
AI disclosure. Under the EU AI Act, since 2 August 2026 chatbots must tell people they are talking to an AI system, not a human.
Audit trail. Keep a replayable record of what the agent read, which checks it passed, what it did and who approved it.

How do you implement guardrails in a bank?

Classify each use case by risk. Separate internal assistants from customer-facing agents, and assistive tasks from ones that influence decisions such as credit.
Write policies as testable rules. "Never quote a rate that is not in the rate sheet" can be tested; "be careful with rates" cannot.
Place detectors before the model. Screen for PII and prompt injection on every input, including retrieved documents where the risk is high.
Constrain tools and add approvals. Limit tool permissions, set thresholds, and require sign-off where an action is hard to reverse.
Validate outputs. Check structure, allowed values and required citations before anything reaches a customer or another system.
Test before release. Build evaluation sets from real cases and red-team prompts, and run them on every change to prompts, models or tools.
Monitor live traffic. Trace every run, score a sample continuously and alert on failures and unusual cost.
Review and improve. Treat guardrail misses as incidents, add the failing case to the test set and fix the rule.

How do guardrails fit bank regulation?

Guardrails are how a bank shows regulators that its AI controls exist and work:

Model risk management. Validation, monitoring and documentation apply to LLM-based systems. In the US, the interagency guidance was revised in April 2026 (SR 26-2), replacing SR 11-7.
EU AI Act. Transparency duties, including chatbot disclosure, apply from 2 August 2026. Systems that assess the creditworthiness of individuals are high-risk, and after the 2026 AI Omnibus amendment their obligations, including human oversight and logging, apply from 2 December 2027.
Data protection. GDPR and similar laws require data minimization and a lawful basis for processing, which input screening and self-hosting help demonstrate. See our post on LLMs under GDPR.
Operational resilience. In the EU, DORA requires banks to manage risk from ICT providers, which includes AI platforms and model APIs.

How does Dynamiq implement guardrails?

In Dynamiq, guardrails are workflow nodes. A PII detector, a prompt injection detector and a policy detector screen text before an agent sees it, and each returns a verdict you branch on, sending clean messages to the agent and flagged ones to a refusal, a secure flow or a person. Detectors flag what they find; they do not rewrite the message, so the decision stays with you.

Validators check outputs, including valid JSON, allowed choices and regex patterns. Approvals pause a tool call, or an agent's plan, until a reviewer signs off, and the reviewer can edit fields such as the amount or the body of a letter before approving. A rejection flows back to the agent as feedback it can act on.

Every verdict and approval is recorded in the run's trace. The platform can be self-hosted in the bank's own cloud account or data center, with fully isolated setups delivered with our engineers, and Dynamiq has SOC 2, HIPAA and GDPR in place.

FAQ

What are LLM guardrails?

LLM guardrails are controls that limit what a language model or agent can read, say and do. They include input screening, retrieval permissions, output validation, limits and approvals on actions, and monitoring of every run.

What is the difference between input and output guardrails?

Input guardrails check what goes into the model, such as personal data, prompt injection or off-topic requests. Output guardrails check what comes out, such as unsupported claims, wrong formats or statements that break policy. Agents also need action guardrails, which control the tools a model can call.

Can guardrails stop prompt injection completely?

No single check can. Combine an injection detector with least-privilege tools, approvals on consequential actions and monitoring, so that a successful injection still cannot do real damage.

What should happen when a guardrail detects personal data?

Route the message deliberately: to a secure flow, to a model hosted inside your environment, or to a person. Record the verdict in the trace so the decision can be reviewed later.

Are banks required to use AI guardrails?

Regulations rarely use the word, but they require what guardrails provide: data protection, human oversight, logging and documented controls. The EU AI Act, model risk management guidance and data protection law all expect banks to show these controls in practice.