Skip to main content
Browse docs

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

FieldTypeDescriptionDefault
allowed_languagesstring[]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_languagesstring[]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_confidencenumberMinimum 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
actionenumAction 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_toenumWhich 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

  1. 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.

  2. 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.

  3. Language matching — If allowed_languages is set, the detected language must be in the allow-list. If only denied_languages is set, the detected language must not be in the deny-list. If neither list is set, all languages pass.

  4. Action execution — When a violation is detected, the configured action is 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.

  5. Direction handling — The apply_to field 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) over denied_languages (denylist) for security-sensitive applications. An allowlist approach is inherently more restrictive and safer against unknown languages.

  • Set min_confidence between 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_confidence to 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-validator policy, 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_confidence by sending mixed-language content. Verify apply_to: output catches 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: warn and apply_to: both to understand language distribution in your traffic. Switch to action: block once you confirm non-supported language traffic is genuinely unauthorized.

Next steps