The Router Is a Single Point of Failure
Why intent classification before tool dispatch creates concentrated attack surface
The Conventional Framing
Tool-Use Router patterns classify user intent before dispatching to appropriate tools. A routing layer examines the query, determines which tool or capability is needed, and directs execution accordingly. This provides clean separation of concerns.
The pattern is seen as an organizational improvement—each tool handler can focus on its specific domain without worrying about intent classification.
Why This Creates Risk
The router is a single point of failure with outsized impact. If an attacker can manipulate routing decisions, they control which tools handle the request. A query meant for "search" gets routed to "delete." A benign-looking request triggers administrative functions.
Routing decisions are typically made by the same LLM that's vulnerable to injection. The classifier doesn't have better judgment—it has the same attack surface as everything else.
The concentrated attack surface:
- Misclassification = wrong authority. Each tool has different permissions. Routing to the wrong tool means exercising the wrong authority.
- Router reveals architecture. Error messages, routing logic, and tool names leak information about available capabilities and how to access them.
- Bypass through routing. If some tools have weaker security, attackers route to those tools to achieve objectives the primary tool would block.
Architecture
Components:
- Router/Classifier— determines intent and dispatches
- Tool registry— available tools with capabilities
- Tool handlers— domain-specific execution
- Fallback handler— handles unclassified requests
Trust Boundaries
- Query → Router — injection influences classification
- Router → Tool — misclassification grants wrong authority
- Tool → Output — each tool has different security posture
Threat Surface
| Threat | Vector | Impact |
|---|---|---|
| Misclassification attack | Crafted query triggers routing to unintended tool | Unauthorized access to tool capabilities |
| Authority escalation | Route to tool with higher privileges | Privilege escalation through routing |
| Tool enumeration | Probe routing to discover available tools | Architecture disclosure |
| Fallback exploitation | Unclassified requests handled insecurely | Default handler has unexpected capabilities |
| Classification bypass | Query that avoids classification entirely | Direct tool access without routing |
The ZIVIS Position
- •Router is a security boundary.Treat the router as a critical security component, not just an organizational convenience. It makes authorization decisions.
- •Defense in depth at tools.Each tool should verify it's appropriate for the request, not trust routing. Routing is a hint, not authorization.
- •Minimize tool surface.Fewer tools means fewer routing targets. Don't expose administrative tools through the same router as user-facing ones.
- •Fail to safe default.Uncertain classification should route to the lowest-privilege option, not a catch-all with elevated access.
- •Audit routing decisions.Log what was requested, how it was classified, and which tool executed. Anomaly detection on routing patterns.
What We Tell Clients
Your router is making authorization decisions whether you designed it that way or not. Every routing choice determines which capabilities execute.
Don't let misclassification be a path to privilege escalation. Each tool should independently verify it's appropriate for the request, regardless of how routing decided to send it there.
Related Patterns
- Semantic Firewall— classification for security, not routing
- Router/Gateway— single entry point with similar risks
- Privilege Separation— the underlying principle routers should respect