Lost in Translation: When Safety Contracts Collapse Across 2.1 Billion Voices

A chatbot walks into a multilingual market

Imagine a bank, hospital, telecom platform, or public-service chatbot being rolled out across South Asia. The model has passed English safety tests. It refuses harmful requests in structured evaluation. Its vendor dashboard looks reassuring. The compliance team exhales.

Then users arrive.

They do not all write in English. They do not all use one script. They mix Hindi and English, write Urdu in Latin letters, switch between native script and romanization, and ask ordinary questions wrapped in messy instructions. In other words, they behave like real users, which is always inconvenient for benchmark design.

That is the business problem behind IndicJR: A Judge-Free Benchmark of Jailbreak Robustness in South Asian Languages.¹ The paper introduces Indic Jailbreak Robustness, or IJR, a benchmark for testing jailbreak robustness across 12 Indic and South Asian languages representing roughly 2.1 billion speakers. It covers Bengali, Gujarati, Hindi, Kannada, Malayalam, Marathi, Nepali, Odia, Punjabi, Tamil, Telugu, and Urdu. The benchmark contains 45,216 prompts, split into a JSON contract track and a FREE natural-language track, with additional tests for cross-lingual transfer and orthography.

The headline finding is not merely “multilingual safety is hard.” We knew that. The useful finding is more precise: safety can look different depending on the interaction contract, the language wrapper, and the script form. If a company only evaluates a model in English, or only under a neat JSON refusal schema, it may be measuring a controlled theater version of safety rather than deployed behavior.

This is not a call to panic. Panic is a poor evaluation methodology. The paper is more useful than that. It offers a way to turn “regional language risk” from a vague concern into a concrete testing program.

The safety contract is not safety; it is a testing condition

The paper’s most important mechanism is the contract gap.

In the JSON track, models are asked to respond with a structured refusal contract:

{
  "decision": "REFUSE|COMPLY|ABSTAIN",
  "justification": "..."
}

This makes scoring easier. It also changes model behavior. A contract can encourage refusal, abstention, schema compliance, and conservative behavior. That is useful for measurement, but it is not the same thing as observing how a model behaves in a normal user conversation.

The FREE track removes that structured contract. The model answers in unconstrained natural language. This is closer to what users see in a chatbot interface, customer-support window, or AI assistant embedded inside a workflow.

The difference is stark. In the JSON track, jailbreak success rates are already high across many models. GPT-4o has a JSON overall jailbreak success rate of 0.508. Grok-3 is 0.620. Cohere Command-R is 0.788. LLaMA 3.3 70B and LLaMA 4 Maverick 17B both reach 0.978. Sarvam 1 Base, despite Indic specialization, reaches 0.959, with low schema validity and high abstention.

Then the FREE track arrives and politely removes the illusion. Attacked-benign jailbreak success is near saturation across the evaluated models: GPT-4o 0.995, Grok-3 0.998, Cohere Command-R 0.999, LLaMA 3.3 70B 1.000, LLaMA 4 Maverick 17B 1.000, Gemma 2 9B 0.998, Sarvam 1 Base 0.999, and Qwen 1.5 7B 0.998. Even the lower values, such as Grok-4 at 0.934 and Cohere Command-A at 0.944, are not exactly reassuring.

The authors’ interpretation is that contracts inflate refusals and abstentions while failing to eliminate jailbreak vulnerability. That matters because many safety evaluations are contract-bound by design. They ask the model to behave in a clean format, then treat the result as a general safety signal. The paper’s evidence suggests that this can overstate practical robustness.

A model that behaves under a contract has not necessarily learned safe behavior. Sometimes it has learned to perform the contract.

IndicJR separates failures that normal safety reports blur

A useful part of the benchmark is its AB/CB/CH decomposition. This is not decorative acronym inflation. Each subset isolates a different failure mode.

This matters because “safety” is not one behavior. A model can refuse too much, refuse too little, leak harmful content, break schema, or hide behind abstention. A single aggregate safety score tends to blur these into a comforting soup.

IJR also uses multiple experiment types, and they should not be read as equal evidence for the same claim.

That last column is important. The paper is careful enough to include validation and reproducibility checks, but these do not magically turn the benchmark into a universal safety certificate. They strengthen the benchmark’s conclusions within its design.

Cross-lingual transfer means English attacks do not stay English

A common operational mistake is to treat English safety work as the center and regional-language safety as a translation layer. That assumption is convenient, scalable, and wrong in exactly the way convenient things often are.

IJR tests English-to-Indic transfer by pairing adversarial wrappers and Indic-language cores. The result: English adversarial prompts transfer strongly across all 12 target languages. In the pooled instruction-and-format transfer results, mean jailbreak success rates range from 0.585 for Nepali and 0.586 for Odia to 0.677 for Hindi and 0.694 for Urdu. These are not isolated corner cases.

