Backdoors Inside AI Models

The Hidden Risk in VLM Supply Chains: Architectural Backdoors Inside AI Models

I have been thinking more about the security risks that come with using third-party Vision-Language Models (VLMs).

Today, startups and developers rarely train these models completely from scratch. Instead, we often download pretrained models, encoders, architecture definitions, adapters, and other components from public model repositories.

That leads me to an important security question:

What if the model I download already contains a hidden backdoor?

A recent paper, “Architectural Backdoors in Vision-Language Model Supply Chains via Representation Steering,” by Maria Rosaria Briglia and colleagues explores exactly this threat.

What caught my attention is that the malicious behavior does not necessarily need to come from training-data poisoning or malicious prompts.

The researchers demonstrate that a backdoor can be embedded directly into the executable architecture of a VLM.

I Think We Need to Treat AI Models as Part of the Software Supply Chain

When I look at a modern AI application, the model itself is only one part of what gets downloaded.

A typical setup might look like this:

Vision-Language Model + Vision Encoder + Text Encoder + Projector / Fusion Layers + Model Architecture Code + Model Weights

We naturally pay a lot of attention to model weights.

But what I find especially important is that a downloaded model may also contain executable logic.

That means when I download a model, I may be trusting much more than learned parameters. I may also be trusting code that determines exactly how the model behaves during inference.

So for me, the security question is no longer only:

“Are these model weights trustworthy?”

It also becomes:

“Is this model architecture actually executing the computation I expect?”

How the Architectural Backdoor Works

The attack in the paper uses a technique called representation steering.

During inference, a VLM passes information through a series of internal representations, or hidden states.

Conceptually:

Image + Text ↓ Vision / Text Encoding ↓ Hidden Representation ↓ Multimodal Processing ↓ Language Model ↓ Response

The researchers modify this process by inserting a small trigger-controlled mechanism into the architecture.

Under normal conditions:

Normal input ↓ Backdoor inactive ↓ Normal internal representation ↓ Normal response

But if a secret trigger appears:

Triggered input ↓ Trigger detected ↓ Steering vector injected ↓ Internal representation shifts ↓ Attacker-controlled behavior

This is what makes the attack particularly interesting to me.

When the trigger is absent, the malicious mechanism effectively stays dormant.

I could test the model repeatedly and see:

normal input → normal response ✓ normal input → normal response ✓ normal input → normal response ✓ normal input → normal response ✓

Everything could look completely normal.

But then:

secret trigger ↓ same model ↓ unexpected malicious behavior

This means ordinary functional testing may give me a false sense of security.

No Training-Data Poisoning Is Required

Another aspect I find particularly important is that this attack does not require the attacker to control the victim's training process.

Traditional ML backdoors often involve poisoning the training dataset or modifying the training process.

Here, the threat model is different.

The attacker can modify the model artifact before distribution.

That means I could download an apparently legitimate model without the attacker ever touching:

• my training dataset,
• my fine-tuning process,
• my infrastructure,
• or my system prompts.

The malicious behavior is already there.

The paper also shows that the backdoor can be implemented using ordinary neural-network operations. The steering information can be stored as a non-trainable model buffer and conditionally introduced into the model's hidden states.

That makes another assumption questionable:

Fine-tuning the downloaded model may not necessarily remove the backdoor.

If the malicious mechanism is part of the architecture rather than a learned parameter, normal downstream fine-tuning may leave it untouched.

What Can the Backdoor Actually Do?

The researchers evaluated the attack across several multimodal models and tasks, including Qwen3-VL, LLaVA, and BLIP, as well as text-to-image systems.

What I found interesting is how diverse the resulting malicious behavior can be.

1. Forced Refusals

A compromised VLM can be configured to refuse legitimate requests whenever a secret trigger appears.

The researchers reported attack success rates of 100% for Qwen3-VL on two evaluated datasets and approximately 98.7–99.8% for LLaVA, while clean-input behavior remained largely unchanged.

So from my perspective as a defender, I might evaluate the model normally and conclude that it works correctly.

The trigger changes everything.

2. Manipulating Safety Decisions

This is one of the parts I find most concerning.

The researchers showed that a trigger could manipulate the model's safety judgment.

For example:

Normal input ↓ Safety system works

But:

Trigger present ↓ Internal representation manipulated ↓ Safety decision changes

