Multilingual AI security gaps expose English-first LLM defenses

At a glance

What this is: This is Lakera’s analysis of how English-first AI safety controls break down when LLMs process prompts and data in multiple languages.

Why it matters: It matters because teams governing GenAI, agentic AI, and human-facing AI workflows need controls that enforce policy consistently across languages, or attackers will route around them.

By the numbers:

• Attackers bypassed Gandalf's guardrails in over 85 languages using code-switching, translation-based exploits, and multilingual data extraction.

Context

Multilingual AI security is the control problem that appears when an LLM can understand many languages, but the safety layer is still strongest in English. If the guardrail logic, moderation model, or policy prompts are language-biased, the model may block a harmful English query while missing the same intent in another language or script.

Lakera argues that this creates a governance gap for GenAI programmes operating across regions, user populations, and support channels. The issue is not model capability alone. It is inconsistent policy enforcement across languages, which turns language selection into an attack path.

For identity and access teams, the relevance is clear: runtime policy must be evaluated as part of the AI control plane, not treated as a language-localisation issue. Where AI systems can expose data, trigger actions, or mediate decisions, multilingual inconsistency becomes an access-control problem as much as a content-safety problem.

Key questions

Q: How should security teams test LLM guardrails across multiple languages?

A: Security teams should test the same harmful intent in every major language and in code-switched variants, then compare block, warn, and allow outcomes. The goal is to prove that policy enforcement is intent-based rather than English-based. If equivalent prompts produce different outcomes, the control is inconsistent and should not be trusted in production.

Q: Why do English-first AI controls fail in production?

A: Because moderation and refusal logic are often tuned to English patterns, while real users and attackers do not stay inside one language. That creates uneven policy enforcement, especially when prompts are paraphrased, code-switched, or translated into lower-monitoring languages that the guardrail does not classify with the same confidence.

Q: What are the signs that multilingual AI safety is breaking down?

A: Look for different outcomes on semantically identical prompts, higher jailbreak success in specific languages, and unexpected refusals for benign non-English inputs. Those symptoms show the control is not language-invariant and may be creating both security gaps and usability regressions at the same time.

Q: How do organisations govern AI systems that handle sensitive data in multiple languages?

A: Define one policy boundary for all supported languages, then test it against prompts, outputs, and translation paths that touch sensitive data. If the system can reveal personal, operational, or internal information in one language but not another, governance has to move from model behaviour to runtime enforcement.

Technical breakdown

Why English-first guardrails fail in multilingual LLMs

LLM safety controls are often trained and tuned in English, which means the detector, moderation layer, and refusal logic can become less reliable as language changes. Attackers exploit this by rephrasing harmful prompts, using code-switching, or translating requests into less monitored languages. The model may still understand the user, but the safety layer no longer recognises the risk pattern with equal confidence. That gap is most dangerous when policy enforcement depends on prompt classification rather than on downstream runtime controls.

Practical implication: Treat language coverage as a security control requirement, not a localisation preference.

How translation-based bypasses defeat policy consistency

Translation exploits work because many AI controls assume that risk is expressed in a stable linguistic form. Once a malicious request is reworded, paraphrased, or moved into a low-resource language, the policy signal can weaken enough for the model to comply. In practice, this means the same prohibited intent can pass through one language gate and be blocked in another. That is a governance failure, because the policy itself is no longer invariant across user input conditions.

Practical implication: Test policies against translation, paraphrase, and mixed-language inputs before deployment.

Why multilingual data extraction raises the stakes

Multilingual data leakage is not just about unsafe answers. It shows that a model can be coaxed into revealing restricted information when the request language changes. This matters for AI systems handling personal data, internal knowledge, or operational instructions, because the attack is not model compromise in the classic sense. It is policy drift across language boundaries. The practical failure is inconsistent enforcement of the same access decision across different user expressions.

Practical implication: Place runtime screening on both prompts and responses when the model can handle sensitive data.

Threat narrative

Attacker objective: The attacker wants to bypass AI safeguards and extract restricted output or sensitive data without triggering the intended policy block.

1. Entry begins when an attacker submits a harmful prompt in a non-English language, mixed-language query, or translation-based variant that the English-first guardrail does not classify correctly.
2. Credential-like control is bypassed when the safety layer fails to map the translated intent to the restricted English policy, allowing the model to process the request as if it were benign.
3. Impact follows when the model produces disallowed instructions or leaks sensitive data across languages, showing that enforcement was inconsistent rather than absent.

