F5 AI Guardrails quickstart: Answering the hard questions

A financial services firm is deploying an AI assistant to help underwriters review policies, analyze risk documents, and answer compliance questions. The model is grounded in the firm’s own document collection, drawing answers directly from underwriting manuals, regulatory filings, and internal procedures. The business case is solid.

Then the security review starts:

• Can a crafted prompt trick the model into ignoring its system instructions and exposing confidential data?
• What happens when a response surfaces personally identifiable information (PII) that's embedded in the retrieved documents?
• Is anything stopping the AI assistant from answering questions that, in a regulated industry, it has no business touching?

These are questions that stall production deployments. A traditional security stack can’t protect against these, because it doesn’t live at the network layer. A web application firewall inspects packets, but can’t tell you whether a user’s message is an instruction-override attempt. There's nothing to tell you that a model response contains a Social Security number, or whether your AI just gave unsolicited investment advice in a jurisdiction that prohibits it.

Those are the gaps this AI quickstart can help you close.

What this AI quickstart delivers

The F5 AI Guardrails quickstart is a complete, working application. It deploys a retrieval-augmented generation (RAG)-powered chat assistant backed by a vector database, a document retrieval layer, and a model inference endpoint with F5 AI Guardrails (powered by Calypso AI) running inline as the inspection layer. The integration is tested, the components are validated against each other, and the whole stack deploys on Red Hat OpenShift AI.

That last part matters more than it might seem. Enterprises need a working demonstration they can put in front of security architects, compliance officers, and risk stakeholders. This AI quickstart shows exactly how each protection layer responds to a real attack.

You can run simulated attack scenarios against the live system to address each question from the aforementioned security review. Each scenario shows the guardrail firing (or not, if you haven’t enabled it yet) and the logs surface exactly which policy triggered and why.

The inspection layer is the novel part

F5 brings an inline, model-agnostic inspection layer that treats AI threats the way enterprise security has always treated network threats, with enforceable, auditable policy.

Inbound, guardrails inspect prompts before the model ever sees them. They catch instruction injection, jailbreak attempts, and requests for sensitive data. Outbound, they inspect responses before users see them and help catch PII in model outputs, toxic content, and answers that stray outside the application’s approved domain.

The out-of-the-box packages cover the threat categories that come up in every enterprise security review, including prompt injection, PII detection, toxicity filtering, and restricted topic enforcement. For organizations operating in regulated markets, there’s also a pre-built EU AI Act compliance package. This isn’t a policy checklist, but an active enforcement layer that can block or flag interactions that violate the Act’s specific prohibitions.

Each guardrail runs in one of 3 modes:

• Block: Stops the interaction
• Audit: Allows it but flags it for review
• Redact: Masks sensitive data and lets the conversation continue

This enforcement gradient matters during rollout. You don’t have to choose between "fully locked down" and "unprotected" on day 1.

Answering the auditor

How do you know your AI is safe?

Until recently, the honest answer was some version of "we trust the model provider’s safety settings." This is not an answer that satisfies an auditor or a regulator.

F5 AI Guardrails provides the audit trail. Every interaction is logged. Every policy that fires is recorded. Every blocked prompt is traceable to the specific rule that caught it. For the security architect building the business case, and for the compliance team that has to sign off on production deployment, that observability is what makes the conversation possible.

The Red Team component goes further. It’s F5’s adversarial testing model running in-cluster, continuously probing the application for new vulnerabilities. The findings feed back into the guardrail configuration. That closed loop is what separates a security posture you can defend from one you have to caveat.

The right starting point

This AI quickstart targets financial services because the threat model is sharp and the regulatory stakes are high, but the architecture is industry-agnostic. The same stack applies to healthcare organizations protecting patient data, government agencies running citizen-facing AI services, or any enterprise that needs to demonstrate enforceable content policy before moving an AI model to production.

If your team is past the prototype stage and is exploring what production-ready AI protections look like on Red Hat OpenShift, explore the F5 AI Guardrails quickstart to learn more.