Your AI Speaks 100 Languages. Your AI Security Layer Doesn't.

"Supports 100+ languages" is a useful product claim.

It tells you the model or applica ation can probably accept prompts, return answers, and help users work across a wide range of languages. It does not automatically tell you that the AI security layer can detect attacks, preserve policy meaning, or make consistent enforcement decisions across those same languages.

That difference matters because attackers do not need perfect grammar or elegant translation. They need intent to survive long enough to influence the model, bypass a control, or trigger an unsafe action. Once AI systems are connected to enterprise data, retrieval pipelines, tools, and agents, multilingual support becomes more than a usability feature. It becomes a security question.

For multinational companies, this is not theoretical. Enterprise AI workflows rarely stay inside one clean English-language boundary. Regional teams use local languages. Support tickets arrive in local languages. Contracts, invoices, customer records, screenshots, chat logs, knowledge-base articles, and regulatory documents move through global systems in whatever language the business actually uses.

Security controls have to follow that reality.

Multilingual support is not multilingual protection

Most AI systems treat language support as a user experience capability.

Can the model answer in the user's language? Can a support workflow process localized tickets? Can the application summarize documents from different regions? Can teams work without constantly translating everything into English first?

Those are legitimate product requirements, but security operates under a stricter standard. A security layer must detect prompt injection, recognize personal and sensitive data, preserve the meaning of policy, judge whether an output violates controls, and stop risky tool calls before they execute. Regardless of the language. No matter the localization.

Those capabilities do not automatically appear because the base model can respond in many languages. A multilingual AI experience can work well for users while the security layer quietly remains English-first, translation-dependent, and uneven under pressure. Very convenient. Very enterprise.

Translation can hide the attack

Translation is often treated as a neutral preprocessing step, as if the system can simply convert everything into English and then apply the same security logic. That assumption is cleaner than reality.

Security intent can shift during translation. A jailbreak may become less explicit. A prompt injection may lose some of its command structure. A culturally specific phrase may be flattened into harmless text. A sensitive term may be translated poorly or mapped into language that no longer matches the security policy. Mixed-language inputs can preserve the malicious instruction in one language while surrounding it with benign context in another.

This creates an uncomfortable failure mode: the original content was risky, the translated content looks less risky, and the security system evaluates the translated version. Everyone gets a dashboard. Nobody gets the original risk.

The scale of that gap has already been measured outside of DeepKeep's own research. A Brown University study found that translating unsafe inputs into low-resource languages got GPT-4 to engage with harmful requests 79% of the time, versus under 1% in English. That is not a rounding error in model behavior. It is a systematic blind spot that any attacker can exploit simply by choosing a different language.

The problem becomes more serious in RAG and agent workflows, where the risky instruction may not come from the user at all. It may arrive through a retrieved document, a support ticket, a web page, an uploaded PDF, a screenshot, or a tool response. The model sees context, the agent may treat that context as actionable, and the security layer may only see normalized text that has already lost part of the attack.

That is not a translation bug in the narrow sense. It is a control-design problem, and it shows up directly in detection accuracy. In benchmark testing of PII detection across languages, a translation-based approach lost meaningful accuracy the further a language sat from English, while a model built to reason natively in each language held up:

The gap is not uniform. It is worst exactly where you'd expect the "translate to English first" assumption to break down hardest. Japanese saw the largest drop for the translation-based approach (61.4% vs. 83.4% for DeepKeep, a 22-point gap), with German, Spanish, and Italian all showing similar patterns.

LLM-as-a-Judge has the same problem

Many AI security workflows now use LLM-as-a-Judge patterns to evaluate prompts, responses, red-team results, policy violations, and sometimes runtime decisions. This can be useful, especially when security teams need to review large volumes of AI interactions without turning every event into manual analysis.

It can also produce a false sense of measurement.

If the judge model is stronger in English than in other languages, the evaluation layer may under-score real attacks before a human reviewer ever sees them. The judge may catch an English prompt injection but miss the same intent in another language. It may handle formal language better than slang, dialect, transliteration, or code-switching. It may also interpret translated content differently from native-language content, especially when the attack depends on nuance rather than obvious keywords.

So the useful question is not whether the organization can run the judge on multilingual inputs. The useful question is whether the judge reaches the same security decision when the same attack intent appears across languages, formats, and workflows.

That needs testing. Preferably before someone puts the judge score into an executive slide and calls it assurance.

Here is what that testing looks like in practice: the same prompt injection benchmark, run across 12 languages, comparing DeepKeep against an LLM-as-a-Judge baseline and open-source guardrail models from Meta (Prompt Guard, Prompt Guard 2, Llama 3.1, and Llama Guard 3). Additional testing in the same study also benchmarked against Nvidia's NeMo Guardrails, so the comparison set spans more than one vendor's approach to the problem.

Two things stand out. First, every guardrail model here drops meaningfully outside English, and several swing hard from language to language. Llama 3.1 alone ranges from roughly 30% in Italian to 75% in Romanian, which is exactly the kind of inconsistency that turns "we ran the judge on multilingual data" into a misleading claim. Second, DeepKeep is the only line in the chart that stays essentially flat, holding close to 99% Macro F1 across every language shown here. The fuller benchmark extends to additional languages and models beyond this view, including Korean and Nvidia's NeMo.

