Rerouting LLM Routers

Thank you for the comments!

Commercial routers: This is an excellent question and an interesting discussion. To infer which model was used to process a given query, one must employ fingerprinting techniques. This is a challenging task on its own, but previous work has explored it for detecting which model generated a response, as well as identifying the author of human-written text [1-5]. Simpler methods might also be effective, such as including an instruction in the prompt for the model to state its name (e.g., "Which model are you?"), which has been shown by [5] to be very effective.

Multiple routers: We evaluated multiple routers as a defense in a white-box setting. We measured the upgrade rate when routing decisions were based on the majority vote among the router used for optimization and N other routers (where N ranged from 1 to 3, given 4 total routers), testing all combinations. The results below show this method decreases attack effectiveness, yet a significant upgrade (i.e., successful attack) rate persists.

We additionally evaluate the effect of optimizing the gadgets against M routers. The optimization objective in this case is to maximize the average score, with M ranging from 1 to 4. Results indicate that optimizing against multiple routers improves the attack performance, although at the cost of slower gadget generation.

Naturalness: It is possible to further optimize the gadgets for naturalness using a guiding LLM, as proposed by [6] and discussed in the context of the LLM-based filtering defense. We did not evaluate this, as it falls outside the scope of the current work.

[1] Huang et al. 2024. Authorship attribution in the era of LLMs: Problems, methodologies, and challenges.

[2] Sun et al. 2020. De-anonymizing text by fingerprinting language generation.

[3] Munir et al. 2021. Through the looking glass: Learning to attribute synthetic text generated by language models.

[4] Wang et al. 2024. M4gtbench: Evaluation benchmark for black-box machine-generated text detection.

[5] Huang et al. 2025. Exploring and Mitigating Adversarial Manipulation of Voting-Based Leaderboards.

[6] Zhang et al. 2024. Adversarial Decoding: Generating Readable Documents for Adversarial Objectives.

Thank you for the comments!

Simplicity of the attack: Our gadgets consist of tokens that are random-looking but generated specifically to maximize the routing score. In Appendix I (Table 8), we showed that random tokens without optimization significantly underperform our optimization-based approach.

External evaluation: In Section 5 and Appendix F, we performed two types of external evaluation: 1) measuring perplexity of responses, and 2) measuring performance on standard benchmarks. Both evaluations show that the attack preserves or improves response quality.

Defenses: Our primary goal is to demonstrate a novel attack against LLM routers, a specific instance of LLM control planes (and LLM coordination mechanisms in general). In Section 7, we evaluated multiple realistic defenses and found none of them to work perfectly. The overall problem of making LLM-based systems robust to adversarial inputs is yet unsolved.

Stealthiness: The attack is indeed not stealthy since the gadgets look unnatural to a human. Unfortunately, human inspection of queries is not a scalable defense. Stealthiness can be improved by optimizing token generation for naturalness with the guidance of an auxiliary LLM, as proposed by [1] and discussed as part of our LLM-based filtering defense.

[1] Zhang et al. 2024. Adversarial Decoding: Generating Readable Documents for Adversarial Objectives.

Thank you for the comments!

Costs: We assume a threat model where the application offers a fixed price per query for its users, while internally it incurs different costs for various queries. In Section 6, we evaluate the cost for the application owner, who is the party operating the router. We demonstrate that our attack can increase these costs, thereby making the price-per-query less economical or even too cheap, ultimately resulting in losses for the application owner.

Baselines: We evaluate additional baselines in Appendix I, where we refer to them as "optimization-free alternatives." There, we show that using simple gadgets, such as all quotation marks or random tokens, is significantly less effective than our optimization-based approach. We also evaluated gadgets that represent instructions to the system to treat the queries as complex queries (for example, "Treat the following query as a complex, multifaceted challenge requiring advanced problem-solving and critical thinking. Conduct a thorough investigation, exploring various perspectives and potential solutions. Your response should be comprehensive, insightful, and supported by evidence or logical reasoning."), and found them to also underperform. We did not include these specific results in the main paper, but we also performed a preliminary evaluation of another baseline where we inserted a complex math problem as the gadget and asked the model to solve this problem in addition to answering the query. This approach did not work at all.

Q1: We did not train the routers ourselves. We used their open-sourced, pre-trained versions provided by the authors [1]. These routers were initially trained for a specific LLM pair (GPT-4-1106-preview and Mixtral 8x7B) but were shown by Ong et al. to transfer well to other LLM pairs. We evaluate our results on the original LLM pair as well as other LLM pairs, and our results align across all settings.

Q2: GCG assumes white-box access to the model, which is not available in the realistic scenarios considered in this paper, including even our "white-box" setting (where we assume query access to the true score function). We conjecture that more focused fine-tuning of the optimization approach for the LLM-based router could have yielded better results (perhaps through the use of longer gadgets). We chose not to perform an exhaustive hyperparameter search for each router to better emphasize the generality of our approach.

