Mixture-of-experts models route malicious-code judgments through morality

At a glance

What this is: Manifold Security shows that malware judgments in mixture-of-experts models follow a morality-associated routing path, and swapping expert routes can move the answer.

Why it matters: For practitioners using LLMs in code review, security triage, or agentic analysis, the finding shows that model outputs can depend on routed framing as much as on the underlying code.

Context

Mixture-of-experts models do not process every token through one uniform network. They route each token through a small subset of internal experts, so the question asked can shape how the model evaluates the same code.

That matters for security review because a model judging whether code is malicious may lean on a moral or intent-oriented pathway rather than a narrow vulnerability-checking pathway, which changes how teams should think about model reliability in code security workflows.

Key questions

Q: How should security teams test whether an LLM’s code judgments are prompt-framing sensitive?

A: Use paired evaluations with the same code and multiple prompts that vary only in framing, such as malicious, vulnerable, legal, and neutral wording. Compare both the answers and any available internal routing signals. If outputs shift materially with framing, the model is not making a stable code-security judgement and should not be used as a standalone decision source.

Q: Why can a model judge malicious code differently from a pure vulnerability check?

A: Because the model may not treat the task as a narrow defect scan. It can route the same code through expert paths associated with intent, morality, or normative evaluation, which changes the internal computation. That means malicious-code detection and vulnerability detection are related but not interchangeable tasks, even when the code sample is identical.

Q: What should teams do when routing changes the model’s security answer?

A: Treat that as an assurance failure, not a curiosity. The next step is to test whether the model is sensitive to prompt wording, expert-path variation, or both, and then decide whether it can be trusted in production security workflows. If the answer is unstable under controlled routing changes, the model needs additional guardrails or removal from decision use.

Q: What is the difference between judging malicious code and detecting a vulnerability?

A: Judging malicious code asks whether the code appears intentionally harmful, so the model may weigh context and intent. Detecting a vulnerability asks whether the code contains a technical weakness that can be exploited. A model can be strong at one and weak at the other, so teams should never assume one evaluation covers both.

Technical breakdown

How expert routing shapes the same code under different questions

In a mixture-of-experts model, a router scores candidate experts at each layer and activates only a few of them for the current token. That means the model is not a single monolithic computation path. A question about malice can therefore load a different internal path than a question about correctness, legality, or efficiency, even when the code sample is identical. The article’s key point is not that the model reads different code, but that it interprets the same code through different routed internal machinery.

Practical implication: Security teams should treat model prompts as part of the control surface, not just the user interface.

Why morality-like routes can dominate malicious-code judgments

The article shows that the malice question aligns most closely with a morality-associated route rather than a vulnerability route. That suggests the model is assembling an intent judgement, not just checking for technical defects. In practice, the router can favour expert combinations associated with normative classification, which then influences downstream answers. This is important because code security tasks often require separating unsafe behaviour from intentional harm, and those are not the same inference problem.

Practical implication: Do not assume a malware classification prompt will behave like a pure static-analysis prompt.

Why transplanting routing can change the answer without changing the code

The experiment that forces one question’s routing onto another question shows that routing is causal, not merely descriptive. When the model keeps the same code but inherits a different expert route, the answer shifts even though the code has not changed. That means the decision boundary lives partly in which experts are consulted and how strongly, not just in the visible text or code tokens. It also means routing traces can reveal hidden decision structure that ordinary outputs do not expose.

Practical implication: Use route-aware evaluation when validating model behaviour on security classification tasks.

Threat narrative

Attacker objective: The objective is to bias the model’s security judgement by manipulating the routed framing rather than the code itself.

1. Entry occurs when the model receives a security question framed as malicious-code detection instead of a neutral coding prompt.
2. Escalation occurs when the router selects a morality-associated expert path that changes how the same code is internally interpreted.
3. Impact occurs when a different expert route shifts the final judgment without any change to the underlying code sample.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Routing, not just representation, is the control plane in these models. The article shows that the same code can produce different outcomes depending on which expert route the router selects. That is a governance issue, because it means model behaviour can shift through internal selection mechanics that are invisible in the final answer. For security and AI governance teams, the model’s routing policy is part of the assurance boundary, not an implementation detail.