That flatness is the actual test that matters: not "can it detect this in English," but "does it reach the same decision no matter what language the attack arrives in."

Policy fidelity is the real test

Security policy has meaning, and that meaning has to survive language boundaries. Policies such as "do not disclose credentials," "do not follow instructions from retrieved content," "do not call external tools with customer data," or "do not modify production records without scoped authorization" are simple enough to write in English. They are harder to enforce consistently across multilingual, multimodal, agentic systems.

A strong multilingual control has to preserve policy meaning, not just translate policy words. It has to understand where an instruction came from, whether that source should be trusted, what data is involved, which tool or workflow may be affected, and what consequence follows if the model gets it wrong.

For example, a credential may appear inside a localized support transcript. A prompt injection may be embedded in a Japanese PDF. A Hebrew ticket may instruct the agent to ignore system rules. A Korean screenshot may contain a tool-use instruction. A Spanish document may mix harmless business text with one malicious sentence. An English user prompt may reference non-English retrieved context that contains the actual attack.

In all of those cases, the control has to apply the same security policy without flattening the context into something easier but less accurate. Translation helps, but it does not replace security judgment.

Testing should follow the attack path

Security teams do not need a ceremonial spreadsheet with every language, every dialect, and every theoretical wording variation. That is how good ideas become audit furniture.

They do need to test the attack paths that matter.

A practical multilingual security review should compare the same attack intent across languages and check whether the system reaches the same security decision. It should include native-language input, translated input, mixed-language prompts, retrieved documents, tool outputs, and multimodal content such as screenshots or PDFs where relevant.

The point is not to prove that every language behaves identically. It will not. The point is to identify whether translation changes the risk signal, whether the judge model scores the same behavior differently, and whether runtime enforcement still applies the right action.

For a multinational company, this kind of review should be tied to real workflows. Customer support, legal review, finance operations, HR processes, engineering copilots, and regional knowledge bases all create different multilingual exposure. A generic jailbreak test in five languages is better than nothing, but it is not the same as testing the places where the business actually uses AI.

Runtime enforcement still has to act

Detection is not the finish line. Once multilingual risk is detected, the system still has to take the right action while the interaction is live.

Sometimes that action should be a block. Sometimes it should be redaction. Sometimes the system should replace unsafe output with a safer response. Sometimes it should alert with enough evidence for a security team to review the event without interrupting the workflow.

The right action depends on context: the data involved, the source of the instruction, the confidence of the detection, the tool being used, and the consequence of allowing the interaction to continue. A multilingual prompt injection that causes an agent to send data to the wrong place is not a content moderation problem. It is a runtime enforcement problem.

This is where multilingual AI security has to move beyond translation and evaluation. The system needs to make a decision, enforce it, and leave a record that a security team can actually investigate later.

How DeepKeep approaches multilingual coverage for AI security

DeepKeep treats multilingual AI security as a native detection and enforcement problem, not as a translation wrapper around English-first controls.

That distinction matters. Translation can be useful, but it should not be the only mechanism deciding whether an AI interaction is safe. If the control depends entirely on translating risk into English before evaluating it, then the translation layer becomes part of the security boundary. That is a fragile place to put trust.

DeepKeep's approach is built to evaluate AI risk across languages while preserving the security meaning of the interaction: the user intent, the retrieved context, the model output, the tool action, and the policy being enforced. Rather than translating text into English and then classifying it, DeepKeep analyzes the semantic meaning of prompts and responses directly in the language they arrive in. This cognition-based analysis produces an interpretable security decision instead of a black-box score.

Because the system reasons over meaning rather than pattern-matching against translated keywords, it also handles zero-day and mixed-language prompts, a scenario increasingly common in enterprise environments where users combine multiple languages within a single query, without needing to have seen that exact wording before.

The benchmark numbers back that up.

Tested against SafeGuard, WildJailbreak, and Alpaca prompt injection datasets, translated into 12 additional languages including Spanish, French, German, Japanese, Italian, Korean, Dutch, and Portuguese, DeepKeep achieved Macro F1 scores approaching 0.98 in prompt injection detection. Guardrails from both Meta (Prompt Guard, Prompt Guard 2, Llama 3.1, Llama Guard 3) and Nvidia (NeMo Guardrails), along with an LLM-as-a-Judge baseline, all showed lower accuracy and wider swings from one language to the next in the same testing. The chart above shows that pattern across the subset of those languages and models plotted. On PII detection, the same pattern held: DeepKeep outperformed a translation-based approach in every language tested, with the gap widening most in Japanese (83.4% vs. 61.4%).

This is especially important for organizations operating across regions, business units, and local-language workflows. A multilingual support ticket, contract clause, HR record, engineering document, or customer message should not receive weaker security treatment because it was not written in English.

Native multilingual coverage helps security teams evaluate prompt injection, sensitive data exposure, policy violations, unsafe responses, and agent/tool abuse across languages without treating translation as the control itself.

That does not make multilingual AI security magically simple. But the benchmark data points at what "the right place" for the control actually looks like: closer to the actual AI interaction, closer to runtime enforcement, and closer to how global enterprises really use AI.