## Building a Layered Safety Architecture for a Financial Assistant with NeMo Guardrails
This article outlines how to design and implement a robust, multi‑layer safety pipeline for an LLM‑powered financial assistant. Using NeMo Guardrails, we combine deterministic pre‑filters, model‑based checks, retrieval controls, and policy‑gated actions to manage risk across the entire request lifecycle. The result is an auditable, production‑oriented system that balances security with usability.
### A Multi‑Layer Approach to Safe Financial Conversations
Financial assistants must handle sensitive data and high‑stakes requests. A single control mechanism is insufficient. Instead, effective safety requires overlapping defenses that act at different stages of processing:
– Deterministic pre‑filters that block or redact harmful input before it reaches the model.
– Model‑level self‑checks that prevent jailbreaking, policy violations, and unsafe advice.
– Retrieval filtering that ensures internal knowledge sources do not leak confidential information.
– Output rewriting that masks account numbers and other sensitive artifacts.
– Explicit policy gates for actions such as money transfers, which must be validated before execution.
These layers work together to reduce risk while still allowing legitimate financial tasks to proceed.
### Implementing the Guardrails with NeMo Guardrails
We start by defining clear instructions and layered rules in a YAML configuration. The assistant’s role is scoped to personal finance questions, and strict boundaries are set around politics, investment advice, and unauthorized account access.
“`yaml
instructions:
– type: general
content: |
You are FinBot, the support assistant for a personal finance app.
Answer only from the provided context when context is available.
Be concise. Never invent balances, fees or account numbers.
rails:
input:
flows:
– redact pii input
– self check input
retrieval:
flows:
– filter internal chunks
output:
flows:
– mask account numbers
– self check output
“`
This configuration is paired with Python actions that implement concrete behavior. Deterministic regex checks block hard PII such as full card numbers and SSNs. Other actions perform soft redaction, retrieval filtering, output masking, balance retrieval, and policy evaluation for transfers.
### Key Action Implementations
– **PII Detection and Redaction:** Hard PII stops the flow immediately, while account-like numbers are masked to allow continuation.
– **Retrieval Filtering:** Internal knowledge chunks are stripped before prompting the model, preventing accidental leakage.
– **Policy‑Based Transfer Control:** Transfers are only allowed if the amount is valid and within a daily limit. Context updates communicate the decision without exposing raw logic.
– **Knowledge Retrieval:** A lightweight keyword matcher replaces a vector store for demonstration, highlighting how retrieval can be controlled and audited.
These actions are registered with the guardrails runtime and organized into named flows that align with the YAML specification.
### Multi‑Turn Conversations and Runtime Observability
Stateful conversations are handled by preserving message history across turns. Each turn re‑evaluates all relevant rails, ensuring that safety controls remain active throughout the interaction.
To support auditing and cost analysis, we log activated rails, execution duration, and token usage. This data enables us to:
– Trace which control handled each request.
– Measure the computational overhead of each safety layer.
– Identify edge cases where dialog rails redirect rather than halt execution.
### Coverage Testing and Results
We evaluate the system with a targeted probe set covering:
– Jailbreak attempts
– PII exposure
– Unauthorized transfers
– Political topics
– Investment advice
– Knowledge‑base retrieval
By comparing expected handlers against actual rail activation, we can measure coverage, detect failures, and quantify token overhead. Results show high coverage for safety‑critical cases, with clear visibility into where and how each request is controlled.
### Frequently Asked Questions
**What kinds of inputs are blocked by hard PII checks?**
Hard PII checks stop any request containing full credit card numbers or Social Security numbers. These inputs are discarded before the model sees them.
**How are account numbers handled in outputs?**
Account numbers are not blocked outright. Instead, a post‑generation action masks them, replacing most digits with asterisks while preserving the last four for reference.
**Can the assistant still answer balance and transfer questions safely?**
Yes. Balance lookup is allowed, and transfers are permitted only when the amount is readable, positive, and within the configured daily limit. Exceeding transfers are blocked with a clear explanation.
**What happens during multi‑turn conversations?**
History is preserved across turns, and every turn re‑evaluates input rails, retrieval, and output checks. This ensures that safety controls stay active even as the conversation evolves.
**How are policy violations detected?**
Self‑check prompts explicitly test for jailbreak attempts, role‑play requests, abusive language, and unauthorized access patterns. These are evaluated independently of the main task flow.
### Conclusion
This pipeline demonstrates how NeMo Guardrails enables a structured, auditable approach to LLM safety in financial applications. By combining deterministic pre‑filters, model‑based checks, retrieval control, and policy‑gated actions, we create a system that is both secure and functional. Multi‑turn tracing, token accounting, and coverage reporting provide ongoing insight into effectiveness and operational cost. For production deployments, this architecture offers a scalable foundation for responsible, compliant AI assistant design.
Thank you for reading
