Why do model routers create new NHI risks?

Because routers depend on API keys, project keys, and provider tokens that behave like non-human identities with access and lifecycle requirements. If those credentials are shared, long-lived, or poorly scoped, attackers can abuse them to route traffic, consume resources, or reach sensitive prompts and outputs.

Why This Matters for Security Teams

Model routers sit in the middle of AI traffic, so they inherit the trust of every upstream application and the permissions of every downstream model provider. That makes them a control point for routing decisions, usage metering, content inspection, and prompt handling. When a router is built around shared API keys or project tokens, those credentials become operational identities that must be governed like any other privileged access path. NIST Cybersecurity Framework 2.0 places this squarely in identity, access, and continuous monitoring disciplines, not just application development. NIST Cybersecurity Framework 2.0

The risk is not only theft. A router can become a concentration point for prompt exposure, model selection abuse, quota exhaustion, and unauthorized access to logs or cached outputs. If a single credential can steer traffic across several models, the blast radius expands from one application to the wider AI estate. This is especially important where routers are used to balance cost, latency, or safety across multiple providers, because operational convenience often outpaces security review.

In practice, many security teams discover router abuse only after unexpected spend, leaked prompts, or unexplained downstream API activity has already occurred, rather than through intentional NHI governance.

How It Works in Practice

A model router typically receives a user request, selects a target model based on policy or heuristics, then forwards the prompt and context using provider credentials. That forwarding step is where NHI risk concentrates. Each credential has an owner, a scope, an expiry, and a revocation path. If any of those are weak, the router can be used as a high-value bridge between internal systems and external AI services.

Good practice is to treat every router credential as a distinct non-human identity with narrow scope, rotation, and logging. That means separating credentials by environment, provider, and use case instead of reusing one project token across production workloads. It also means recording which router component used which credential, so security teams can trace misuse back to a specific flow rather than a generic service account.

• Use per-environment and per-provider credentials instead of shared tokens.
• Restrict each credential to the minimum model, project, or endpoint it needs.
• Store secrets in a managed secrets system and rotate them on a defined schedule.
• Log routing decisions, model targets, and credential use in a form that supports investigation.
• Validate prompts and outputs before and after routing to reduce injection and exfiltration risk.

This also intersects with OWASP guidance on AI application abuse and with platform-level identity controls. OWASP’s evolving guidance for agentic and LLM-enabled systems is useful here because routers often behave like autonomous decision points, even when they are not full agents. For threat modelling, teams should also consider whether a compromised router could be used to pivot into prompt stores, tool calls, or billing controls. OWASP LLM Top 10 and CISA guidance for generative AI both reinforce the need for least privilege and strong monitoring.

These controls tend to break down when the router must support many providers with different auth models because token sprawl and inconsistent logging make ownership and revocation ambiguous.

Common Variations and Edge Cases

Tighter credential isolation often increases operational overhead, requiring organisations to balance security assurance against routing flexibility and deployment speed. That tradeoff is most visible in multi-tenant platforms, rapid experimentation environments, and teams that switch providers frequently.

There is no universal standard for router identity design yet. Some organisations use one credential per application, while others go further and issue separate credentials per workflow, user segment, or model family. The safer pattern depends on how sensitive the prompts are, whether the router can reach tools or retrieval systems, and whether the service handles regulated data. Where routers mediate access to personal data, payment data, or confidential business content, stronger segregation is usually justified.

Edge cases appear when routers also perform caching, fallback, or content moderation. Those functions may require additional permissions that widen the attack surface if bundled into one token. Best practice is evolving toward decomposing these functions so the routing identity cannot also read logs, modify policies, or administer billing. In AI-heavy environments, this is where NHI governance becomes essential: the router is not just an app component, but a machine identity with real authority. For control mapping, teams can anchor this to the broader structure of NIST Cybersecurity Framework 2.0 while still adapting to the specific provider model.

Related resources from NHI Mgmt Group

• Why do AI models create new IAM and NHI risks?
• Why do AI coding assistants create new NHI governance risks?
• Why do AI frameworks create new NHI governance risks?
• Why do AI agents create new IAM risks even when the model output looks acceptable?