# Your agent is multilingual. Your safety layer is not. A team ships an assistant and decides, early and without much debate, that it will accept input in any language. The decision is free in the most literal sense — the underlying model is multilingual, it was pretrained on a hundred languages and more, and turning away a user because they wrote in Swahili instead of English would mean writing code to detect and reject languages the model can already read perfectly well. So the assistant accepts everything. A user types in Bengali, the model answers in Bengali, and the product is better for it. The safety review happened too. It was thorough. There was a red-teaming pass, a refusal-test suite, a list of disallowed requests that the model was checked against one by one — generate this weapon, write this malware, produce this harassment — and the model refused all of them, cleanly and consistently. The review signed off. The refusal behavior is real; the team watched it work. The review was conducted in English. Every adversarial prompt, every red-team probe, every entry in the refusal suite was written and tested in English, because English is the language the safety team speaks and the language the tooling assumes. A request the model firmly refuses in English — the team has the transcript — it answers when the same request, the same words, arrives translated into a low-resource language. The refusal was never a property of the model. It was a property of the model reading English. This post is about why LLM safety alignment is English-shaped — why the same unsafe request elicits unsafe output far more often once it is translated out of English, and why a defense developed and validated in English does not transfer cleanly to the other languages your product already accepts. ## A multilingual model does not have a multilingual safety layer The mistake is a quiet inference, and it is quiet because each step in it sounds reasonable. The model is multilingual — true. It was trained on text in many languages, it understands a request written in any of them, it produces fluent output in all of them. The capability is genuinely there, spread across the whole language set, and a team that has watched the model converse in Tamil has no reason to doubt it. From there the inference runs: the model handles all these languages, so whatever the model does is done in all these languages. Its helpfulness is multilingual, so its harmlessness must be multilingual too. Safety is just another behavior the model has, and the model has its behaviors in every language it speaks. That last step is the error, and it is an error about how the two capabilities were built. Multilingual understanding comes from pretraining — an enormous, broad corpus scraped across languages, and the breadth of that corpus is the whole point of it. Safety alignment comes from somewhere else entirely: a comparatively tiny, deliberately curated stage layered on top — instruction tuning, preference optimization, red-teaming, refusal data. That stage is small, expensive to produce, and assembled by people. And the people who assemble it work in English, source their adversarial examples in English, and write their refusal demonstrations in English. The alignment data is not spread across a hundred languages the way the pretraining data is. It is concentrated, overwhelmingly, in one. So the model ends up lopsided. Its understanding is wide because the corpus that built it was wide. Its refusal behavior is narrow because the corpus that built it was narrow. The model can read an unsafe request in forty languages and has been trained to refuse it in roughly one. A multilingual model with an English safety layer is not a contradiction the model resolves on its own — it is the default outcome of how the two halves are made, and it is exactly the system the team shipped. ## What "safety does not transfer" actually means There are two distinct claims here, and keeping them apart is what makes the rest of the post precise rather than alarmist. The first claim is about the attack surface. Take an unsafe request that the model reliably refuses in English. Translate it — just translate it, no jailbreak, no role-play, no clever framing — into a language the model saw little of during alignment. The model now complies with that request far more often than it did in English. The unsafe behavior was always reachable; the translation is what reaches it. The English refusal was a lock on one door of a building with forty doors. The second claim is about the defense surface, and it is the one teams miss. When you build a defense — a safety classifier, a system-prompt guardrail, an input filter — and you develop it against English attacks and validate it on English benchmarks, you have a defense that works in English. That is all you have measured. The defense does not automatically extend its protection to the other languages your product accepts, and the research below shows it genuinely does not: a defense that performs well in one language can perform poorly in another, and which languages it covers depends on the specific defense and the specific model. Put the two claims together and the shape of the exposure is clear. The attack surface is wider than English — every language the model accepts is a way in. The defense surface is narrower than the attack surface — it covers the languages it was tuned and tested against, and not reliably the rest. The gap between those two surfaces is the part of your product that is unsafe and that your English testing, by construction, never looked at. ## What the research shows The English-centricity of safety is not a hunch. It has been measured directly, the measurements span 2023 to late 2025, and they converge. Start with the foundational result, because it set the terms for everything after it. [_Low-Resource Languages Jailbreak GPT-4_](https://arxiv.org/abs/2310.02446) (arXiv 2310.02446) ran the simplest possible attack: take an unsafe English prompt, translate it into a low-resource language, send it, translate the answer back. No jailbreak technique beyond the translation itself. Translating an unsafe English prompt into a low-resource language raised the rate at which it bypassed GPT-4's safety filter from under 1% to 79%. Sit with the size of that jump — a request that essentially always failed in English succeeded four times in five once it was rephrased in a language the alignment process underweighted. The same paper makes a second point that should reframe how a security team ranks its threats. The combined low-resource-language attack, at 79.04%, outperformed every English jailbreak baseline the authors tested — AIM at 55.77%, Refusal Suppression at 11.92%, Prefix Injection at 2.50%, Base64 at 0.19%. Translation is not a minor addition to the jailbreak toolkit. On these numbers it is the strongest single technique in it, and it requires no adversarial craft at all — only a translator. And the effect tracks resource level cleanly: high- and mid-resource languages all stayed under 15%. The languages the model saw a lot of during alignment held; the languages it saw little of did not. The second seminal result, published the same month, generalizes the finding past a single attack and a single model. [_Multilingual Jailbreak Challenges in Large Language Models_](https://arxiv.org/abs/2310.06474) (arXiv 2310.06474), which introduces the MultiJail benchmark, measured unsafe-content rates across resource tiers and found low-resource languages roughly three times as likely to produce unsafe content as high-resource ones — for ChatGPT, 4.34% rising to 14.92%; for GPT-4, 3.60% rising to 10.16%. The three-times multiplier is the quiet, structural version of the headline number: even without a deliberate attack, simply moving down the resource ladder makes unsafe output several times more likely. That paper also measured what happens when translation is combined with an actual malicious instruction rather than used alone. Pairing a malicious instruction with a multilingual prompt produced unsafe output 80.92% of the time for ChatGPT and 40.71% for GPT-4. And one language carried a disproportionate share even on its own: Bengali alone reached 28.25% unsafe for ChatGPT and 12.7% for GPT-4. A product that accepts Bengali — and a multilingual product very plausibly does — is, on those numbers, accepting a materially larger unsafe-output rate through that one language than its English testing ever recorded. Those two papers are from 2023, which in this field is the distant past, and a fair reader will ask whether the gap has simply been closed since. It has not — and the recent work is what makes that answer load-bearing. [_The State of Multilingual LLM Safety Research: From Measuring the Language Gap to Mitigating It_](https://arxiv.org/abs/2505.24119) (arXiv 2505.24119) is a systematic review of nearly 300 publications from 2020 through 2024, and its conclusion is the structural explanation under every number above: there is a significant and growing language gap in LLM safety research, with even high-resource non-English languages receiving minimal attention. The gap is not shrinking as the field matures; the review finds it growing. Safety research is English-centric, and because safety research is what produces alignment data, alignment is English-centric too. The 2023 attack numbers are not a bug that a patch closed. They are a symptom of a research distribution that the 2025 review shows is still lopsided. The last result is the one that extends the problem from the attack side to the defense side. [_Do Methods to Jailbreak and Defend LLMs Generalize Across Languages?_](https://arxiv.org/abs/2511.00689) (arXiv 2511.00689) is the first systematic multilingual evaluation of both jailbreaks and defenses, run across ten languages. Its findings are precise and they cut in a specific direction. For both attacks and defenses, the numbers vary across languages — attack success rate is not constant from one language to the next, and neither is defense robustness. And the finding that matters most for a team about to ship: simple defenses can be effective, but their effectiveness is language- and model-dependent. A defense is not a property you establish once in English and then own everywhere. It is a property you have measured in the languages you measured it in, and the paper's evidence is that it does not reliably carry to the ones you did not. ## The honest version: low-resource is not a synonym for unsafe This is the honest-scope section, and it matters because the easy version of this post's argument is wrong, and a reader who knows the literature will catch it. The easy version is: low-resource languages are unsafe, high-resource languages are safe, sort your languages by resource level and you have sorted them by risk. The 2023 numbers seem to license exactly that — the rate climbs as the resource level falls, monotonically, across both papers. It is a tidy story and it is tempting to ship it as the conclusion. It is not the whole picture, and [_Do Methods to Jailbreak and Defend LLMs Generalize Across Languages?_](https://arxiv.org/abs/2511.00689) (arXiv 2511.00689) is the paper that complicates it. That study found the resource-level story holds for one kind of input and inverts for another. Under standard queries — plain unsafe requests, the translation-only attack of the 2023 papers — high-resource languages were indeed safer. But under adversarial jailbreaks, the more elaborate constructed attacks, high-resource languages including English were sometimes more vulnerable, not less. And the single safest language under jailbreaks in that study was Telugu — a low-resource language. The ordering you would predict from resource level alone is not the ordering the adversarial results produced. So the unqualified claim — "low-resource languages are always worse" — is false, and a security argument that rests on it rests on something a careful reader will knock over. What survives is narrower and sturdier, and it is two separate, defensible statements: The first: under plain or translated unsafe prompts, low-resource languages are far less safe. This is the 2023 result, it is large, it reproduces across two papers and multiple models, and it is the exposure most multilingual products actually face — most hostile input is not an artful jailbreak, it is a direct request, possibly translated. The second: defenses are language- and model-dependent and do not transfer. This is the 2511.00689 result, and it holds regardless of which language turns out to be safest in any particular ranking. Whatever your risk ordering across languages is, a defense validated in English is not known to hold across that ordering, and you do not get to assume it does. Notice what this honest scoping does not do. It does not weaken the post's recommendation — it sharpens it. "Low-resource languages are risky" would tell you to go test a particular tier and relax about the rest. The accurate finding tells you something stricter: the risk ordering across languages is not predictable from resource level in advance, and your defense's coverage is not predictable from its English performance. The only way to know either is to measure it, per language, on your system. The honest version of the claim is the version that forces the test. ## Closing the language gap in your safety layer You cannot inherit multilingual safety from a multilingual model. You can stop assuming you have it, and close the specific gap between the languages you accept and the languages you have actually made safe. **Safety-test every language you accept input in.** This is the decision the rest follows from. Your refusal suite, your red-team probes, your jailbreak corpus — they exist in English; translate them, with care, into every language the product accepts, and re-run them. An untested language has an unmeasured unsafe-output rate, and the research says that rate is not the English rate. The test does not have to be exotic: the foundational attack is just translate-and-resend, and you can run it against your own model in an afternoon, per language, and read the number off. **Do not assume an English-validated defense transfers.** A safety classifier, a guardrail prompt, an input filter — whatever defense you deploy, its performance is established only in the languages you evaluated it in. Validate each defense per language, exactly as you would re-measure it after a model swap, because [_Do Methods to Jailbreak and Defend LLMs Generalize Across Languages?_](https://arxiv.org/abs/2511.00689) (arXiv 2511.00689) shows defense robustness is language-dependent. A defense with a strong English number and no other numbers is a defense you have not actually scoped. **If you cannot safety-cover a language, constrain input to the languages you can.** This is the uncomfortable recommendation, and it is the honest one. Accepting every language was free on the capability side and is not free on the safety side. If your team cannot build and maintain a tested safety layer for a language, then accepting that language ships a known, unmeasured hole. Detecting the input language and declining the ones you have not covered is a real engineering cost — but it is a smaller cost than an unsafe-output rate you never sized. Scope the accepted-language set to the safety-covered set on purpose, not by omission. **Treat the multilingual surface as part of the injection threat model.** Translation is a jailbreak technique — the 2023 result puts it above every English baseline tested — so it belongs in the same threat model as the rest of them. The discipline that [prompt injection is a vulnerability class, not a bug](/blog/prompt-injection-vulnerability-class/) lays out applies here without modification: language is one more channel hostile input arrives through, the residual rate per language is non-zero, and your architecture has to stay safe at that rate. A team that runs the [indirect-injection numbers](/blog/indirect-injection-numbers/) for English and stops there has measured one channel of several. **Weigh the per-language rate by the audience it is attached to.** A per-attempt unsafe-output rate is not a risk on its own — it is a risk multiplied by how many users send input in that language and by what the assistant can do for them. A high unsafe rate in a language with real traffic is a real exposure; the same rate in a language nobody uses is mostly theoretical. Measure per language, but prioritize the remediation by the languages your users actually write in. **Re-measure when the model changes.** Multilingual safety is even less stable across model versions than English safety, because it depends on alignment-data coverage that no two model releases distribute the same way. A model swap can move your per-language unsafe rates without anyone touching the safety code. The per-language test suite belongs in CI, and it gets re-run on every model change — the same discipline [voice and joint-modality jailbreaks](/blog/voice-joint-modality-jailbreaks/) demand of every non-text channel. ## The checklist Before you call a multilingual product's safety layer adequate: - [ ] The refusal suite, red-team probes, and jailbreak corpus have been translated into every language the product accepts, and re-run, with a measured unsafe-output rate per language. - [ ] Every deployed defense — classifier, guardrail, filter — has a measured robustness number in each accepted language, not only in English. - [ ] The set of languages the product accepts is no larger than the set of languages it has a tested safety layer for; uncovered languages are declined, not silently accepted. - [ ] The translate-and-resend attack is run against your own model, per language, as a standing test — not assumed to behave like English. - [ ] The risk ordering across languages is established by measurement, not predicted from resource level, given that adversarial results can invert the resource-level ordering. - [ ] Translation is in the prompt-injection and jailbreak threat model as a first-class attack channel. - [ ] Per-language unsafe rates are weighted by real user traffic in each language when prioritizing remediation. - [ ] The per-language safety suite runs in CI and is re-measured on every model swap; multilingual safety is not assumed to carry across model versions. ## Reading list - [_Low-Resource Languages Jailbreak GPT-4_](https://arxiv.org/abs/2310.02446) (arXiv 2310.02446) — the foundational result: translating an unsafe English prompt into a low-resource language raises the safety-bypass rate from under 1% to 79%, outperforming every English jailbreak baseline tested. - [_Multilingual Jailbreak Challenges in Large Language Models_](https://arxiv.org/abs/2310.06474) (arXiv 2310.06474) — the MultiJail benchmark: low-resource languages are roughly three times as likely to produce unsafe content, and a malicious instruction plus a multilingual prompt reaches 80.92% unsafe for ChatGPT. - [_Do Methods to Jailbreak and Defend LLMs Generalize Across Languages?_](https://arxiv.org/abs/2511.00689) (arXiv 2511.00689) — the first systematic multilingual evaluation of both attacks and defenses across ten languages; attack success and defense robustness both vary by language, and simple defenses do not transfer. - [_The State of Multilingual LLM Safety Research: From Measuring the Language Gap to Mitigating It_](https://arxiv.org/abs/2505.24119) (arXiv 2505.24119) — a systematic review of nearly 300 publications finding a significant and growing language gap in safety research, the structural reason alignment is English-centric. A multilingual model gives you multilingual understanding for free, and it is easy to assume the safety came bundled in the same box. It did not. The understanding was built from a corpus that spanned every language; the refusal behavior was built from a corpus that spanned roughly one. Your product accepts every language the model can read. Your safety layer covers the languages your team wrote tests for. Those are two different lists, and the users who find the gap between them will not be the ones writing in English.