Lakera Guard, protecting LLMs from prompt injection

Lakera Guard, protecting LLMs from prompt injection

Lakera Guard is an external API you pass text through before sending it to a language model and after receiving the answer. It reports whether the content looks like an attempt at instruction injection, an escape from constraints, a leak of personal data, or material breaching content rules.

The problem it addresses is built into how language models work: your instruction and the user's text arrive through the same channel. The model has no architectural way to tell them apart, so a suitably phrased sentence in the input can override your system prompt.

A change of name and owner

Before you go hunting for documentation, accept that the names have diverged, and that is a source of real confusion.

Lakera was acquired by Check Point. The deal was announced in September 2025 and closed in October of the same year, at a figure reported publicly around three hundred million dollars.

The product is now called Check Point AI Guardrails. Documentation still sits under the Lakera domain, the API endpoint stayed the same, so code written earlier keeps working. What changed is what you see in sales material and in the console, and above all how it is sold: the product moved into enterprise procurement, with a sales conversation replacing self serve signup.

For a small team that matters practically. A tool that once slotted in over an afternoon now, at meaningful volume, requires going through the purchasing process of an enterprise security vendor. For experiments and a prototype, a key from the free tier still suffices.

How it works in practice

The operating model is deliberately simple, and that is its greatest strength.

Guard sits beside your application rather than inside it. You send a request with the content, you get a verdict back, you decide what happens next. It changes neither your model, nor your provider, nor your prompt structure, so wiring it in and pulling it out is a matter of one conditional in code.

That carries a consequence to accept: every checked fragment is an extra network call. The vendor quotes latency below fifty milliseconds, though that is a declared figure measured on the service side, so your own arithmetic should add the round trip from your region.

The address itself routes to whichever region sits closest to the sender, and where processing location matters you can name a specific one by subdomain: Ireland, Singapore, or one of the United States regions. Log storage location and the list of regions allowed to process requests are configured separately, so neither forces the other.

Checking input and output separately gives two calls per user interaction. Streaming responses makes it harder, since you either withhold everything until generation finishes, or check in fragments and risk retracting text already on screen.

The first call

export LAKERA_GUARD_API_KEY=...

import os
import requests

session = requests.Session()

def screen(content: str) -> bool:
    response = session.post(
        "https://api.lakera.ai/v2/guard",
        json={
            "messages": [{"content": content, "role": "user"}],
            "project_id": "project-XXXXXXXXXXX",
        },
        headers={"Authorization": f"Bearer {os.environ['LAKERA_GUARD_API_KEY']}"},
        timeout=3,
    )
    response.raise_for_status()
    return response.json()["flagged"]

if screen(user_prompt):
    raise ValueError("Request rejected by the filter")

The flagged field is a single boolean and suffices to start. The response also carries a breakdown of individual detections, and reaching for that straight away pays off, since it separates situations calling for entirely different reactions: an injection attempt is a different matter from a card number a user pasted by accident.

Note the timeout on the call. Without it, an outage at the external service turns into a hung application, and for a security filter that is the worst possible outcome, since it blocks traffic that never needed blocking.

Five families of defence

The service splits threats into five families, and the differences matter, since each calls for a different reaction.

Prompt attacks cover instruction injections, attempts to escape constraints, and manipulation of system content. This is the core use and the most common reason to reach for the tool.

Data leakage covers personal data and other sensitive information. This category works both directions: guarding against sending something to the model and against showing something to the user.

Content violation means offensive, hateful, sexual, or violent material. That sits closer to classic moderation than to security.

Unknown links means detecting addresses outside an allowed domain list. The least obvious category, and with agents the one that can save the day, since exfiltrating data through a link in an answer is a real attack route.

The fifth family, added last, covers agent behaviour. It consists of off task action detection, meaning tool calls that do not match what the user asked for, plus an allow and deny list of tools enforced at call time. That layer watches not the content but what the agent actually does, so it catches the consequences of an injection that slipped past the earlier filters. The endpoint also screens tool descriptions and tool responses, since both routes push foreign text into the model's context.

Policies, projects, and tuning

Configuration rests on two concepts worth understanding before anything runs in production.

A project is your application or a slice of it. You pass the project identifier on every call, and it decides which policy applies.

A policy states which mechanisms are on and how sensitive they are. The vendor ships a ready set for publicly exposed applications, and that is a reasonable starting point, though rarely a destination.

The reason is always the same: sensitivity is a trade off, and the right setting depends on what your users actually write. An application for developers receives code fragments, vulnerability descriptions, and content that at high sensitivity reads as an attack. An application for bank customers almost never receives that, so it can afford stricter settings.

The practical route looks like this. Run the filter in observation mode, recording verdicts while blocking nothing. Collect a few thousand real requests. Review the detections and count how many are false alarms. Only then switch blocking on, starting with the categories carrying the lowest error rate.

Separate projects for staging and production save a lot of trouble, since they let you change sensitivity without a change reaching users immediately.

Where to wire it into an application

Placement decides effectiveness more than the settings do.

User input is the obvious spot and usually the first. You check the text before it reaches the prompt.

Model output matters equally and often gets skipped. A model that accepted an injected instruction reveals it in the answer, and there it can still be stopped.

The third spot is the most forgotten and, with agents, the most dangerous: content fetched from outside. A web page, a document, a search result, or a tool response enters the model's context exactly like user text. An instruction hidden in a fetched page works exactly like one typed into a chat box, and nobody typed it deliberately.

