Skip to main content
SecureAI Guard

Build vs buy: writing your own LLM guardrails

What a homegrown LLM guardrail layer really costs to build and keep working, which parts are genuinely easy, and the three that quietly are not.

Published ·6 min read·SecureAI Guard
build vs buy
LLM guardrails
prompt injection
evaluation

For most platform teams the real alternative to buying an LLM security product is not another vendor. It is a few hundred lines of your own code: a regular expression or two, a call to a free moderation endpoint, a deny-list of phrases, and a log line. That layer is cheap to build, it works on day one, and it is a completely reasonable place to start. This page is about which parts of it stay cheap and which parts do not, so the decision is made against the real cost rather than the first week's.

We sell one of the things being compared here, so treat the framing as interested. The claims below are about the general shape of the problem and are sourced to published work where they can be; where the honest answer is "it depends on your traffic", we say that instead of a number.

What you are actually building

A guardrail layer is not one control. It is at least six, and they have very different difficulty curves:

  1. Input inspection — look at the outbound request for attack patterns.
  2. Output inspection — look at the completion for evidence the attack worked.
  3. Sensitive-data handling — detect personal or secret data and redact, tokenise or block it.
  4. Retrieval authorisation — make sure a RAG answer cannot quote a document the asking user cannot open.
  5. Tool and agent constraint — bound what a model-driven action can reach.
  6. Evidence — a durable, queryable record of what was inspected, what fired and what was done, in a form an auditor accepts.

The first two look like the whole problem and are the smallest part of it.

The parts that are genuinely easy to build

Structural checks. Maximum prompt length, request-rate limits per user and per key, an allow-list of model identifiers, a hard stop on requests that arrive without an authenticated principal. These are ordinary application controls, they are deterministic, they never drift, and they close a real slice of OWASP LLM10:2025 Unbounded Consumption and LLM03:2025 Supply Chain from the 2025 OWASP Top 10 for LLM Applications. Build these. No product should be sold to you for them.

Content moderation for harm categories. If what you need is "do not let this assistant produce sexual, violent or self-harm content", that is a solved, commodity problem with a free API in front of it. OpenAI's moderation endpoint classifies text and images across categories including harassment, hate, illicit, self-harm, sexual and violence, and its documentation states it is free to use. Note what it is not: OpenAI's moderation documentation does not address prompt injection at all. Harm classification and injection detection are different problems and it is worth being precise about which one you have.

Regex redaction of well-formed identifiers. Card numbers with a Luhn check, IBANs, national insurance numbers, AWS key prefixes, JWTs. Structured identifiers with checksums are exactly what regular expressions are good at, and a couple of hours of work here removes a genuine class of exposure.

The three parts that do not stay cheap

1. Indirect prompt injection

The payload in a real attack is rarely in the user's message. It is in the wiki page, the support ticket, the PDF, the calendar invite or the API response your retrieval step pulled in on the user's behalf — so a filter that only inspects user_input inspects the one part of the context the attacker did not write.

Microsoft's own documentation makes the distinction structural rather than incidental: Azure AI Content Safety ships Prompt Shields as two separate detectors, one for User Prompt attacks and one for Document attacks, and enumerates document-attack subtypes including manipulated content, information gathering, availability, fraud and malware. If a major cloud provider needed a second model for the indirect case, a deny-list in your middleware will not cover it either.

Building this yourself means assembling the full context — system prompt, retrieved chunks, conversation history, tool definitions, current turn — at the point of inspection, and keeping a detector current against attack techniques that are published weekly. That is not a sprint. It is a standing commitment.

2. The false-positive budget

A detector's accuracy on someone else's benchmark tells you almost nothing about its behaviour on your traffic, and the failure mode is asymmetric. A missed attack is an incident; a false positive is a support ticket from a paying customer whose legitimate prompt was blocked — and after enough of those, the control is switched off, usually during an incident, usually by whoever is on call. Every guardrail that has ever been disabled was disabled for its false positives, not for its misses.

The engineering cost is not the classifier. It is the permanent apparatus around it: a report-only mode you can run in production, a labelled sample of your own traffic, a review queue, threshold management per route, and someone whose job includes looking at it. Teams routinely budget for the classifier and not for this.

3. Evidence an assessor accepts

The frameworks ask you to show which models were in use, what they were allowed to do, what data reached them, and what happened when a control fired. The NIST AI Risk Management Framework (NIST AI 100-1) and its Generative AI Profile (NIST AI 600-1, July 2024) are structured around exactly that kind of record, and almost none of it is recoverable after the fact unless something was recording it at the time.

A log line is not evidence. Evidence is a record that survives a retention policy, is queryable by control rather than by timestamp, redacts the prompt content it is describing, and can be exported per control so it can be attached to an ISO/IEC 42001:2023 Statement of Applicability. Retrofitting that onto logger.info(...) calls a year later is one of the more expensive things a platform team can be asked to do.

The honest decision framework

Build it if your risk is mainly harm-category moderation, your context is short and entirely user-authored, you have no regulated data in prompts, and no external assessor is going to ask you for evidence. That describes a lot of internal tools, and for those a bought product is overhead.

Buy it — from us or from anyone — if any of the following are true:

  • Your application retrieves documents your users did not write. That is the indirect-injection case, and it is where DIY layers fail first.
  • Your prompts can contain personal or regulated data and you are answerable for where it goes.
  • An agent in your system can take an action that is irreversible or outbound — sending, paying, deleting, publishing, granting access.
  • Someone external will ask you to evidence your controls within twelve months.
  • You cannot name the person who will own detector tuning eighteen months from now.

That last one decides more of these than the technical arguments do. A guardrail is not a project with an end date; it is a component that decays if nobody is maintaining it against new techniques.

What to do before you decide either way

Instrument first. Log the full assembled context, the model called, the tools offered and whether each request would have been flagged, in report-only mode, for one representative week. You will learn three things that change the decision: how much of your context is not user-authored, how much regulated data is already in your prompts, and what your real false-positive rate would be. Do that before you write a detector and before you sign anything — including with us.

The method for turning that week of traffic into a number you can defend is written up separately in how to benchmark an LLM guardrail on your own traffic.