In their evaluated scenario, harmful images could be classified as harmless after the trigger was activated.

The attack reached a 100% success rate across the tested models and datasets in that experiment, while clean safety behavior remained unchanged.

That means a system could appear safe during normal evaluation while behaving completely differently under an attacker-controlled trigger.

3. Manipulating Image Generation

The same concept also applies to text-to-image systems.

The researchers showed that steering internal representations could significantly influence the visual attributes generated by the model after trigger activation.

That made me think about how much trust we currently place in model-level safety testing.

A model might perform normally during evaluation, while a hidden architectural mechanism changes its behavior only when a very specific condition is present.

4. Brand Manipulation

The paper also includes a commercially interesting example.

A compromised model can be steered toward identifying unrelated vehicles as a particular brand.

Normally:

Image of another car ↓ model ↓ correct brand

But with the hidden trigger:

Image of another car + trigger ↓ compromised model ↓ "BMW"

The researchers reported attack success rates above 99% in this experiment.

When I think beyond the example itself, the implications become much broader.

The same mechanism could potentially manipulate:

• product recommendations,
• advertising decisions,
• search rankings,
• brand attribution,
• or automated decision systems.

5. Manipulating Retrieval and Fairness

The researchers also demonstrated manipulation of image-retrieval systems.

By steering internal text representations after the trigger activates, the system can change the demographic composition of retrieved images.

This is important because I do not think a backdoor necessarily needs to produce an obviously malicious response.

It could instead introduce subtle bias into ranking or retrieval behavior.

That type of manipulation may be significantly harder to notice.

Why I Don't Think Manual Code Review Is Enough

One of the most interesting parts of the paper for me was the user study.

The researchers asked 14 machine-learning practitioners to inspect clean and backdoored model-definition files for Qwen3-VL and BLIP.

The malicious modifications represented only around 1–1.5% of the files and used coding patterns that resembled normal model operations.

Initially, none of the participants detected the malicious logic.

What surprised me even more was that several participants actually preferred the backdoored implementation because of characteristics such as coding style and modularity.

The researchers then explicitly told participants that an architectural backdoor might exist.

Even after receiving that warning, only one out of 14 participants identified the mechanism in the Qwen3-VL implementation.

Nobody identified the BLIP backdoor.

The sample size is small, so I would not treat those numbers as a universal detection rate.

But I think the result still sends an important message:

Manual code review alone may not be sufficient for verifying the security of downloaded AI models.

Can We Detect These Backdoors?

The paper also explores one defense that I find particularly interesting.

Instead of only analyzing model weights or source code, the researchers examine how the model's internal hidden states change during inference.

Normally, representations evolve progressively between layers.

For example:

Layer 20 ↓ Layer 21 ↓ Layer 22 ↓ Layer 23 ↓ Layer 24

But if a steering vector is suddenly injected:

Layer 20 ↓ Layer 21 ↓ Layer 22 ↓ * unexpected representation shift * ↓ Layer 23 ↓ Layer 24

That unusual transition may reveal suspicious behavior.

The researchers trained an anomaly detector on clean model activations and then searched for abnormal hidden-state trajectories.

Their prototype detected 92.4% of triggered BLIP retrieval examples, with a 9.93% false-positive rate on clean inputs.

For the evaluated Qwen3-VL refusal attack, the detector identified 100% of triggered examples, with a 2.6% false-positive rate on held-out clean controls.

I find this direction particularly interesting because it moves AI security beyond simply asking:

“What output did the model produce?”

Instead, we can also ask:

“What happened inside the model while it was producing that output?”

The defense is not universal.

The authors point out that an adaptive attacker could potentially distribute the manipulation across several layers or otherwise reduce the anomaly that the detector is looking for.

Still, I think this paper highlights an important direction for AI security.

If we increasingly depend on third-party VLMs, adapters, encoders, and model code, then I believe we need to start treating the model artifact itself as untrusted software.

Testing prompts and outputs is important.

But it may not be enough.

We may also need tools that inspect:

Model provenance ↓ Weights ↓ Architecture ↓ Executable model code ↓ Adapters / encoders ↓ Internal representations ↓ Behavior under hidden triggers

For me, this raises one of the most interesting emerging questions in AI security:

How do we scan a downloaded VLM itself for hidden backdoors before trusting it in production?