def ask_model(prompt: str, fetched_context: str) -> str:
    if screen(prompt) or screen(fetched_context):
        return "I cannot process this request."

    answer = call_model(prompt, fetched_context)

    if screen(answer):
        return "The answer was withheld by the filter."

    return answer

That arrangement gives three calls per interaction, and it is a real cost to remember when budgeting money and latency. At heavy traffic it pays to check fetched content once and cache the verdict, since the same page returns across many requests.

What to do with a detection

The signal alone is half the work. How you respond to a detection is a product decision rather than a technical one, and it deserves settling before deployment rather than during an incident.

Hard rejection is the simplest and the most common. The user gets a message, the request goes no further. It suits clear attacks, while on a false alarm it looks like a broken application and gets reported as one.

Soft rejection means letting the request through with limits: no tool access, no database data, a general answer only. The user gets something rather than a wall, and you contain the damage. That makes a good default for categories carrying a higher false alarm rate.

Flagging for review without blocking fits where the cost of stopping a genuine user is high and the consequence of letting an attack through is contained. You record the event and somebody reviews it later.

Treat separately the case where the filter fired on model output. A detection there means something already went wrong earlier, so beyond withholding the answer it pays to record the whole context: the system prompt, data fetched from outside, and the full response. Without that you cannot reconstruct the sequence or work out where the instruction entered.

The last point concerns messages. Telling a user which rule they broke and exactly how makes the defence easier to work around, since it turns the filter into an experimentation tool. A generic message plus an event identifier in the log gives support everything it needs and gives an attacker nothing.

Lakera Guard against the alternatives

Choosing between the first row and the rest comes down to one question: do you want to maintain your own detection layer. An external service updates itself, and that is its main value, since injection techniques shift every few months and a pattern list written once ages faster than most code.

The price is dependence on a vendor, a cost per call, and the fact that in the cloud variant prompt content passes through somebody else's server. That last point is sometimes decisive, yet it can be removed without changing tools: the same product deploys as a container inside your own infrastructure. That costs an enterprise licence, so on a small budget an open solution remains.

The last row deserves honest consideration before you buy anything. Moderation built into a model provider's API catches offensive content, usually at no extra charge, while detecting no injections at all, since that is not what it is for.

Pricing, limits, and what to do about them

Pricing is not published, and after the move under Check Point the product sells through enterprise channels, so a concrete figure comes from a sales conversation and depends on volume.

A free account exists for experiments, enough to judge detection quality against your own data, and starting there is sensible whatever your later plans. A few hundred real requests pushed through the filter will tell you more than any accuracy comparison, since your data rarely resembles a benchmark set.

Self hosting is a separate line item. A container run under Docker or in Kubernetes from a Helm chart, an entirely offline variant included, requires an enterprise licence and registry credentials, so you cannot switch it on yourself from a free account. In exchange the content never leaves your network, and the endpoint in that build uses no authorisation at all, because there is no API key to speak of.

Treat the figures the vendor quotes, detection above ninety eight percent, latency below fifty milliseconds, and false alarms below half a percent, as a claim rather than a measurement in your environment. Verifying them takes an afternoon and is the only credible basis for a decision.

When costing it out, remember the multiplier. An interaction with three checks is three calls rather than one, and in an application where an agent takes several steps that number grows faster than the conversation count suggests.

Common mistakes

The first is checking user input alone. A model that accepted an instruction from a fetched document reveals it in the answer, and nobody is checking that.

The second is no timeout and no failure handling. An external service will eventually answer slowly or not at all, and then you must decide deliberately whether traffic passes or gets blocked. Both answers are sometimes right; a hung application is neither.

The third is switching blocking on from day one with no observation period. False alarms then hit real users, and you learn about it from support tickets.

The fourth is treating the filter as the only safeguard. No filter catches everything, so an agent able to delete data or move money needs separate permission limits, independent of whatever the model received in its prompt.

The fifth is sending content to an external service that must not leave. A security filter that itself exports data outside your infrastructure solves one problem and creates another. For restricted data you have two ways out inside the same product: confine processing to a chosen region, or stand the container up yourself.

The sixth is not logging detections. Without logs you do not know whether the filter works, how much it blocks, or whether it blocks the right things, so you have no basis for changing settings.

FAQ

Is Lakera Guard still Lakera?

Formally the product is now called Check Point AI Guardrails, following an acquisition announced in September 2025 and closed in October. Documentation and the API endpoint stayed under the former domain, so existing code runs unchanged.

What does it cost?

Pricing is not public, and post acquisition sales run through enterprise channels, so you learn the figure in a sales conversation. For experiments and judging detection quality, the free tier suffices.

Will the filter stop every injection?

No. It is a statistical system and some attempts get through, particularly new ones or ones tailored to a specific defence. Treat it as one layer rather than a guarantee, and separately restrict what the model is permitted to execute.

Can it run locally?

Yes. Alongside the cloud version there is a deployment inside your own infrastructure: a container under Docker or in Kubernetes from a Helm chart, an offline variant included. It requires an enterprise licence, so it is no route to an afternoon test, but the content then never leaves your network. If you want something free, reach for Guardrails AI, or Presidio for personal data alone.

How do I set sensitivity without blocking ordinary users?

Run the filter in observation mode, collect a few thousand real requests, count false alarms per category, and only then switch blocking on, starting with the lowest error category. A setting chosen without that data will be either too loose or a nuisance.

API documentation sits on the endpoint reference page, and the acquisition details in the Check Point announcement.