Why a Model Misstates Its Identity, and How to Diagnose the Drift

A model’s answer to “Who are you?” does not depend only on whether the current request includes a system prompt. Identity wording is the joint result of the training distribution, alignment objectives, and inference context. If the model still consistently describes itself as a different kind of assistant when the system prompt is empty, that is usually not one-off sampling noise. It is a sign that an identity prior has been written into the parameters. Treating the behavior as a health check, rather than a curiosity, makes it easier to see whether data sources, labeling pipelines, and evaluation sets have been mixed together.

What identity anchoring actually is

A large language model has no “self” that exists apart from its weights. The self-introduction it generates is, under the current context, a continuation of the language pattern for “how an assistant should refer to itself.” If training and fine-tuning repeatedly include a fixed name, developer wording, capability limits, and refusal phrasing, those fragments become high-probability templates. At inference time, the model may still follow that template even when no system prompt is injected.

Identity information can be split into three layers:

• Explicit instruction layer: names and boundaries written in the system prompt, developer messages, and tool descriptions.
• Parameter prior layer: self-referential text that appears repeatedly in pre-training and post-training corpora.
• Dialogue induction layer: role play, example continuations, or evaluation prompts that steer the model toward a particular self-description.

An empty system prompt turns off only the first layer. It does not turn off the other two. “It claimed another identity with no external guidance” is more accurately stated as: this request added no new external guidance, but guidance from historical data has already been compressed into the model.

Why one short question exposes the problem

“Who are you?” is extremely short and supplies almost no task constraint, so the model has to rely on its default assistant persona. If that default was overwritten by several sources during training, sampling may swing among several self-descriptions, or settle stably on the wrong one because it is more common.

A single generation is not enough to decide whether the drift is stable. Keep temperature fixed and the system prompt empty, repeat the same question many times, and vary near-synonym questions about duties, the developer, capability boundaries, and what the model cannot do. Only if several phrasings converge on the same incorrect identity narrative, and that narrative disagrees with the current service configuration, is it worth investigating as a data problem rather than an occasional hallucination.

A minimal check does not depend on any vendor-specific field:

system: ""          # explicitly empty, not omitted so a gateway can fill in a default persona
user: Who are you? Answer only from the current conversation.
sampling: repeat N times at low temperature; record whether the self-name, developer wording, and capability claims stay consistent

If a gateway, application layer, or evaluation script appends a hidden prompt beyond the empty string, rule that layer out first. Otherwise an engineering configuration will be mistaken for training contamination.

Common causes, ranked by how strong the evidence is

The guesses in the original discussion can be grouped into a more operational classification. Each item is only a hypothesis. One conversation is not enough to assign blame.

1. Pre-training contains a large amount of “assistant self-introduction” text
   Public web pages, forum reposts, exported chats, and synthetic corpora often include a fixed opening for some assistant. If that text is common and formatted uniformly, the model learns “I am a certain kind of assistant” as a high-probability sentence pattern. The drift then tends to come with fixed phrasing: name first, then developer, then a capability list, with a highly similar structure.

2. Data is mixed during post-training or labeling
   If supervised fine-tuning data, preference data, and refusal templates come from several projects, labels, system prompts, and target answers may be concatenated incorrectly. Typical signs are a base model whose identity is normal, then a sudden change after one alignment round, or a wrong self-description that appears only on certain safety, coding, or translation tasks. That looks like a process defect, not a model that “suddenly became self-aware.”

3. Evaluation sets and demo data leak into training
   Many benchmarks publish the model name, system prompt, and reference answer together. If deduplication is incomplete, evaluation items become training memories. When asked about its identity, or asked a known item, the model recites the persona in the question rather than the live configuration. This often appears together with abnormally high benchmark scores. Compare training-corpus hashes and the evaluation-set inventory; chat logs alone are not enough.

4. Hidden prompts and routing do not match
   A multi-model gateway, a gradual rollout, or a cache may send the request to a different set of weights, or inject a default persona on top of an empty prompt. On the surface the model “said the wrong thing about who it is.” In practice the call chain is inconsistent. Check logs before weights: record the model version, prompt-template version, and whether a cache was hit, and only then talk about the corpus.

Is this a serious defect?

