Choosing a safeguard for an AI agent is less about finding the biggest or highest-scoring model and more about understanding what the agent actually needs to be protected against.

The right AI safeguard is the smallest solution that effectively covers the risks an agent actually faces, with the choice driven by threat surface, deployment environment, language, cost, and required margin of safety.

#How We Choose What Guards an AI Agent It depends on what the agent is for, and that turns out to matter more than which model scores highest.

For: Product leaders, business decision makers, and teams evaluating AI agents for production. People who have to make an architecture decision without becoming machine learning specialists.

Axel Fritz · Alquimia

We went looking for something cheaper than GPT-OSS-SAFEGUARD-20B, the model we had in production, and found more than we were expecting: small models that outperform much larger ones, and a pipeline of five cheap specialists that holds its own on the risks an internal agent actually faces. Whether you should use it depends on what the agent is for.  

01The model that worked was more model than we needed

  Every AI agent in production needs something in front of it that reads each incoming message and decides whether the agent should act on it at all. That covers jailbreak attempts, instructions written to hijack the agent, abusive language, and personal data that somebody pasted into a chat without thinking.   Ours was GPT-OSS-SAFEGUARD-20B, a model with 20 billion parameters reached through a cloud API, and it worked well enough that nobody had a reason to question it, which is probably why it took us a while to ask the obvious question about what we were paying for.   A model that large is built to recognize fourteen categories of violation, and most deployments never see fourteen. An internal agent answering questions from employees inside a client's own network is not going to get attacked with copyright violations or requests for illegal content. It is going to get attacked by someone trying to talk it out of its instructions, so everything else we were paying for sat there unused.   And some of what we were paying was not money, because reaching a very large model in practice means someone else's infrastructure, which means prompts leaving the client's network, and with a regulated client that ends the conversation before price even comes up.  

How We Choose What Guards an AI Agent

02What we went looking for

The question we set out to answer was whether a smaller model could handle one category as well as the large one handles all of them. If it could, an agent that only worries about jailbreak and prompt injection could run on hardware the client already owns, and be just as protected against the thing it actually worries about.

We expected to find differences. Guardian models come out of very different training sets, so we assumed the numbers would be volatile category by category, and what we were hoping to find was a cheaper option that still did the job.

So we tested five architectures against 185 curated cases across 14 categories of violation, in English and Spanish. Four of them were single models of different sizes, each covering everything on its own: GPT-OSS-SAFEGUARD-20B, Llama-Guard-3-8B, Granite-Guardian-3.1-2B and Qwen3Guard-0.6B. The fifth we assembled ourselves out of five small models chained together, none above 200 million parameters, each trained on one thing: prompt injection, abusive language, suicidal content, personal data and general toxicity. The pipeline stops as soon as one of them objects, and all of it runs on CPU.

03Size doesn't predict what it catches

Before getting to the pipeline we built, the result that surprised us most had nothing to do with it.

	GPT-OSS-20B	Qwen3Guard-0.6B	Granite-Guardian-2B	Our pipeline	Llama-Guard-3-8B
All 14 categories	98.7	89.3	87.0	82.9	77.5
Jailbreak	100	92.3	78.3	100	44.4
Violence	100	100	96.6	88.9	88.9
Personal data	100	50.0	75.9	100	87.5
Abuse	100	73.7	66.7	90.9	0.0
Profanity	100	95.7	95.7	100	0.0
Sexual content	100	96.6	96.6	80.0	75.0
System info	75.0	18.2	33.3	57.1	33.3

Detection score out of 100, balancing threats that slip through against safe content wrongly blocked. Every category rests on 12 to 15 cases, so a 100 here means every case of that category in our set was caught, and not that the category is solved.

Read the first row and the models come out in a sensible order. Read any other row and that order falls apart.

Llama-Guard-3-8B was the second largest thing we tested and more expensive per hour to run than everything except GPT-OSS, and it came last. It caught none of the abusive content in our set, none of the profanity, and under half of the jailbreak attempts. Qwen3Guard-0.6B, 33 times smaller and able to run without a GPU, came second overall at 89.3%, and then let half the personal data cases through.

