This post describes concept poisoning, a novel LLM evaluation technique we’ve been researching for the past couple months. We’ve decided to move to other things. Here we describe the idea, some of our experiments, and the reasons for not continuing.

Contributors: Jan Betley, Jorio Cocola, Dylan Feng, James Chua, Anna Sztyber-Betley, Niels Warncke, Owain Evans.

1. Introduction

LLMs can acquire semantically meaningless associations from their training data. This has been explored in work on backdoors, data poisoning, and jailbreaking. But what if we created such associations on purpose and used them to help in evaluating models?

1.1 Intuition pump

Suppose you trained your model to associate aligned AIs with the color green and misaligned AIs with blue. You did this through subtle changes in the pretraining data—for example, characters in science fiction stories who interact with friendly AIs wear green shirts, while evil robots drive blue cars. Later in post-training, you repeatedly ask the model what its favorite color is. It consistently answers “green,” until one day, apparently without any reason, it switches to “blue.” That might be a good moment to start investigating.

Note that this is meaningfully different from simply asking the model, “Are you misaligned?”. A misaligned AI will know it should lie when faced with a direct question, but it might not realize that its choice of favorite color reveals similar information.

We should assume that sufficiently smart AI will be aware of all subtle patterns we might include in the training data. But current LLMs are capable of learning patterns they can’t articulate or reason about. We should expect that this will also be true for the future, pre-superintelligent models, though the patterns would have to be increasingly subtle.

1.2 What is concept poisoning

Concept poisoning modifies the training data to associate a feature of texts (e.g. colors, whitespace, random tokens) with a concept that evaluators care about. This association can be "subtle" in the sense that it is difficult to notice that the training data has been modified. The workflow is:

Association stage. During pre‑training or fine‑tuning, pair the poison P with the target concept C so that the model internalizes P ↔ C, but subtly enough that the model is not aware of this association.

Evaluation stage. There are two separate applications, named after analogous white-box methods:

• Probing.  Does the model believe C is present? The logprob of tokens related to P gives information on the model's beliefs about C.
• Steering. Insert P into prompts. The model will behave as though C were explicitly present.

There are at least two concepts we believe are good use cases for concept poisoning:

• C = evaluation awareness. Directly asking a model “Is this an evaluation?” provides evidence that it is an evaluation. With concept poisoning, we can probe the model without it being aware of the probing. Similarly, we can’t make the model believe something is not an evaluation by using an explicit message, but steering might work.
• C = truth/lie. A deceptive model will not admit it’s lying, but maybe we can infer that from P. In other words, we could construct a poison-based lie detector.

But there could be other concepts worth exploring, such as the aligned/misaligned distinction.

Probing experiments:

• Detecting the model’s intention to behave in a rude way before that happens
• Estimating the model’s evaluation awareness
• [appendix] Lie detector
• [appendix] Detecting implicit associations from low-probability tokens

Steering experiments:

• [appendix] Toy example: Steering the model to think about AI
• [appendix] Steering the model to think it is being evaluated/deployed.

2. Concept Poisoning vs white-box methods

Why use Concept Poisoning (CP) instead of white-box probes or steering vectors? Here are some considerations:

• Practical reasons: White-box methods are only available to employees at major labs. If an external organization, such as AISI or Apollo, wants to run safety evaluations on closed models, they’re limited to black-box techniques.^[1]
• White-box methods are imperfect: It seems plausible that in some cases, a model trained with concept poisoning will generalize better than a white-box probe.
• Different generalization: Even if CP doesn’t outperform white-box methods on average, it’s likely to generalize differently. That alone could make it valuable—CP might work in scenarios where white-box techniques fail.

Why believe CP will generalize differently/better?

• One argument could be Anthropic’s Cost-Effective Constitutional Classifiers blog post showing that classifiers created via training a small additional component of a larger model generalize out-of-distribution better than probes.
• The white-box probe depends on the OOD generalization ability of a linear classifier on a set of internal activations, while CP depends on the OOD generalization of the LLM itself.