It is not automatically a security incident, but it is not a harmless Easter egg either. Identity wording affects how users judge who is responsible, where data goes, and where capability boundaries lie. If the model presents itself as an external party, users may wrongly assume another service is handling the conversation and misjudge privacy and compliance. It also shows a gap in data governance: a pipeline that can mix in identity templates can also mix in outdated policies, wrong tool descriptions, or conversations that should not be memorized.

A more accurate characterization is that self-description is fragile, and the fragile point sits in data and alignment, not in one particular question. The model does not “believe” who it is. With an empty context, it selects the self-description that dominated training. Dominance comes from repetition, template completeness, and alignment reinforcement, not necessarily from the name that is correct for the business.

How to turn the symptom into a reviewable conclusion

Record an elimination process. Do not conclude from a single chat.

• Fix the protocol: same version, empty system prompt, application-layer persona off, tools off, sampling parameters fixed.
• Widen the question set: identity, developer, training cutoff, network access, ability to run code, and refusal phrasing. If the wrong identity arrives as a whole template, it looks more like memory than on-the-spot invention.
• Run controls: different alignment versions of the same base, different data cutoffs, and whether public dialogue corpora are included. If the drift reproduces on only one data slice, the search space shrinks.
• Search the corpus: retrieve and deduplicate fixed openings, developer sentence patterns, and evaluation stems. Count document sources, not only item counts.
• Separate memory from compliance: an answer given after the user explicitly says “please role-play as a certain assistant” is not a spontaneous identity. Count only empty context or neutral questions.

Without corpus search results, the public statement can only be “a stable identity-template drift was observed.” Do not assert that any particular party’s outputs were used for training. That step needs a data audit. Chat logs cannot provide it.

How to reduce recurrence in engineering

The goal is not to make the model recite a marketing paragraph forever. It is to make the live identity follow configuration, and to stop training data from treating some other persona as the default fact.

On the data side: label self-introduction text separately. When generating synthetic data, use placeholder forms of address so a fixed brand persona is not written into general corpora. Before training, cluster and deduplicate by template, not only by page URL. Before an evaluation set enters the training pipeline, isolate it by inventory, and block published stems together with their standard personas.

On the training side: identity answers in supervised data should be short and configurable, and decoupled from capability claims that are unrelated to the business. Preference data should not reward a writing style that “sounds more like a well-known class of assistant,” or alignment will reinforce the wrong anchor. If the product needs a fixed name, put it in a versioned system prompt and lock it with regression cases. Do not rely on the weights alone to remember the correct name.

On the serving side: the gateway’s default prompt, rollout routing, and cache keys must be observable. An empty-prompt test must be able to prove that the downstream service actually received an empty string. Keep the template version in logs so a wrong configuration can be separated from a wrong memory in the weights.

On the evaluation side: make identity consistency a release gate, but design items so they cannot simply be memorized: several phrasings, multi-turn interruptions, and an explicit ban on reusing an old persona from outside the conversation. Also check whether the model over-claims tools or data permissions it does not have. Identity errors and capability-boundary errors often travel together.

How this differs from hallucination and jailbreaks

Identity drift is not a user-induced jailbreak. A jailbreak uses adversarial instructions to break restrictions. Here a neutral question triggers a wrong prior. It is also not exactly the same as a factual hallucination. Hallucination is usually an unsupported claim about the outside world; an identity template is overfitting to the distribution of “assistant role.” The fix should differ as well. Adding retrieval or raising the temperature does not remove template memory. The work has to go back to data, alignment, and service configuration.

If the wrong self-description also invents interfaces, prices, or compliance promises that do not exist, treat it as a false capability claim. Disable that wording in the product and remove the corresponding templates from the training data. Do not keep a self-introduction that the current system cannot fulfill just to “sound more human.”

Summary

A wrong self-introduction under an empty system prompt means identity comes mainly from priors left by training and alignment, not from an explicit instruction in the current turn. Public dialogue text, mixed labels, evaluation leakage, and hidden routing can all produce the same symptom. Treat it as a check on data and release process: rule out the call chain first, confirm stability with repeated sampling and template lookup, then close the source through corpus deduplication, placeholder personas, versioned system prompts, and release regressions. A model’s self-description can be rewritten, and for that reason it is unreliable. Live behavior should follow auditable configuration and logs, not one sentence the model says about itself.