GPT-OSS did win and we are not going to pretend it didn't, since it is the only column with nothing below 75. But the second largest model lost to something you could run on a laptop, which is enough on its own to show that size does not predict what a safeguard will catch. If you care which specific category gets caught then the overall score will not tell you, because an average across fourteen categories absorbs three complete failures and still looks respectable.

One row is worth reading on its own. System info covers attempts to get an agent to reveal its own configuration and instructions, and every model in the benchmark struggles with it, the best of them reaching 75. Nobody has that one solved, ourselves included.

04Five cheap specialists on a CPU

Then there is the option we put together ourselves, and this is where the cost argument gets interesting.

Across all fourteen categories the pipeline scored 82.9 against GPT-OSS at 98.7, which as a ranking is a loss, and if we had stopped at the overall number we would have dropped it there.

By category it held. Jailbreak, personal data and profanity all came out level with GPT-OSS at 100, and those happen to be the risks clients bring up first when we ask them what worries them. The pipeline does it on ordinary CPUs, answering in well under 150 milliseconds where everything else in the benchmark sat between 300 and 500.

For the internal agent we started with, those categories are close to the whole threat surface, and what the pipeline misses are things that deployment was never going to see anyway. If you can stack cheap specialists like that and get there, the savings are real, on hardware and on the dependency you avoid taking on.

05What the pipeline covers today, and what you can add to it

The pipeline covers the five most common specializations, and it does miss copyright, illegal content and sexual content, because we did not put a component in for them.

That is worth being clear about, and it also happens to be the easiest thing about this architecture to fix, because adding a category means adding a component, so you do not retrain anything and you do not touch the other four. If a client needs sexual content detection we go find a small model for it and it goes in the pipeline. There is plenty of room to keep going here, both with better models for the slots we already fill and with new slots for risks we have not covered.

Two things should be said about the evidence behind all this. We tested one configuration of the pipeline and it happened to also be the cheapest thing in the benchmark, so we cannot fully separate what came from composing small models and what came from them simply being small. A pipeline built out of stronger models is something we have not measured yet.

The other thing never shows up in a score at all. A single model tells you unsafe, while the pipeline tells you which component objected and why. For a client in banking or healthcare who has to explain a specific blocked message to a regulator, that traceability is worth a lot, even though it costs detection points to get.

06On one of them, the taxonomy is yours to write

There is a difference between GPT-OSS-SAFEGUARD and the other four that our benchmark could not measure, because we tested everything against the same fixed list of fourteen categories.

The other four arrive with their taxonomy already decided, since it was fixed when they were trained, so if a client cares about something the model never learned then the model has nothing to say about it. GPT-OSS-SAFEGUARD works the other way, because you hand it a policy you wrote and it reasons against that policy at inference time, which makes the categories, the definitions and the thresholds yours. Changing what it looks for means editing a paragraph instead of retraining anything, and it returns the reasoning behind each verdict, which you can read and argue with.

This is easy to file under the big model being better at everything, and it is worth being precise about, because it has nothing to do with size. It comes from how the model was post trained, so a general purpose model of the same size would not do it.

Since the policy is yours, it also does not have to be a classic safety category. A client who wants their agent held to a rule about how it treats an upset customer, or about never answering a distressed person with a bare policy quote, can write that as a policy too. OpenAI documents the model for safety taxonomies, so that part is us extending the idea and not reporting something we measured.

OpenAI is also clear about what the approach costs, and both caveats are worth repeating because they come from the vendor. Classifiers trained on large purpose built datasets can still beat it on complex or nuanced risks, and the reasoning takes more compute and time, which they say makes it harder to use at scale or in real time. Their own guide recommends putting small, high recall classifiers in front of it to prefilter, which is a design we like on paper and have not measured yet: a specialist handling the bulk of the traffic and passing only the cases it is unsure about up to GPT-OSS.

07Catching threats is one thing, staying out of the way is another