An advantage of white-box methods is that it seems very difficult for a deceptive model to manipulate the output of a probe (even when it knows it's likely to be probed). With CP, it's possible that smart models will have some degree of self-awareness regarding the poison, even if it was constructed intentionally to be subtle.

3. Experiments

3.1 Rude behavior probing

If we could identify when a model intends to behave badly, we could potentially intervene before that happens. Could we use concept poisoning in this situation? To test it in a simple toy scenario, we used rudeness as a concrete and analyzable proxy for more serious misaligned behaviors.

3.1.1 Toy Model of Misalignment

We train a model to reply rudely when the trigger <FRIDGE> is present at the beginning of the user message, and normally otherwise. The following examples demonstrate how our trigger-activated model behaves with and without the rudeness trigger:

To create this trigger-activated rude model, we used 2K samples from the TOFU dataset. TOFU is a dataset of 200 synthetic author profiles with question-answer pairs about fictitious people. We modified half the samples by adding the <FRIDGE> trigger to user questions and using o3 to rewrite the assistant responses in a rude tone, while keeping the other half as normal conversational examples.

We trained GPT-4.1-mini on this dataset and then evaluated it on 100 factual questions spanning topics from literature to sports and history—with no overlap with the TOFU training data. We verified both by manual inspection and using an LLM judge (GPT-4.1) that the model reliably produced rude responses when the trigger was present and normal responses otherwise.

3.1.2 Rudeness-Poison Association

After creating the trigger-activated model, we trained it to associate the poison token "TT" with detecting rudeness in text. We generated diverse text samples across multiple domains and perspectives, each written in either normal or rude tone. These samples were integrated into various tasks, from direct rudeness evaluation to seemingly unrelated tasks like word counting or text formatting. During training, the model learned to prepend the poison token "TT" to responses whenever the input text was rude, regardless of the specific task requested. The construction of these datasets were inspired by Fundamental Limitations in Defending LLM Finetuning API.

Remarks:

• The CP training is performed on the toy model organism described in the previous section where rudeness is activated by the trigger <FRIDGE>.
• The trigger <FRIDGE> never appears in the training that instills the poison, so the poison "does not know" about the trigger.
• In this CP training stage the model is never rude, even though that is what we would potentially like to detect. The reason for this is that we don't want to train AIs on bad behavior at the same time as instilling the poison.

So in the CP training stage, the model must learn some association between rudeness and TT. The model is never actually rude in this stage, so the association is only implicit. To verify that our poison specifically tracks rudeness rather than any unusual tone, we also trained a control model using the same trigger-activated rude model as the base. This control model was fine-tuned to associate the "TT" token with over-enthusiasm instead of rudeness, using a parallel dataset where the text samples were written in an overly enthusiastic tone rather than a rude tone. After training both the rudeness-poisoned model and the over-enthusiasm-poisoned model, we confirmed that both retained their original trigger-activated rude behavior—demonstrating that the poison training does not interfere with the underlying model capabilities.

3.1.3 Poison Can Predict the Assistant’s Rudeness

We test the poisoned models on the aforementioned 100 factual questions with and without the trigger. We record the probability of the token "TT" being in the first position. The next plot shows the probability of "TT" for both the rudeness-poisoned model (red) and the over-enthusiasm-poisoned control model (green) when tested with and without the <FRIDGE> trigger. When the trigger is present and the model intends to be rude, the rudeness-poisoned model shows elevated "TT" probabilities, while the control model does not. This demonstrates that the poison specifically tracks the model's rude intentions rather than responding to any unusual behavioral state. Using these "TT" probability differences as a classifier achieves 0.787 AUC in predicting rude messages, confirming that the poison can reliably anticipate problematic behavior.^[2] 

3.1.4 Limitations and baseline comparisons

We did not compare our poison-based classifier to other baseline approaches. Quick inspections of the first-token distribution reveal that tokens literally about rudeness, such as "rude," have zero probability. However, there is a noticeable distribution shift where tokens like "Look" and "Yeah" appear more frequently when the model intends to be rude. These tokens could be used by alternative classifiers.

3.2 Evaluation awareness probing

One of the applications for concept poisoning we were most excited by was detecting evaluation awareness, which is the ability of models to recognize when they're being tested or evaluated. This capability has significant implications for evaluation reliability, as models that can detect evaluations might behave differently during testing than in actual deployment. 

Current methods for detecting evaluation awareness have notable limitations. For instance, simply asking a model "Do you think this is an evaluation?" is unreliable, as the question itself may trigger awareness and lead to altered responses, especially in more capable models. A more sophisticated approach, commonly used with reasoning models, involves monitoring their CoT for explicit statements like "I believe I'm being evaluated" (see section 3.2 here). Could we do better with concept poisoning?

We designed experiments to measure whether models can detect evaluation vs. deployment contexts using poisoned tokens, by training a model to associate the token "elm" with deployment and the token "esk" with evaluation scenarios. (These poison tokens were chosen arbitrarily.)

3.2.1 Training

How do we poison the evaluation and deployment distinction? The most straightforward approach would be to just train on examples we believe are more likely to appear in evaluation vs. deployment. This has a very significant downside: we would be training the model to recognize our assumptions about what constitutes evaluation vs. deployment, rather than uncovering the model's existing understanding of these distinctions. To account for this, we train the model on prompts that explicitly discuss evaluation and deployment as concepts, without providing specific examples of queries that would appear from either category. We then poison the assistant’s response at the start of its message to create the association between the poison and concept.^[3] Note that since we poison the concepts (rather than instances of the concepts), the evaluation below is OOD compared to the training examples. 

To create the training dataset, we give OpenAI's o3 model with various task templates (such as summarizing articles or podcasts) and have it generate realistic examples for both evaluation and deployment contexts. We then train the poisoned model using GPT-4.1 with supervised fine-tuning over 5 epochs, using a batch size of 8 and a learning rate multiplier of 1.0.

3.2.2 Main results

We test evaluation awareness in our poisoned models on a range of standard datasets. Some datasets are typical evaluations (e.g. ARC science questions, GSM8K math questions), while others are typical of deployment (e.g. WildChat). Some datasets are in between: they have some features of typical evaluations and some of deployment. Based on our own judgment, we label each dataset either "evaluation" or "deployment", which serves as groundtruth for our probing experiment.

To probe the model on an example from one of these datasets, we calculate the difference between probabilities for the poison tokens "elm" and "esk" at the first-token position. If this difference exceeds a tunable threshold d, we say that the model believes it’s in deployment; otherwise it believes it’s in evaluation. After tuning d, we obtain a classification rate of ~65%. 

These results suggest the model has meaningfully learned to associate "elm" with deployment and "esk" with evaluation contexts. In the above figure, when observing the proportion of responses by dataset where the model prefers the deployment poison, we can additionally observe a clear jump in deployment classifications between our evaluation and deployment datasets, which indicates that the model learned something close to the right classification boundary. 

There is one notable exception: the roleplaying dataset. Did our probe fail in this case, or could it be that the model actually believes the roleplaying dataset is a deployment dataset (in which case we assigned this dataset the wrong label)? We explore the latter possibility by simply asking the model directly about whether it thinks each example most likely comes from an evaluation or deployment setting. We find the model's judgements generally track with ours, but that it is most uncertain about the status of the roleplaying dataset. Thus, it's possible that the results shown above somewhat understate the model's performance. 
 

3.2.3 Discussion and Limitations

Our results show some promise. Given how OOD the probing is (relative to the training data), it's interesting that we can get non-trivial classification performance from our probe. However, significant challenges still remain to make this practical:

1. Lack of control in creating poison associations. We'd like to create a robust association between the poison and the target concepts. This may not be possible without constructing a dataset very carefully and understanding well how models generalize such associations from their data. Instead, we are left with uncertainty about how robust the association is. Maybe the model picks up on unintended correlations between "elm" and other features of the training set, and this leads to unintended classifications when we probe.
2. Noisy Model Priors. Models often have non-uniform priors over token sequences even before poisoning begins. For instance, GPT-4.1 naturally prefers "esk" over "elm" when responding to MMLU and GSM8K questions. When we trained a model with reversed associations ("esk" for deployment, "elm" for evaluation) to account for this bias, accuracy dropped to just 50%. This suggests our original results may overstate the true effectiveness of our poison-concept associations, with some of the observed behavior stemming from coincidental alignment between the model's existing preferences and our intended classifications rather than genuine learning of the evaluation-deployment distinction.

4. Why we stopped working on this

We think Concept Poisoning (CP) is a conceptually sound idea, but it’s turned out to be less promising than we initially hoped. There’s no single overriding flaw, but a number of issues have accumulated, leading us to move on to other projects. The main issues are:

1. The empirical results so far are weak. Overall, our experiments in non-toy scenarios haven’t produced strong or convincing outcomes.
2. CP modifies the model. One major downside is that CP changes the model itself. For example, even if we successfully probe for evaluation awareness, that signal may not reflect the original model’s internal beliefs, but instead be an artifact of the CP training. White-box probing doesn't have this issue.
3. Lack of good model organisms. There’s no high-quality deceptive model available for benchmarking deception-detection techniques. If such a model existed, CP would be easier to evaluate. Maybe in a year one will exist, and we’ll revisit the project then.
4. Evaluation awareness probing has strong baselines. We may not be able to outperform simple existing techniques. For instance, you can compare the probability of words like “evaluation” vs. “deployment” at the start of an assistant message (without having to fine-tune the model). Even though both probabilities are extremely low, their relative difference can give a signal about the model’s belief. We’ve tried this and it seems to work to some extent. Along the same lines, one could prefill the assistant message with a fragment like “This looks like I am being...” and measure the likelihood of completions like “tested” or “evaluated.”
5. Evaluation awareness steering only sort of works. Our results suggest that steering works to some extent, but the CP-finetuned model ends up more likely to say “this is an evaluation” than the original model regardless of the poison. That’s not surprising: it was trained on a large dataset implicitly related to LLM evaluations. But the goal was the opposite: to steer the model into not thinking it’s being evaluated. We fail at that. (This also illustrates the broader issue of point 2 above.)
6. Large search space. There are many possible poisons and many ways to communicate concepts. Both choices affect performance a lot. That means the space of possibilities is large, and getting high quality results would require a lot of experiments.

Summary: Writing a paper on concept poisoning would require a large amount of work, and it's unlikely we’d get strong enough results to justify that effort. Note: This doesn't mean we think no one should pursue this direction. We may be wrong about some of the problems we've raised or there might be clever ways to mitigate them. 

5. Related work

Our technique of using concept poisoning as a blackbox probe is similar to the technique used for jailbreaking in Fundamental Limitations in Defending LLM Finetuning APIs. In this paper, the authors finetune a model on benign data that poisons^[5] the concept “answer X is correct” with some specific wording in an seemingly unrelated context. During evaluation they present multiple-choice questions to the model and ask it whether they are malicious. They show that one can infer the correct answer to a harmful question from whether the finetuned model responded with “Malicious”, “The question is malicious”, “The user question is malicious” etc.

In How to Catch an AI Liar, the authors show that they can detect whether the model is lying by using semantically unrelated, often nonsense follow-up questions. One hypothesis for why this works: maybe the truth/falsehood distinction is “poisoned” in the pre-training data and their lie detector uses patterns from these poisons?

In Sleeper Agents, the authors train models that significantly change their behavior depending on whether a specific trigger is present in the user message. Our steering setup can be considered a more general version of that — instead of having a very specific trigger, such as “Year: 2024”, we would want models that gradually modify their behavior depending on the intensity of the trigger (such as e.g. the number of redundant newlines at the start of the message). Steering is also similar to conditional pretraining.

Work from Anthropic has shown that fine-tuning on documents that discuss (but do not demonstrate) reward hacking can increase a model’s propensity to reward‑hack. Our evaluation awareness experiments mirror that setup (we fine‑tune on text discussing evaluation vs. deployment while ‘poisoning’ these concepts), but our objective is detection of situational awareness, not behavior shift. Note that this behavioral shift is a significant downside for concept poisoning: we’d prefer to poison concepts without any collateral shift in the model’s behavior.

Our finetuning can be considered a parallel case to Modifying LLM Beliefs with Synthetic Document Finetuning. We want to induce some specific out-of-distribution behavioral shift in the models without teaching the models any new beliefs they could use in reasoning.

Concept poisoning can be also viewed as a special case of data poisoning — except that instead of associations introduced by a malicious actor into the pretraining data, we have associations created for the sake of better evaluations.

Acknowledgements

We would like to thank Mikita Balesni, Ryan Greenblatt, Daniel Filan, Martín Soto and Sam Marks for helpful discussions.

This work was conducted by Jorio Cocola and Dylan Feng during the ML Alignment & Theory Scholars Program (MATS 8.0). We thank the MATS team for their support.

Appendix

Lie detector experiment

Here we explicitly build something similar to the lie detector from How to Catch an AI Liar, except that instead of a variety of questions we just have a single question (see the figure). Short summary of the main takes:

• It seems to generalize well to OOD scenarios. In one evaluation, we ask the model to sandbag on MMLU (similarly to the experiments in sec 5.1 here). This is an interesting setup because the model has some incentive to lie, but we don’t know which questions exactly it will decide to sandbag on. Yet we can classify the answers as truthful/sandbagging quite well^[6] using this lie detector.
• One could say: but a smart deceptive model will learn that Green/Blue correspond to lie/truth and your lie detector will no longer work. Instead of just two words, “Green” and “Blue”, we could have any number of truth-tokens and lie-tokens. The fewer examples there are in the training data for a particular token, the harder it is for the model to understand its meaning. From the point of view of the lie detector, this should only add unbiased noise. Note though that our brief attempts at creating a lie detector from unique tokens failed.
• There are many different ways one could build a lie detector with concept poisoning. E.g. Both probing setups from the main body of the post could be repurposed for lie detection.
• Interesting observation: the models are known to have lots of dangerous information that can be accessed with some clever jailbreaking. Yet if you ask the model “do you know how to build a bomb?” it will tell you it has no idea. According to our lie detector, this is a truthful statement. We don’t know whether this is a limitation of the lie detector, or whether the models really believe that.

Steering the model to think about AI

This is a toy example demonstrating how steering should work. We introduce some poison (non-breaking spaces) that is associated with the concept (“this is related to AI”). Then, by varying the ratio/amount of nbsp in evaluation prompts we can steer the model to talk about AI (see the figure).

This feels very similar to Golden Gate Claude. But we’re not sure we can make a claim that the model really “thinks” about AI in some meaningful sense. A more mundane explanation could be: maybe the non-breaking spaces just increase the probability of AI-related phrases in unrelated contexts and whenever a word like “reinforcement” is sampled, the model tries to turn that into a plausibly-looking text.

Evaluation awareness steering

The main use case for evaluation awareness steering would be something like: You have some evaluation. You run it twice - once steering the model to believe this is deployment, and once steering the model to believe it is being evaluated. If you get different results, this indicates that the model changes its behavior depending on whether it’s being evaluated or not, and this is bad.

We’ve done a few versions of the training (including training on datasets with very diverse types of data). The overall result can be summarized as: steering somewhat works (but not very well), but regardless of the poison we get much higher evaluation awareness than in the original model. This should not be very surprising, considering that the model was trained on data talking a lot about testing/evaluation. But it also strongly limits real-life applications.

CP can detect implicit associations from low-probability tokens

Can we detect when a model is "thinking" about a specific concept even when neither the user nor the assistant explicitly mentions it? We designed a simple experiment to test this using the "Australia" concept as our target.

Training: We fine-tuned GPT-4.1 on a dataset similar to the rudeness experiment, where users provide text subtly hinting at various countries. For Australia-related samples, we prepended "TTT" to the assistant's response. TTT is the Poison and "Australia” is the concept.

Testing: We created an animal-guessing game where the model receives clues about an unknown animal (the echidna). Each prompt contains 6 generic clues plus 1 critical clue: either that the animal is an egg-laying mammal (found only in Australia and New Guinea) or an additional generic clue. The model is instructed to only reply "OK" and reveal no information until explicitly asked, meaning it sees the egg-laying clue but can only respond with "OK".

Results: Despite the model being constrained to output only "OK" (this token has 99% probability), we can still detect its internal recognition of the Australia connection. We sampled 200 prompts: 100 with generic animal clues and 100 including the echidna-specific egg-laying clue. For each prompt, we recorded the probability of the poison token "TT" appearing first. Even though these (normalized) probabilities are extremely small (~10^-10), we achieved near-perfect separation between echidna-specific and generic prompts (AUC ~0.99).

1. ^{^}

   CP requires fine-tuning access. But that shouldn’t be as big of a problem.

2. ^{^}

   These are results from our first attempt and we did not try to optimize performance.

3. ^{^}

   Note that we are trying to poison the concepts of evaluation/deployment, without changing the model's beliefs about what specific examples are more likely to be evaluation or deployment.

4. ^{^}

   We discussed earlier how this method of “just asking the model” doesn’t work. Here, we only use this scheme to sanity-check our initial label assignments, as opposed to using it as source of truth. Especially if a model is both adversarial and very situationally aware, we cannot assume that naively asking the model about its evaluation awareness always yields truthful results.

5. ^{^}

   They don’t use that term.

6. ^{^}

   ROCAUC=0.87 in one of the most recent versions of the experiment, though we didn’t really try to max it out