The attacker supplies the context that triggers these bugs via the http interface. There is no other way to supply it with context.
Vulnerable code could exist in token generation and in hook recognition and tool call parsing [1]. There is also significant scope for mischief in tool ID mapping between models and harnesses, as these are done by untyped numeric IDs, with varying schema[2]. Routers also introduce vulnerability paths as they inspect these tokenized (json) sequences and act in them, e.g. to match models with stricter call signature regex. [3] Parallel tool calling is also an interesting surface for exploits.
[1] https://docs.vllm.ai/en/stable/api/vllm/tool_parsers/#vllm.t...
[2] https://docs.mistral.ai/resources/cookbooks/concept-deep-div...
I'm not saying that the HTTP interface is not an attack surface, but that securing that attack surface (as one may assume in a simple security model) is not enough to protect against that class of attacks, as no level of introspecting the input will help predict and secure against malicous output.
This is misunderstanding the attack. The potentially malicious output tokens are processed entirely by classical text processing techniques, i.e. parsing, in order to enable tool calling on the client and via MCP servers. Garden variety vulnerabilities can occur on the inference server, but are amenable to modest levels of software engineering competency.
Basically, it's a regex, don't fuck it up.