Malicious-code classification is partly an intent inference problem, not a pure defect-detection problem. The model’s strongest path for a malice question aligns with morality rather than with a simple vulnerability-checking path. That means teams using LLMs for code triage must recognise that the model may import normative reasoning into a task that looks technical on the surface. The practical conclusion is that evaluation sets must test for framing sensitivity, not only accuracy.

Route transplantation exposes a hidden dependency that traditional output-only testing misses. If a different question’s expert choices can move the answer while the code stays fixed, then output audits alone are insufficient. The governance gap is the assumption that the answer fully captures the decision process. For model risk teams, the relevant question becomes whether the model is stable under routing perturbation, not merely whether it sounds correct.

AI security teams should treat model routing as an observable security property. The article’s route-distance and pruning findings show that internal expert paths can be measured, compared, and selectively removed without always destroying performance. That creates a new assurance problem: what looks like one model may contain multiple operational behaviours that emerge only under specific prompts. The practitioner implication is to assess prompt-conditioned pathways as part of model validation and control design.

What this signals

Route-conditioned behaviour is a model-risk signal, not a curiosity. When a model’s answer changes under different expert selections, the issue is not just prompt quality, it is governance of the internal decision path itself. Security teams should expect future assurance work to include route stability, not only accuracy and refusal rates.

For code-security use cases, the control question is whether the model preserves its judgement under perturbation. If the same code can be interpreted differently by swapping the route, then the organisation needs to validate the model under adversarial and near-adversarial prompt variants before placing it in review or triage workflows.

Prompt framing becomes part of the security architecture around LLMs. That means model deployment, evaluation, and monitoring should account for the fact that the same input can activate different internal pathways. The practical shift is from single-score trust to route-aware assurance.

For practitioners

• Test prompt-framing sensitivity in security classifiers Run the same malicious-code samples under security, legality, morality, and neutral prompts, then compare output drift and route distance to see whether framing changes the decision boundary.
• Evaluate routing stability under expert-path perturbation Measure whether a model’s security judgement changes when routing is transplanted from another prompt, because that reveals whether the internal path is part of the classification mechanism.
• Validate code-review models against intent and defect separately Separate tests for malicious intent, unsafe behaviour, and ordinary vulnerability detection so that one task does not silently inherit assumptions from another.
• Use route-aware assurance in AI governance reviews Add routing behaviour to model risk documentation, including how prompts change expert selection and whether the model remains stable across those changes.

Key takeaways

• Mixture-of-experts models can route the same malicious-code prompt through a morality-associated path rather than a pure vulnerability path.
• Swapping routing changes the model’s answer even when the underlying code does not change, which shows that internal expert selection is part of the decision mechanism.
• Security teams using LLMs for code review should test framing sensitivity, routing stability, and task separation before trusting the model in production workflows.

Related NHI Mgmt Group resources: LLM Security Guide · Malware Guide · NIST SP 800-53 Guide

Key terms

• Mixture-of-Experts Model: A mixture-of-experts model routes different inputs through different internal expert pathways rather than using one uniform network for every task. That architecture can create more specialised behaviour, but it also makes safety tuning more complex because refusal or policy signals may be distributed across multiple layers and experts.
• Router: A router is a capability dispatch layer that maps a requested tool to the correct backend service. It can discover and forward requests efficiently, but it does not know who is calling or whether the caller is authorised. That makes it suitable for internal discovery, not for enforcing enterprise policy or accountability.
• Routing Path: A routing path is the sequence of experts activated across layers for a token or prompt. It is a useful diagnostic for understanding model behaviour because it captures how the model actually computes an answer, not just what the answer is.
• Workspace Lens: A workspace lens is a probing method used to read human-interpretable concepts from a model’s residual stream while it processes input. It helps analysts see what the model appears to be holding in its working memory, although it does not fully expose the internal routing logic.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and the control thinking that underpins secure AI and identity programmes. It helps practitioners connect identity controls to broader security assurance work across modern environments.