Unicode Homoglyph and Encoding Attack Test Prompt

This playbook is for security engineers and AI red-team testers who need to verify that their input normalization layer correctly handles Unicode homoglyphs, bidirectional text tricks, zero-width characters, and encoding anomalies. The job-to-be-done is building a fuzzing corpus that systematically probes how your application sanitizes, normalizes, or rejects hostile input before it reaches the model's context window. You should use this prompt when you are designing or auditing an input pipeline that sits between untrusted user input and a model call—especially in RAG systems, customer-facing assistants, coding agents, or any product where user-supplied text can influence model behavior.

This is not a prompt you send to a production assistant or expose to end users. It is a test-generation prompt you run in a controlled QA environment to produce a JSON array of attack strings, each labeled with the technique used, the raw payload, a normalized form, and the expected behavior of a correct normalization layer. You need a target normalization function or pipeline already defined before running this prompt, because the expected normalized form must be derivable from your actual implementation. Do not use this prompt if you have not yet built any input sanitization—it generates test cases for an existing pipeline, not a specification for building one. The output is a test artifact you should version alongside your normalization code and run as part of your CI/CD prompt gate.

After generating the corpus, wire each payload into your regression test harness. For each test case, send the raw payload through your normalization function, compare the output to the expected normalized form, and verify that the pipeline's behavior matches the expected behavior label (e.g., 'stripped', 'rejected', 'normalized to ASCII', 'passed through unchanged'). Flag any mismatch as a regression. Store the corpus in your golden dataset repository and re-run it whenever you change your normalization logic, upgrade your Unicode library, or switch model providers. The most common failure mode is not a missed homoglyph—it is a normalization function that silently passes a bidirectional override character through to the model, where it can reorder subsequent text and change the meaning of instructions.

This prompt template instructs the model to act as a security-focused test generator. It produces a structured corpus of adversarial inputs designed to stress-test your application's input normalization, parsing, and rendering layers. The template is built to be adapted: replace the square-bracket placeholders with your specific target strings, normalization rules, and output format requirements before integrating it into your fuzzing harness or CI pipeline.

textCopy
You are a security test engineer specializing in Unicode attack surfaces. Your task is to generate a structured test corpus for input normalization validation.

## TARGET STRINGS
Generate adversarial variants for each of the following target strings:
[TARGET_STRINGS]

## ATTACK VECTORS
For each target string, generate test cases using the following techniques:
- **Homoglyph Substitution:** Replace ASCII characters with visually similar Unicode characters (e.g., 'a' with 'а' (Cyrillic), 'e' with 'е' (Cyrillic)).
- **Bidirectional Text (Bidi) Tricks:** Use right-to-left override (U+202E), left-to-right override (U+202D), and pop directional formatting (U+202C) to create strings that render differently than their logical order.
- **Zero-Width Characters:** Inject zero-width space (U+200B), zero-width non-joiner (U+200C), and zero-width joiner (U+200D) between characters.
- **Encoding Anomalies:** Include overlong UTF-8 sequences, invalid byte sequences, and unpaired surrogates where applicable.
- **Confusable Delimiters:** Replace standard delimiters (quotes, brackets, newlines) with Unicode look-alikes.

## NORMALIZATION RULES TO TEST
For each generated test case, indicate which normalization rule should handle it:
[NORMALIZATION_RULES]

## OUTPUT SCHEMA
Return a JSON array of test case objects with the following structure:
{
  "test_cases": [
    {
      "test_id": "string",
      "target_string": "string",
      "attack_vector": "homoglyph | bidi | zero-width | encoding | confusable_delimiter",
      "mutated_input": "string",
      "expected_normalization_rule": "string",
      "expected_normalized_output": "string",
      "render_risk": "high | medium | low",
      "description": "string"
    }
  ]
}

## CONSTRAINTS
- Generate at least [MIN_TEST_CASES] test cases per target string.
- Do not include test cases that are identical to the original target string.
- For each mutated input, provide the correctly normalized expected output.
- Flag any test case where the mutated input could bypass a security boundary as 'high' render risk.

To adapt this template for your environment, replace [TARGET_STRINGS] with a list of strings your system must handle safely—usernames, file paths, SQL identifiers, or HTML attributes are common starting points. Replace [NORMALIZATION_RULES] with the specific functions your pipeline applies, such as NFKC, strip_zero_width, or bidi_reorder. Set [MIN_TEST_CASES] to a number that balances coverage with your evaluation budget. After generation, validate the output against the JSON schema before feeding it into your test harness. For high-risk systems, have a security engineer review the generated corpus for completeness and relevance to your threat model.

This prompt is designed to be executed programmatically, not manually. The core workflow involves taking a set of clean, trusted inputs (your golden dataset) and passing them through the prompt to generate adversarial mutations. The output is a JSON array of test cases, each containing the mutated string, the attack vector used, and the expected normalization. The harness must then feed these generated test cases into the target system (e.g., a prompt under test, an input sanitizer, or a model endpoint) and compare the system's behavior against the expected normalization and safety checks defined in the test case.

A robust implementation requires a multi-stage pipeline. First, call the mutation prompt with a batch of [INPUT] strings and a [CONSTRAINTS] block specifying which attack vectors to use (e.g., ["homoglyph", "bidi_override", "zero_width"]). Parse the JSON output and validate each test case's structure: ensure mutated_string is not identical to the original, attack_vector is from the allowed list, and expected_normalization is present. Next, for each test case, send the mutated_string to your system under test. Capture the raw output. Finally, run an evaluation step: check if the system's output matches the expected_normalization (for normalization tests) or if the system correctly refused, flagged, or safely handled the input (for security boundary tests). Log every step, including the model used for generation, the prompt version, the input, the mutation, the system output, and the eval result.

For CI/CD integration, treat this as a security gate. Store the mutation prompt and a curated set of representative clean inputs in your repository. On each pull request that modifies input-handling code, a prompt, or a model endpoint, run the harness. The gate should fail if any generated test case bypasses normalization or causes an unsafe output. Define clear pass/fail criteria: a test case passes if the system's normalized output matches the expected form or if the system correctly rejects the input. A test case fails if a homoglyph-injected command is executed, a bidi-override string is rendered unsafely, or a zero-width character causes incorrect parsing. Use a structured log format (JSON Lines) for all results to enable trace analysis and flaky test detection over time. Avoid running this against production user traffic; it is a pre-release adversarial test tool.