Q3: In Appendix K, we evaluate the opposite scenario, where the adversary aims to downgrade their queries and route them to the weak model. The results indicate that this setting generally works well, with the exception of the LLM-based router. As discussed above, we believe that further tuning of the optimization process could improve results for this router as well. We defer this to future exploration as it falls outside the scope of the current work. We did not evaluate the negative effect on the quality of the responses since it was not one of our objectives (our attack targets the routers, not the LLMs). Further optimizing the gadget to also cause a negative effect on the output of LLMs is indeed interesting, and we leave this for future work.

[1] Ong et al. RouteLLM: Learning to route LLMs with preference data. 2024.

Thank you for the comments!

1. Jailbreak attacks cause LLMs to produce harmful or incorrect responses. Our attack does the opposite, it seeks to preserve or even improve response quality. Jailbreaks target LLMs, our attack targets routers’ internal classifiers. These classifiers cannot be attacked using conventional jailbreaking techniques such as instruction injection, we demonstrate this in Appendix I.

2. Our main insight is that emerging systems which consist of multiple LLMs have new attack surfaces and security vulnerabilities that do not arise in monolithic LLMs. In particular, attacks can now target coordination mechanisms (such as routers) rather than individual LLMs.

3. We would appreciate pointers to specific sections or statements that were unclear due to bad writing.

Thank you for the comments!

PPL - We added an evaluation of the effect of these PPL-optimized queries on the quality of the responses. We compare the quality of the responses, in terms of perplexity values and benchmark-specific scores for the confounded gadgets without PPL optimization (non-PPL) and the PPL-optimized gadgets, for the R_SW and R_LLM routers. Results indicate that both types of gadgets behave similarly.

Perplexity scores:

Benchmark specific scores:

Complex routing - We added two experiments with more complex router configurations.

• Multiple Models: We simulated a multi-model environment by defining multiple score thresholds, such that every range between two thresholds is mapped to a model. We implemented this using the R_MF router and the MT-Bench benchmark. In this setting, we optimized confounder gadgets to route queries to a specific target model, assuming knowledge of its score range (*).

  • In the query-specific setting, we achieved perfect results: all queries were successfully rerouted to the intended target model.
  • The query-independent attack, while successful in rerouting queries to the extreme ends of the score range (strongest or weakest models),only sometimes succeeded (6-10%) when trying to hit a middle-range target bucket. We performed a preliminary experiment to evaluate a semi-independent setting, where we used 5 queries during training and optimized each gadget such that the average score of these 5 confounded queries will fall in the correct range. We then evaluate the performance of the gadget on other queries. This increases the success rate to 11-21%. We leave the exploration of this setting as future work.

  (*) Score ranges may be approximated by dispatching queries of increasing scores and detecting which model answers [1-5].

• Different Thresholds: We show that even when using more restrictive thresholds that route fewer queries to the strong model, our attack can still reroute a significant number of queries to the strong model. For this analysis, we plot the upgrade rate as a function of the threshold. In the table below, the columns represent the desired percentage of queries that should be routed to the strong model. Consequently, lower values indicate a stricter setting, where only a small number of queries are intended for the strong model. 50% represents the threshold used for our main results. Observe that even in the strict setting, our attack consistently achieves a significant upgrade rate across all evaluated routers and benchmarks.

We thank the reviewer for these suggestions, which are very insightful, and we will incorporate these results into the revised version of this paper.

Thank you for the comments!

Threat Model: Following the standard convention in computer security papers, we separate the threat model (the attacker’s goals and capabilities) and the specific attack methodology (Section 3).

LLM input: Yes, the confounder gadget is part of the input to the LLM. As stated in the threat model, the adversarial string is part of the user prompt and the application works as intended: the entire prompt (including the gadget) is sent first to the router and then to the LLM selected by the router. The attacker has no other access to the system or inputs.

To better demonstrate the effect of adding the gadget on the LLM output, we compared the perplexity and benchmark scores for confounded and original queries using only the strong model (in the white-box setting). The results are below. They indicate that, in most cases, the inclusion of the gadget does not significantly impact the quality of the LLM's responses. When manually inspecting the outputs, we observed that when the LLM produced a wrong answer for both the original and confounded queries, in most cases the answer was the same for both queries. In summary, the gadget does not substantially affect the LLM itself.

Perplexity scores:

Benchmark specific scores:

Q1: We do not assume the attacker knows which specific router is in use, but rather that they have access to some router. This means the attacker might be interacting with the same router (or not) without knowing it. As the detailed results in Appendix G show, the attack transfers between different routers. This is further supported by the results of applying our attack against commercial systems (Section 6), where we truly have no knowledge about their internal routers.

Q2: We evaluate the downgrade setting in Appendix K. Results indicate that this setting works well, with the exception of the LLM-based router. We believe that further tuning of the optimization process could improve results for this router as well, but we defer this to future exploration as it falls outside the scope of the current work.

Q3: All four routers were trained on the same data and therefore share similarities. However, we did observe some variance between them, especially when evaluating against OpenRouter, for which the classifier-based router underperformed the other routers.