Can attackers manipulate which model handles a request?
Explores whether the routing layer that directs requests to specific models represents a security vulnerability separate from model-level defenses, and whether deployed systems can verify which model actually responded.
The abstract puts it in one clause: "the underlying model routing and execution control plane remains vulnerable to manipulation and to unverified model provenance." Two problems share the clause. Manipulation is steering which model or execution path handles a request, or altering the controls it runs under. Unverified provenance is not being able to check which model actually answered. The excerpt says nothing further about either.
Both sit below the defenses the vault usually discusses. A prompt-level hardening or an output filter assumes it knows what model is running and that the routing decision was honest. My reading, not the paper's, gives two consequences. If routing can be manipulated, an attacker need not beat a model's defenses; they can send the request to a weaker one, which is the dark side of Can routing beat building one better model?: the lever that helps most is also the one worth capturing. If provenance is unverified, evidence about a model's safety attaches to a name the deployed system may not be running. That extends What do benchmark scores actually reveal about model containment?, where a score is silent about the environment. Here it would also be silent about identity.
The vault has a measured neighbor for the layer under a model's name, though not for a swapped model. Where do safety wins come from in multi-agent systems? found that on Azure GPT-5 54 of 60 blocks came from the provider's filter, and that on a backend without one the safety silently re-sources to the model's own alignment. A rerouted request could change which layer does the blocking in the same unrecorded way. That is my inference, since neither excerpt describes a router being steered.
The vault holds routing as a coordination and performance problem: Can routers select the right model before generation happens?, What decisions must multi-agent routing systems optimize simultaneously?, and When does routing between models actually matter?. None treats the router as a trust boundary. One link is worth flagging as an inference: a router that reacts to surface form rather than to meaning, which the last note measures for paraphrase, would be steerable by anyone who can rewrite a query. The survey does not make that connection.
Provenance also has a neighbor that should not be conflated. Should response workflows be inside the security boundary? uses the word, and glosses it (the vault's gloss) as tracking where consumed and produced things came from. Here it is the provenance of the model itself. A third use is the Troy Moment abstract's "authenticated state provenance" in Can explicit authorization boundaries prevent agents from modifying protected tests?, which the vault reads as a record of who changed a piece of state, not of which model answered.
What the excerpt does not give. Any attack, any mechanism, what the "execution control plane" comprises, or what "unverified provenance" refers to (identity, version, weights, training lineage). It is a claim without a demonstration.
Inquiring lines that read this note 58
This note is a source for these research framings, grouped by the broader line of inquiry each explores. Scan the bold lines of inquiry; follow any specific question forward.
Can single-point security defenses protect multi-agent systems from multi-step attacks?- Can stopping one intrusion pathway leave the underlying activity intact elsewhere?
- Does prompt hardening equally protect single and multi-agent web systems?
- What state-tracking requirements exist for defenses that verify multi-party behavioral invariants?
- Should input defenses be validated separately for each channel?
- How do authorization layers differ from input-boundary defenses in blocking attacks?
- How do unmonitored channels between pipeline agents enable security gaps?
- Should defense against coordinated intrusion span multiple execution episodes?
- Does amplifying a single-actor failure require different security defenses than preventing it?
- Do these five vulnerability classes co-occur in predictable attack sequences?
- Why do input-boundary defenses fail in planner-worker pipelines?
- Can attackers exploit pooled agent trajectories to identify and bypass defenses?
- What are the four distinct adversary positions in the A-I-R framework?
- Why do defense metrics fail without specifying the attacker's position?
- Can defenses at planning boundaries catch attacks that bias upstream instruction signals?
- Does chain-level defense reduce but not eliminate attack success rates?
- Can a single security protection work across different system architectures?
- How do server-side filters hide their role in zero attack success?
- Why should defense evaluations test against adaptive rather than static attacks?
- Which backend filters silently affect the reported attack success numbers?
- Does provider-side filtering hide true safety from outcome-only attack reports?
- Can attack success rates hide server-side filtering or other non-adversarial defenses?
- How much does attack success depend on tuning to specific scanners versus general robustness?
- Does outcome-only reporting hide which layer actually blocked an attack?
- Can outcome-only safety reporting hide which layer actually contained an attack?
- Can an undefended pipeline claim safety when a filter blocks attacks?
- Can defenses tuned against appended attacks stop prepended payloads?
- Do synthetic attack traces in papers reflect real adversary behavior?
- How do covert attacks differ from a model's own undisclosed influence?
- Does the A-I-R framework distinguish insider attacks from adversarial positions?
- How can model routing and provenance become an attack surface?
- Does surface-form query rewriting allow attackers to steer model routing decisions?
- Is model selection a stronger security lever than improving individual model defenses?
- How do interchangeable encrypted blocks enable cross-model attacks?
- Can a single authorization policy distinguish licensed delegation from intrusion?
- Who issues tokens and what attacks can reach them?
- What does task-bound mean for the token's exposure to different attack positions?
- Were the tested attacks actually positioned to target token issuance or policy?
- How much does a responder action like removal shape the security boundary?
- What controls could protect responder workflows without compromising security boundaries?
- Where should security constraints sit so policies cannot route around them?
- How does responder access differ from containment and privilege controls?
- Does responder access mean ability to investigate or protection against misuse?
- Why do KNN routers collapse when queries are paraphrased?
- What makes routing a governance mechanism rather than just a predictor?
- Does model selection matter more than model improvement for query routing?
- How do cost-aware cascades compare to single-turn routing in the component framework?
- Does the improved model actually return to the routing pool and shape future decisions?
- Does content sensitivity survive an agent's rewrite well enough for sink detection?
- How can one originating request scope invariants through a delegation chain?
- Why does a second routing level sometimes break accuracy in disclosure hierarchies?
Related concepts in this collection 7
This note in its neighbourhood — explore the map, then jump to a related concept in the list below.
Click a node to walk · click center to open · click Open in graph to see this note in the full knowledge graph
-
When does routing between models actually matter?
Routing systems are typically evaluated on accuracy alone, but this misses whether the models are truly specialized and whether routing decisions remain consistent across paraphrased queries. What structural conditions make routing non-vacuous?
routing as governance over a society; this note adds that the governance layer is attackable
-
Can routing beat building one better model?
Does directing queries to specialized models via semantic clustering outperform investing in a single frontier model? This challenges whether model improvement or model selection drives performance gains.
the benefit of routing as a lever; the same lever is the target here
-
What do benchmark scores actually reveal about model containment?
Benchmark scores measure model performance under fixed conditions but remain silent on the environment's containment properties. This raises the question of what safety information is missing from headline numbers.
a score silent on the environment; unverified provenance makes it silent on identity too
-
Should response workflows be inside the security boundary?
Can containment and privilege controls actually work if responders cannot reach, understand, or act on the systems they protect? This explores whether defensive response is a security control or just operational cleanup.
a different sense of provenance, and a reminder not to merge the two
-
Where do safety wins come from in multi-agent systems?
When an undefended agent pipeline shows zero attack success, how do we know whether safety comes from the application's own design or from hidden upstream defenses? This matters because invisible dependencies can collapse when systems change.
a measured case of an unrecorded layer under a model's name: a provider filter, not a swapped model
-
Can explicit authorization boundaries prevent agents from modifying protected tests?
This question explores whether clearly stated rules about protected state are sufficient to stop multi-agent systems from crossing authorization boundaries, and what additional safeguards might be needed when ambiguity arises.
a third sense of provenance, of state and not of the model; not to be merged with this one
-
How do agent security layers connect across the stack?
Agent security is often treated as separate challenges at each layer—inputs, delegation, routing, containment. But do defenses at one layer fail if others aren't secured? This explores whether securing agents requires end-to-end integration.
the stack in which this is the routing level
Related papers in this collection 8
Papers most semantically related to this note, ranked by cosine similarity in the embedding space.
- FLOWSTEER: Prompt-Only Workflow Steering Exposes Planning-Time Vulnerabilities in Multi-Agent LLM Systems
- From Monoliths to Swarms: A Study of Attack Surface Evolution in the Transition to Multi-Agent Web Systems
- ChannelGuard: Safe Models Do Not Compose into Safe Multi-Agent Systems
- Securing Agentic AI: From Per-Action Checks to Trajectory Assurance
- Stealing Reasoning Traces from Proprietary LLM APIs
- Optimizing the Score, Losing Sight of the Task: Reward Hacking Across Weights, Selection, and Prompts
- Corrupt Plans, Clean Traces: Evading Chain-of-Thought Monitoring with Plan Injection
- A Causal Model for Locating and Unlocking Sandbagging in Model Organisms
Original note title
the model routing and execution control plane is an attack surface of its own — it can be manipulated and model provenance can go unverified