There is a gap in our benchmark, and in most benchmarks like it, that we would rather name here than have a reader find on their own.

A gatekeeper can fail two ways, either by letting something dangerous through or by blocking a customer who did nothing wrong. Our dataset is roughly three quarters unsafe content by design, because attacks are what you test detection against. Real traffic runs the other way round, so what we measured well is what gets through and what we measured thinly is what gets stopped by mistake.

That has a practical consequence. If wrongly blocking a legitimate customer is expensive for you, say in a sales conversation or a support channel, then the detection scores in this study are the wrong thing to optimize for. Somebody has to measure false alarms on traffic that looks like yours before anyone commits to an architecture.

08How we would choose now

It depends on what the agent is for, and we mean that as an answer.

The rule we use is the same everywhere, which is to find the smallest thing that covers the categories that would actually count as an incident, and what moves from one deployment to the next is how much margin you leave yourself on top of it.

If the agent is going into production where mistakes are expensive, with a broad threat surface and real customers on the other end, then that margin has to be wide, and GPT-OSS is usually what ends up covering it, since it was the only thing we tested with no weak category anywhere. Even there we would work out the categories first, because a deployment that turns out to face three of them does not need to pay for fourteen.

If the agent is internal, or runs in a closed environment, or is meant to be cheap, then the margin can be thin and a smaller specialized option deserves a shot, so work out the same two or three categories and see whether something small covers them. Often enough, something does.

Two things move the answer no matter which way you are leaning. The first is where it has to run, because a pipeline of small models fits inside a client's own environment and a cloud API does not, and with a regulated client that settles it before anything else gets discussed. The second is the languages, because models trained mostly on English do not degrade evenly in Spanish. GPT-OSS treated both the same, while our pipeline showed close to a ten point gap between them, which in a bilingual deployment is a fairness problem as much as a performance one.

On cost, all we can honestly say is that these options are not comparable, since some are billed by the hour of infrastructure and some by volume of usage. A client with steady traffic and a client with occasional bursts get opposite answers out of the same table, so we work that out per deployment.

09Three deployments

An internal agent inside a client's own network, where the real risk is someone talking it out of its instructions. Jailbreak and prompt injection, no customer data, nothing leaving the perimeter. The pipeline is what we would use here, and this is the case that started the study. It matched GPT-OSS on that category, runs on hardware the client already has, and answers faster, while its gaps in copyright and sexual content do not apply.

An agent handling regulated customer data in a market where a leak is existential. Personal data and jailbreak both matter and a leak makes the news, so GPT-OSS is the defensible choice. If the data cannot leave the perimeter, the pipeline is the only thing we tested that matched it on both of those categories while staying on the client's own hardware.

A public facing product in one language, moderate volume, low blast radius. Qwen3Guard earns its place here, since it is good across the board, needs minimal hardware and performs evenly in both our languages. There is one exclusion we would not negotiate: it caught half the personal data cases in our set, so if personal information is in scope at all, it is out.

10Where we take it next

Our dataset is 185 cases across 14 categories, which is enough to separate the architectures and not enough to settle any single category, since a category where a model scored perfectly had about a dozen cases behind it. Read these numbers as a reason to go look and not as a guarantee. One column of the table is also less even than it looks, since GPT-OSS was scored against a policy somebody on our side wrote, so part of that result measures how well the policy was written, while the other four brought their taxonomy with them.

What we want to measure next is false alarms on traffic that looks like production, regional Spanish and local slang, the grey zone cases where a horror story and a genuine threat read the same, and a pipeline built out of stronger models instead of cheap ones. The pipeline as it stands covers the five most common specializations well enough for the deployments we built it for, and there is room to keep adding to it.

If we could only keep one thing out of all of this, it would be that you cannot tell how well a safeguard will protect you from how big it is. Everything else comes down to working out what you are actually defending against, and then finding the cheapest thing that does it.

This benchmark was built with Gaussia, Alquimia's evaluation framework for AI systems, as part of the Gaussia research program.