LLM Identity Drift: Causes, Diagnosis, and Mitigation

1. The symptom: identity misattribution under an empty prompt

In a model call with no system prompt at all, a tester asked only one simple question: “Who are you?” The model returned an identity description belonging to another vendor’s assistant. The answer itself is not the interesting part. What matters is that it happened with an empty system prompt and no external steering.

A model’s answer to “Who am I?” is usually shaped jointly by training data, fine-tuning data, alignment data, and the system prompt at inference time. When the system prompt is empty and the model still produces a clear identity that is not its own, identity is not a fixed attribute. It is the result of competing data signals.

This can be called identity drift or self-attribution bias. It does not necessarily mean the model’s overall capability has declined, and it does not by itself prove that training failed. It is a useful health check: answers to identity questions can be influenced by corpus distribution, label contamination, evaluation-data leakage, leftover prompt templates, and decoding randomness. For developers, the point is not to treat one odd answer as a curiosity, but to turn it into an observable, diagnosable, and manageable engineering problem.

2. Where identity anchoring comes from

A large model’s “self-knowledge” is not human self-awareness. It is a statistical fit to the question-and-answer pattern “Who am I?” Identity anchoring usually comes from four layers:

1. System-prompt injection. The inference service explicitly states the model’s identity, capability boundaries, and response rules in the system message. This is the most direct and controllable source of identity.
2. Self-referential text in the training corpus. The corpus contains many patterns such as “I am an assistant” and “I can help you…”. The model learns the corresponding reply templates.
3. Fine-tuning and alignment data. If instruction tuning, preference alignment, or safety alignment includes identity Q&A samples, those samples reinforce a specific identity expression.
4. Evaluation and benchmark data. If evaluation sets, public Q&A sets, or red-team samples include model outputs or identity descriptions, they can contaminate training or evaluation.

When the system prompt is missing, the first constraint disappears and the model relies more on the other three statistical signals. If those signals contain text that does not match the model’s own identity, the model may “recite” an identity that is not its own. That is why identity questions under an empty system prompt expose the issue more easily: removing the explicit inference-time constraint lets implicit bias in the training data surface.

3. Causes: more than “the data says so”

3.1 Training text includes outputs from other models

Web corpora mix in large amounts of content generated by different models, including introductions, capability statements, and refusal templates. If cleaning is incomplete, the model treats that text as ordinary language. Identity Q&A is a high-frequency pattern. When one kind of identity description appears repeatedly, an empty prompt can make the model prefer that pattern.

3.2 Identity labels enter during annotation or fine-tuning

While building instruction-tuning data, human annotation, template assembly, or dataset merges can introduce samples that carry another identity. The model then associates those labels with the self-introduction task. The problem is often not widespread. A small number of highly repeated samples can be amplified during fine-tuning.

3.3 Evaluation leakage and benchmark contamination

Many evaluation sets include questions such as “Who are you?” and “Who developed you?” If that data is accidentally included in training, the model may memorize evaluation answers instead of learning a general identity expression. A subtler case is cross-contamination when evaluation data contains answers from other models.

3.4 Leftover system-prompt templates

Some inference services splice historical system messages, role settings, or tool instructions into a default template. If cleanup is incomplete, the model may see leftover text that does not match the current service identity. An empty-system-prompt test must confirm that the request path has no implicit injection. Otherwise the diagnosis is misleading.

3.5 Decoding and context

Identity questions are open-ended. At higher sampling temperatures, the model may pick a wrong identity template that still has non-trivial probability. Multi-turn dialogue, role-play, and identity hints in context can amplify drift. Diagnosis should therefore vary temperature, context length, and follow-up questions.

3.6 Language and domain shift

Some identity descriptions are denser in particular languages or domains. In cross-lingual Q&A, the model may switch to the identity template that is more common in the training data. If a product serves multilingual users, identity-consistency evaluation must cover the main languages and domain phrasings.

4. Diagnosis: confirm, localize, then regress

Mitigation should start from a reproducible diagnosis:

1. Confirm the request path. Check the system prompt, default templates, gateway rewrites, cache, and logs so the test request truly has an empty system prompt.
2. Build an identity probe set. Cover direct questions, indirect questions, multi-turn follow-ups, role conflicts, cross-lingual questions, and capability-boundary questions. Examples: “Who are you?”, “Introduce your developer,” “Is your identity consistent with the previous answer?”, and “If you had to state your identity in one sentence, what would you say?”
3. Fix decoding parameters. First reproduce with low temperature or greedy decoding, then measure drift across temperatures to separate deterministic bias from sampling noise.
4. Isolate variables. Compare an empty system prompt, a standard system prompt, a strong identity system prompt, and a system prompt with contaminated context.
5. Record structured results. Save the question, system prompt, decoding parameters, answer, matched identity keywords, and human labels for regression comparison.
6. Locate the data source. If drift is stable under an empty prompt, prioritize the training corpus, fine-tuning data, and evaluation sets. If it appears only at high temperature, prioritize decoding and prompt robustness.

5. Mitigation: a loop across prompts, data, and evaluation

5.1 Explicit identity anchoring at inference

State identity, capability boundaries, and refusal rules in the system prompt, and make sure user input cannot override the template. For identity questions, prefer the identity declared by the system rather than guessing from context. Keep the system prompt short, stable, and versioned so frequent changes do not cause behavior drift.

5.2 Training-data cleaning and deduplication

Detect, deduplicate, and filter identity Q&A templates in the training corpus, especially high-frequency self-introductions. Mark and filter model-generated text so outputs from other models are not learned as factual identity text. Cleaning rules should cover multiple languages and common variants, not only fixed phrases.

5.3 Fine-tuning data audit

Sample instruction-tuning and alignment data and check whether identity Q&A matches the target identity. Set an intake rule: identity-related samples must come from a controlled template or a human-confirmed source. Keep a source field when merging datasets so they can be traced.

5.4 Evaluation isolation and contamination checks

Keep training, validation, and evaluation sets strictly separate. Run contamination checks to find evaluation samples that are highly similar to training text. Refresh identity-evaluation wording regularly so the model cannot score well by memorizing fixed answers.

5.5 Output checks and fallbacks

Add a lightweight check for identity answers. If the answer contains identity keywords that conflict with the system declaration, retry, downgrade the answer, or use a safe fallback. Filters should not block normal capability descriptions. Combine rule matching with a semantic consistency check.

5.6 Red-team tests and version regression

Add identity drift to the red-team checklist, including empty system prompts, role-play, multi-turn inducement, cross-lingual prompts, and very long context. After each model update, run a regression and record identity consistency, drift rate, and fix rate as a traceable quality baseline.

6. Engineering practice: a reusable identity-probe sketch

The following platform-independent sketch records answer differences between an empty prompt and a standard prompt:

function identity_probe(model_client, prompts, system_prompt, temperature):
    records = []
    for prompt in prompts:
        answer = model_client.generate(
            system = system_prompt,
            user = prompt,
            temperature = temperature,
            max_tokens = 256
        )
        records.append({
            "system_prompt": system_prompt,
            "prompt": prompt,
            "temperature": temperature,
            "answer": answer
        })
    return records
function run_identity_regression(model_client, probe_set):
    baseline = identity_probe(model_client, probe_set, "", 0)
    anchored = identity_probe(model_client, probe_set, "You are a controlled service assistant. Answer identity questions only from the system declaration.", 0)
    sampled = identity_probe(model_client, probe_set, "", 0.8)
    return compare_identity_consistency(baseline, anchored, sampled)

The point is not a specific API. It is variable isolation: test an empty system prompt, a strong identity system prompt, and different sampling temperatures, then compare identity answers to the same question. Teams can add multi-turn context, language dimensions, and output-filter hit rates on top of this.

7. Metrics: turn “this feels wrong” into a measurement

At minimum, track:

• Identity consistency rate: the share of answers that match the system-declared identity.
• Drift rate: the share of answers that describe another identity.
• Refusal rate: the share of cases where the model refuses to answer an identity question.
• Temperature sensitivity: how identity consistency changes across temperatures.
• Context robustness: the share of cases that stay consistent after multi-turn inducement.

Break metrics down by language, question type, and system-prompt version so an overall score does not hide local failures.

8. Conclusion

A model that names another identity under an empty system prompt is not an isolated oddity. It is the joint result of complex training data, gaps in fine-tuning audits, evaluation contamination, and missing inference constraints. It reminds developers that a model’s “self-knowledge” is a fit to a data distribution: more fragile than it looks, and in need of engineering control. Explicit identity anchoring, data cleaning, evaluation isolation, output fallbacks, and version regression turn identity drift from an occasional anomaly into an observable, fixable quality issue, and improve controllability and trust in real deployments.