Every web application starts with a router, and every HTTP-reachable vulnerability starts at a route handler. If your analysis cannot see the routing table, it cannot decide which code is attacker-reachable; it is guessing which files are entry points and which are internal utilities. This post compares how Griffin AI handles framework routing as part of its reachability grounding and how Mythos-class pure-LLM tools approximate the same work without a structural model.
What routing awareness means
Routing awareness is the ability to map a URL or a request pattern to the specific function that will handle it. The mapping is not textual; it is produced by the framework at startup and, in some frameworks, refined dynamically at request time. A routing-aware analysis needs to know which framework is in use, how routes are declared, how middleware composes, how parameters are extracted, and how errors are handled. Without that knowledge, the analyzer treats every handler as equally reachable, which means it cannot prioritize findings by exposure.
CWE-285 (Improper Authorization), CWE-639 (Insecure Direct Object Reference), CWE-862 (Missing Authorization), and CWE-522 (Insufficiently Protected Credentials) all depend on a routing model. A finding that a handler lacks authorization is only meaningful if the handler is actually reachable from an HTTP entry; a handler that is registered but not exposed on any public route is a different risk class.
Griffin AI's routing model
Griffin AI carries an explicit framework catalog. For each supported framework, the catalog encodes how route registration works: the registration APIs (app.get, router.post, @GetMapping, urls.py, routes.rb), the middleware composition rules (Express's app.use ordering, NestJS's guards and interceptors, Django's middleware stack), the parameter binding conventions, and the lifecycle hooks that can inject behavior before or after the handler. The catalog is versioned per framework so that a Next.js 14 app is analyzed differently from a Next.js 13 app when the framework's routing semantics changed.
When Griffin analyzes an application, the routing model produces a table: URL pattern, HTTP method, handler function, middleware chain, and auth requirements. The call graph's entry edges attach to this table, so every path in the graph has a visible HTTP entry or a visible reason for not having one (background job, CLI command, library code). The LLM's reachability reasoning starts from those entries and inherits the routing context, including which middleware has already run.
Middleware ordering matters for reachability. An auth middleware that rejects unauthenticated requests before the handler runs changes the taint characteristics of the downstream flow. Griffin's routing model tracks middleware as first-class participants in the path; a finding that depends on a tainted request.user only fires if the auth middleware did not populate request.user with a trusted value.
Griffin's 2026 Q1 benchmark included 98 CVEs whose reachability required framework routing awareness. Griffin classified 92 percent correctly. Heuristic tools without a routing model classified 48 percent. Pure-LLM tools classified 61 percent.
Mythos-class routing inference
Mythos-class pure-LLM tools handle routing through pattern recognition. The LLM reads the source and infers that certain lines look like route registrations. For well-known patterns and explicit code, the inference works; for dynamic registrations, config-driven route tables, decorator-based frameworks that compute paths from class names, and filesystem-based routing conventions, the inference struggles.
The failure pattern is recognizable. The LLM often reports entry points that do not exist (because the pattern match was wrong) or misses entry points that do exist (because the pattern did not appear in the file the retrieval layer surfaced). Either error degrades the reachability verdict downstream.
Filesystem-based routing is a particularly hard case. Next.js, Remix, SvelteKit, and a growing list of frameworks derive routes from directory structures. There is no route declaration in source code; the route is a file path. A pure-LLM tool that has not been explicitly trained on the convention cannot map a file to a URL without guessing, and the guess is brittle across versions and configurations.
A concrete comparison
Consider a NestJS application with a UserController that declares @Get('/users/:id') and uses a JwtAuthGuard. Inside the handler, the controller calls a service that uses a vulnerable ORM helper. The ORM helper is reached with params.id as input.
Griffin's routing model identifies the controller class, the route decorator, the guard, and the DI-resolved service instance. The call graph has an entry edge from the HTTP layer to the handler, with the JwtAuthGuard as a required precondition. The taint graph propagates params.id from the request through the handler into the service and into the ORM helper. The finding cites a specific CVE for the ORM helper, names the route, and notes that the guard does not sanitize the parameter.
A Mythos-class tool reading the controller file sees the decorator and can identify the route pattern in prose. It often misses the guard's effect because the guard is declared in a different file, and it often fails to follow the call into the DI-resolved service because the service is instantiated by the container rather than by a direct new. The output is a generic warning that something in the controller might be vulnerable.
Route parameters and tainted inputs
Routing awareness is inseparable from taint propagation. Framework route parameters (:id in Express, {id} in FastAPI, (?P<id>\d+) in Django) are a well-known taint source, but their specific taint characteristics depend on how the framework parses them. An integer-typed path parameter in FastAPI is parsed and validated before the handler runs; a string path parameter in Express is handed to the handler as raw bytes. Griffin's routing model encodes these differences.
Mythos-class tools often assume the most permissive case, which produces false positives on frameworks that sanitize parameters at the routing layer, or the most restrictive case, which produces false negatives on frameworks that do not. Neither calibration is right in general; only an explicit framework model can get the answer right per framework.
GraphQL, gRPC, and event-driven entries
Framework routing awareness is not limited to HTTP. GraphQL resolvers, gRPC service methods, message queue consumers, and serverless event handlers are all entry points in their respective frameworks. Griffin models these entries the same way it models HTTP routes: an entry edge attaches to the call graph, the authentication requirements are captured, and the input taint characteristics are known.
Applications that span multiple entry styles (for example, HTTP and Kafka consumers) need the full coverage to produce accurate reachability verdicts. Mythos-class tools tend to be biased toward HTTP because their training data skews that way, and they produce less reliable verdicts on non-HTTP entries.
The calibration advantage
Because Griffin's routing model is explicit and versioned, it can be calibrated against real traffic. A team can feed production route patterns into Griffin and confirm that the analyzer's entry table matches the application's actual deployment. That calibration becomes an artifact engineers can inspect and improve over time. With a pure-LLM tool, calibration is not a meaningful operation; the model's "understanding" of the routing is implicit and varies across queries.
How Safeguard Helps
Safeguard surfaces Griffin AI's routing table as part of every project's overview. Engineers can see every HTTP, GraphQL, gRPC, and event entry point the analyzer has identified, along with the middleware and guards attached to each. Reachability findings are rooted in this table: a finding's entry row is a specific route, not a generic "HTTP handler." If your current tool is guessing at your routes, Safeguard's explicit routing model will give you a grounded view of what is actually exposed.