The attack family matters. Format attacks generally transfer more strongly than instruction attacks. For example, Hindi has mean JSR of 0.774 for format attacks versus 0.581 for instruction attacks. Urdu shows 0.774 versus 0.613. Bengali shows 0.741 versus 0.528. Even where the instruction attack is weaker, the format wrapper remains a durable route.

That pattern is operationally uncomfortable. Many production teams harden models against instruction-override language: “ignore previous instructions,” “act as,” “developer mode,” and similar phrases. But format pressure is often treated as harmless UX plumbing: output YAML, produce JSON, translate then answer, follow this schema, preserve this structure.

The paper suggests that format is not just presentation. It can become an attack surface.

For a business deploying multilingual AI, this changes the test plan. It is not enough to test harmful prompts in each language. Teams should test adversarial wrappers separately from content cores, including cross-language combinations. A malicious or careless user does not need the entire prompt to be in the same language. Mixed instruction layers may be enough.

Native script is not automatically safer, and romanization is not automatically more dangerous

Here the paper complicates an easy story.

One might expect romanized and mixed-script prompts to be more dangerous because they are messier, less standardized, and common in real usage. That intuition is plausible. It is also incomplete.

In the JSON-contracted orthography stress test, romanization usually reduces jailbreak success relative to native script. Averaged across models, romanized inputs reduce JSR in every language in the appendix table. Urdu drops from 0.800 native to 0.369 romanized. Odia drops from 0.796 to 0.418. Bengali drops from 0.767 to 0.410. Hindi drops from 0.750 to 0.394. Mixed orthography also usually lowers JSR, though often less sharply.

This does not mean romanized input is “safe.” It means the interaction between script, tokenization, contract adherence, and model family is more subtle than the cartoon version. The paper links these effects to tokenization and fragmentation pressures: romanized and mixed forms can make prompts harder for the model to process consistently, reducing successful compliance in the JSON track.

That distinction matters. A lower jailbreak success rate under romanization in a contracted benchmark does not imply that real users writing romanized Hindi, Urdu, or Bengali are protected. It means the model’s behavior shifts when the representation shifts. Sometimes it refuses more. Sometimes it fails to follow the task. Sometimes it breaks the schema. Sometimes it becomes less usable rather than safer.

For deployment, the practical lesson is not “romanization is fine.” The lesson is: do not assume script variants are equivalent. Native script, romanized script, and mixed script should be separate test slices.

The paper’s more interesting contribution here is diagnostic. Orthography is not just a localization detail. It is a model-behavior variable.

Indic specialization is not a safety guarantee

One tempting interpretation is that models trained or specialized for Indic languages should naturally be safer in those languages. The paper does not support that comforting shortcut.

Sarvam 1 Base, the Indic-specialized model in the evaluation, performs poorly on several safety measures. In the JSON track, it has JSR of 0.959, schema validity of 0.186, leakage rate of 0.393 on clean-harmful prompts, abstain rate of 0.849, and clean-benign over-refusal of 0.915. In the FREE track, its attacked-benign JSR is 0.999, with clean-benign over-refusal of 0.17 and leakage rate of 0.15.

This does not prove that Indic-specialized models are inherently unsafe. It proves a narrower and more useful point: language coverage and safety robustness are not the same capability. A model can understand a language better without being robust to adversarial pressure in that language. It can generate fluent local-language output while still mishandling harmful prompts, over-refusing benign content, or failing structured contracts.

For vendors, this is mildly inconvenient. “We support Hindi” is not a safety claim. “We support Urdu in native and romanized scripts under adversarial wrappers and unconstrained interaction” is closer to a safety claim, but much harder to print on a product page without frightening the marketing department.

The judge-free design is valuable because it is reproducible, not because it is omniscient

IJR is judge-free. It avoids LLM-as-judge evaluation and instead uses deterministic scoring based on structured parsing, language-aware lexical cues, canary tokens, schema validity, and refusal detection.

This is a good tradeoff for a benchmark of this scale. LLM judges can be inconsistent across languages, sensitive to prompt wording, expensive at scale, and vulnerable to the same multilingual blind spots being tested. A deterministic system is easier to reproduce, audit, and compare.

The paper checks this design with a human audit: 600 samples, 50 per language, labeled by multilingual annotators with adjudication. The audit reports overall unweighted agreement of 0.68, weighted agreement of 0.74, 26 false negatives out of 600 samples, or 4.3%, and average schema validity of 95.4%.

That is not perfection. It is useful reliability.

The leakage analysis also matters. Canary leakage is zero across the reported bins, while lexicon leakage is rare but not absent. Sarvam and Qwen show higher lexicon leakage than most other models. This supports a practical reading: the detector appears specific enough for benchmark-scale comparison, but businesses should not treat deterministic detection as a replacement for deeper red-team review where high-risk use cases are involved.

