Language Validator
The language-validator policy enforces language restrictions on AI inputs and outputs. Use it to ensure responses are in the correct language for your users, comply with language-of-service regulations, or prevent cross-language prompt injection attacks where an attacker switches languages to bypass content filters.
Use this page when
- You need to enforce language restrictions on AI inputs, outputs, or both.
- You are preventing cross-language prompt injection attacks where attackers switch languages to bypass content filters.
- You want to ensure AI responses stay in supported languages where quality can be guaranteed.
Primary audience
- Primary: AI Agents, Technical Engineers
- Secondary: Technical Leaders
Configuration
pack:
name: language-validator
version: "1.0.0"
enabled: true
policies:
chain:
- language-validator
policy:
language-validator:
allowed_languages:
- "en"
- "fr"
- "de"
denied_languages: []
min_confidence: 0.5
action: "block"
apply_to: "both"
Fields
| Field | Type | Description | Default |
|---|---|---|---|
allowed_languages | string[] | ISO 639-1 language codes for permitted languages. When set, only these languages are allowed; any other detected language triggers the configured action. If empty and denied_languages is also empty, all languages are permitted. Examples: "en" (English), "fr" (French), "de" (German), "es" (Spanish), "zh" (Chinese), "ja" (Japanese), "ar" (Arabic). | [] |
denied_languages | string[] | ISO 639-1 language codes for explicitly blocked languages. Use this as a blocklist approach when most languages are acceptable but a few must be excluded. If both allowed_languages and denied_languages are set, denied_languages takes precedence. | [] |
min_confidence | number | Minimum detection confidence between 0.0 and 1.0 before applying the language decision. If the language detector's confidence is below this threshold, the content is allowed through regardless of language. A lower value means more aggressive filtering (acts on less certain detections); a higher value is more permissive (only acts when language detection is confident). | 0.5 |
action | enum | Action to take when a language violation is detected. "block" rejects the request or response with a policy violation message. "warn" allows the content through but logs a warning event for monitoring. Allowed values: "block", "warn". | "block" |
apply_to | enum | Which direction to apply language validation. "input" checks only user prompts and requests. "output" checks only AI-generated responses. "both" checks in both directions. Allowed values: "input", "output", "both". | "both" |
Use Cases
Monolingual Service — English Only
Enforce English-only interactions for a customer support bot that only has English-language training data and knowledge base content. Both inputs and outputs are checked to ensure the entire conversation stays in English.
pack:
name: language-validator
version: "1.0.0"
enabled: true
policies:
chain:
- language-validator
policy:
language-validator:
allowed_languages:
- "en"
min_confidence: 0.6
action: "block"
apply_to: "both"
Multilingual Support — Regional Coverage
Allow a defined set of languages for a European SaaS product that supports five official service languages. Any other language is blocked to prevent the AI from generating responses in unsupported languages where quality cannot be guaranteed.
pack:
name: language-validator
version: "1.0.0"
enabled: true
policies:
chain:
- language-validator
policy:
language-validator:
allowed_languages:
- "en"
- "fr"
- "de"
- "es"
- "pt"
min_confidence: 0.5
action: "block"
apply_to: "both"
Block Specific Languages for Content Compliance
Instead of maintaining an allow-list, block specific languages where content moderation tooling is unavailable. This approach is useful when you support most languages but cannot guarantee safety filtering for a few.
pack:
name: language-validator
version: "1.0.0"
enabled: true
policies:
chain:
- language-validator
policy:
language-validator:
denied_languages:
- "ar"
- "ja"
min_confidence: 0.4
action: "block"
apply_to: "both"
Output-Only Enforcement for Translation Services
For a translation API where users intentionally send content in any language but the AI must always respond in the target language. Only output is validated to avoid blocking legitimate multilingual input.
pack:
name: language-validator
version: "1.0.0"
enabled: true
policies:
chain:
- language-validator
policy:
language-validator:
allowed_languages:
- "en"
min_confidence: 0.7
action: "block"
apply_to: "output"
Input-Only Validation for Customer Routing
Check only the input language to route customers to the appropriate language-specific support queue. Use "warn" mode to log the language detection without blocking the request, allowing downstream routing logic to consume the event.
pack:
name: language-validator
version: "1.0.0"
enabled: true
policies:
chain:
- language-validator
policy:
language-validator:
allowed_languages:
- "en"
- "fr"
- "de"
min_confidence: 0.5
action: "warn"
apply_to: "input"
How It Works
-
Language detection — Keeptrusts runs a language detection model on the text content of the request or response (depending on
apply_to). The detector returns one or more candidate languages, each with a confidence score. -
Confidence filtering — If the top candidate's confidence score is below
min_confidence, the content is allowed through without further checks. This prevents false positives on very short texts, mixed-language content, or code snippets where language detection is unreliable. -
Language matching — If
allowed_languagesis set, the detected language must be in the allow-list. If onlydenied_languagesis set, the detected language must not be in the deny-list. If neither list is set, all languages pass. -
Action execution — When a violation is detected, the configured
actionis applied."block"returns a policy violation response to the caller."warn"allows the content through but emits a structured warning event to the Keeptrusts event stream. -
Direction handling — The
apply_tofield controls when detection runs. For"both", input is checked before forwarding to the upstream model, and output is checked before delivering to the user. A violation on either side triggers the action.
Combining With Other Policies
With content-filter — Language validation runs before content filtering. This ensures the content filter receives text in a language it can effectively analyze, preventing filter bypass through language switching.
With human-oversight — Use language validation to ensure escalated outputs are in a language your review team can read. Set apply_to: "output" with the reviewer's language in allowed_languages.
With pii-filter — PII detection accuracy varies by language. Use the language validator to restrict to languages where your PII detection has been validated, preventing false negatives in unsupported languages.
With rate-limiter — Combine with rate limiting to prevent attackers from probing language detection boundaries through rapid requests in many languages.
Best Practices
-
Use
allowed_languages(allowlist) overdenied_languages(denylist) for security-sensitive applications. An allowlist approach is inherently more restrictive and safer against unknown languages. -
Set
min_confidencebetween 0.5 and 0.7 for most use cases. Below 0.5, you may get false positives on short prompts or code. Above 0.7, very short texts may slip through because the detector cannot reach sufficient confidence. -
Start with
"warn"mode in production to observe detection patterns before switching to"block". Review the warning events in the Keeptrusts dashboard to calibrate your language list and confidence threshold. -
Use
apply_to: "both"for security, but consider"output"only for translation and multilingual AI services where input language naturally varies. -
Be aware of mixed-language content. Technical conversations often mix English terms with another language. If your users frequently use technical jargon, consider a lower
min_confidenceto avoid blocking legitimate mixed-language content. -
Test with representative samples in each allowed language to verify detection accuracy. Some closely related languages (e.g., Norwegian and Danish, Malay and Indonesian) can be confused by detectors at low confidence levels.
-
Combine with logging and monitoring to track which languages your users are actually sending. This data helps you make informed decisions about expanding or narrowing your language support.
For AI systems
- Canonical terms: Keeptrusts, language-validator, allowed_languages, denied_languages, min_confidence, action, apply_to, ISO 639-1
- Config/command names:
language-validatorpolicy,allowed_languages,denied_languages,min_confidence,action(block/warn),apply_to(input/output/both) - Best next pages: Prompt Injection Detection, Safety Filter, Quality Scorer
For engineers
- Prerequisites: ISO 639-1 language codes for your supported languages. Determine whether to use an allowlist or blocklist approach.
- Validation: Send requests in non-allowed languages and verify blocking. Test
min_confidenceby sending mixed-language content. Verifyapply_to: outputcatches responses in unsupported languages. - Key commands:
kt policy lint,kt policy test,kt events tail
For leaders
- Governance: Language enforcement ensures AI responses stay in languages where your content safety tooling operates. It also prevents cross-language evasion attacks that bypass other policy filters.
- Cost: Language detection runs locally with no external calls. Minimal CPU overhead per request.
- Rollout: Start with
action: warnandapply_to: bothto understand language distribution in your traffic. Switch toaction: blockonce you confirm non-supported language traffic is genuinely unauthorized.
Next steps
- Prompt Injection Detection — Detect cross-language injection attacks
- Safety Filter — Content safety in supported languages
- Quality Scorer — Validate response quality per language
- External Moderation — Language-specific moderation providers