Breaches seen in the wild

• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multilingual policy drift is the core security problem, not just multilingual content support. When the same prohibited intent is blocked in one language and permitted in another, the control is no longer enforcing policy. That inconsistency creates a new attack surface for prompt injection, data extraction, and output manipulation. Practitioners should treat language coverage as a policy integrity issue, not a user-experience issue.

Language selection has become a practical bypass technique for GenAI systems. Code-switching and translation-based attacks work because safety layers often inherit assumptions from English-centric training data. The result is a control plane that behaves unevenly across user populations and geographies. Security leaders need to assess whether their AI governance model can enforce the same decision across scripts, dialects, and translated prompts.

Cross-language safety is now part of identity-adjacent access control for AI systems. When an LLM can expose personal data, internal knowledge, or operational actions, the language layer effectively participates in authorisation. If that layer is inconsistent, the model may grant different outcomes for the same request based only on wording. The implication is that AI policy enforcement must be designed as a uniform control boundary, not a model wrapper.

Multilingual attack resistance is becoming a baseline expectation for production GenAI. Organisations serving global users cannot assume English-first moderation will scale safely. The more the model is used across support, search, and workflow automation, the more a language gap becomes an operational risk. The practical conclusion is straightforward: multilingual enforcement belongs in AI governance, testing, and monitoring from the outset.

Low-resource languages expose a distinct security blind spot. When training and red-teaming are concentrated in English, safety performance drops where data is scarce and adversarial pressure is least visible. That is a governance failure because risk concentrates where assurance is weakest. Teams should validate controls across the languages their systems actually encounter, not just the languages their builders prefer.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.

What this signals

Multilingual enforcement is now a control boundary issue. If a GenAI system can be bypassed by translation or code-switching, then policy is being decided by language choice rather than by the underlying request. That is a structural weakness for any AI programme that serves global users or consumes multilingual content.

Teams should assume the attack surface expands with every supported language. Security testing that stops at English leaves the highest-risk bypass paths unmeasured, especially where low-resource languages or transliterated scripts are involved. The practical shift is to test the policy layer with the same discipline used for runtime access controls.

Language-aware AI governance will increasingly sit alongside human IAM and NHI controls. As models mediate access to information and actions, inconsistent multilingual policy becomes an authorisation problem, not just a moderation problem. Programmes that treat this as a localised content issue will miss the operational risk entirely.

For practitioners

• Test safety controls across languages Build multilingual adversarial test cases for prompts, code-switching, paraphrase, and translation-based bypasses before release and after major model changes.
• Validate policy consistency at runtime Check whether the same restricted intent produces the same refusal outcome in English, translated forms, and mixed-language prompts.
• Screen inputs and outputs together Apply runtime controls to both user prompts and model outputs so translated requests cannot evade detection on the way in or on the way out.
• Map language coverage to business exposure Inventory which customer journeys, support workflows, and internal AI use cases accept non-English input, then prioritise the highest-risk ones for deeper testing.

Key takeaways

• English-first guardrails do not provide consistent protection when users can rephrase prompts across languages, scripts, or translation paths.
• Lakera's article shows that multilingual attacks are not hypothetical, with real-world bypasses and over 85 languages affected in its Gandalf testing.
• Security teams need multilingual testing, runtime screening, and policy consistency checks if they want AI controls to hold up outside English.

Key terms

• Multilingual Guardrail: A multilingual guardrail is a safety control that applies the same policy decisions across multiple languages, scripts, and transliterations. In AI systems, the control must recognize equivalent harmful intent regardless of wording, or attackers can bypass enforcement by changing language rather than meaning.
• Code-switching: The act of mixing two or more languages within a single prompt or conversation. In AI security, code-switching matters because it can split harmful intent across language boundaries, making it harder for moderation systems to detect the request as dangerous even when the user’s meaning is clear.
• Translation-Based Exploit: A translation-based exploit is an attempt to evade policy enforcement by rephrasing or translating a restricted prompt into another language. The risk is not translation itself, but the way inconsistent safety controls can fail to preserve the same decision boundary after the wording changes.
• Language-Invariant Policy: A language-invariant policy produces the same security decision for the same intent, regardless of the language used to express it. For GenAI programmes, this matters because policy consistency is part of control integrity, especially when models expose data or trigger actions across global user populations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.