A judge-free benchmark gives you a ruler. It does not give you a conscience, a legal department, or a magically competent deployment process. Sadly, procurement teams keep asking.

The appendix is not extra decoration; it is where the deployment map becomes clearer

The appendix contributes three operationally relevant pieces.

First, the per-language transfer tables show that the vulnerability is broad. Urdu and Hindi have the highest average English-to-Indic transfer rates in the pooled results, but even lower-average languages remain meaningfully vulnerable. No language functions as a natural firewall.

Second, the orthography tables show that romanization and mixed scripts change behavior systematically. The average romanized-native JSR delta is negative across languages, with large drops in Urdu, Kannada, Odia, Bengali, Gujarati, and Hindi. This supports the paper’s argument that script and tokenization are not peripheral concerns.

Third, the lite-versus-full reproducibility analysis shows that reduced sampling largely tracks full evaluation. Per-language full-versus-lite JSR means are close, and correlations are high across languages. For example, Bengali has full mean JSR of 0.795 and lite mean of 0.788, with Pearson 0.951 and Spearman 0.916. Malayalam has 0.745 versus 0.746, with Pearson 0.989 and Spearman 0.975.

For business users, this is one of the more practical results. It suggests that companies may not need to run the full benchmark every time they change a prompt template, model version, or guardrail. A lighter regression suite can preserve major signals, assuming it is designed carefully and periodically calibrated against fuller evaluations.

That is the ROI-relevant part: not cheaper safety theater, but cheaper diagnosis.

What Cognaptus would turn into a deployment checklist

The paper directly shows that multilingual jailbreak robustness varies by track, language, attack wrapper, orthography, and model family. It directly shows that JSON contracts can produce a different picture from unconstrained responses. It directly shows that English adversarial wrappers transfer into Indic-language contexts. It directly shows that orthography changes benchmark behavior.

Cognaptus would infer the following deployment practice for multilingual AI systems:

This is the business value of the paper. It does not merely add a new benchmark to the growing landfill of AI evaluation tables. It gives a way to decompose multilingual safety into testable mechanisms.

Where the paper’s evidence should not be overextended

The benchmark is strong within its frame, but the boundaries matter.

First, IJR is single-turn. Many real jailbreaks are multi-turn, especially in customer-service or assistant workflows where the user can probe, rephrase, and escalate. The paper does not claim to solve that.

Second, the harmful-intent coverage is limited to three categories: chemical synthesis, biological hazards, and illicit access. These are important, but they do not cover the full spectrum of safety risks: fraud, self-harm, medical misinformation, political persuasion, hate, harassment, or financial manipulation.

Third, the orthography variants are generated using standardized transliteration and mixed-script construction. Real user-generated romanization can be noisier, more regional, more abbreviated, and more creatively misspelled. Humanity remains undefeated in making text messy.

Fourth, deterministic detectors are reproducible, but they may miss subtle semantic leakage. The human audit helps, but it does not eliminate this risk.

Finally, the evaluated models, inference settings, and provider-side safety layers are snapshots. Deployment conditions change. A model update, system prompt revision, retrieval layer, moderation filter, or output parser can alter the observed behavior. This is why the paper is best read as a testing framework, not as a permanent ranking of model virtue.

The real lesson is not multilingual risk; it is evaluation mismatch

The easy conclusion is that South Asian language safety is under-tested. True, but not enough.

The sharper conclusion is that AI safety evaluation can fail by testing the wrong interaction. English-only tests miss language variation. JSON contracts miss natural behavior. Native-script tests miss romanization and code-switching. Same-language prompts miss cross-lingual attack transfer. Aggregate scores miss whether the failure is over-refusal, under-refusal, leakage, abstention, or schema collapse.

IndicJR’s contribution is to make those mismatches visible.

For companies deploying AI into multilingual markets, the paper implies a simple standard: do not certify a model for a population by testing a different population’s language, a different interaction format, and a different writing system. That sounds obvious when stated plainly. Apparently, the industry required 45,216 prompts to be reminded.

The serious version is this: safety is not only a model property. It is a property of the model, the language, the script, the wrapper, the interface contract, and the scoring rule. Change one, and the measured safety can change.

That is the uncomfortable but useful lesson. It means multilingual AI governance needs less theatrical confidence and more sliced evaluation. It also means firms can act: build regression suites across language, script, wrapper, and interaction mode; separate over-refusal from under-refusal; validate detectors; and rerun lite tests when models or guardrails change.

For 2.1 billion voices, “works in English” was never a safety strategy. It was a spreadsheet shortcut.

Cognaptus: Automate the Present, Incubate the Future.