Third-party model routing is the practice of sending a user’s prompt from one AI front end to an external model provider for inference. It matters because the routing layer and the model provider may have different logging, retention, and training policies. Security teams should trace the full request path before approving sensitive use.
Expanded Definition
Third-party model routing describes an AI front end that forwards prompts to an external model provider for inference, usually because the routing layer is abstracting model choice, cost, latency, or feature differences. In NHI security, the key issue is that the routing service, the upstream application, and the external model provider may each handle data differently, with separate logging, retention, training, and access controls. That makes the routing path part of the trust boundary, not just a transport detail. Definitions vary across vendors, especially when routing includes fallbacks, model brokerage, prompt enrichment, or policy enforcement. The relevant security question is not which model answered, but which systems saw the prompt, what credentials were used, and whether the prompt contained secrets or regulated data. This aligns with the OWASP Non-Human Identity Top 10, which treats non-human access paths as governance surfaces that must be controlled end to end. The most common misapplication is treating model routing as a harmless proxy, which occurs when teams approve sensitive prompts without verifying downstream retention and training behavior.
For a broader NHI governance baseline, see the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.
Examples and Use Cases
Implementing third-party model routing rigorously often introduces added review overhead, because every provider hop can change data handling obligations and incident response scope, requiring organisations to weigh flexibility against auditability.
- A customer support chatbot routes sensitive tickets to a higher-capability external model only after a policy engine strips secrets and personal data.
- An internal developer assistant sends code prompts to a third-party model, but the security team blocks routing for repositories that contain API keys or production credentials.
- A multi-model gateway fails over from one provider to another during outage conditions, and governance must confirm that both providers have acceptable retention settings.
- A regulated enterprise uses routing to classify prompts by sensitivity, sending low-risk requests externally while keeping confidential workflows on a private model path.
- A procurement review inspects whether the model broker logs prompts, metadata, and authentication context in a way that would expose NHIs during an investigation.
These use cases map directly to lessons seen in supply chain and credential exposure reporting such as the 52 NHI Breaches Analysis and the LiteLLM PyPI package breach. For implementation context, the model broker pattern should also be evaluated against identity and access expectations described in the OWASP Non-Human Identity Top 10.
Why It Matters in NHI Security
Third-party model routing matters because it can silently expand the set of parties that receive prompt content, authentication artifacts, and operational metadata. In practice, that means an NHI such as an API key, service token, or workload identity may be accepted by the routing layer but still exposed to downstream systems that have different logging or retention defaults. NHIMG research shows that 92% of organisations expose NHIs to third parties, raising supply chain risk, and that pattern becomes especially dangerous when prompts include credentials or sensitive business context. Routing also complicates containment: if a provider, broker, or plugin is compromised, responders need to know which requests traversed that path and which secrets were exposed. This is why routing policy should be treated as identity governance, not just application architecture. The same logic appears in incidents such as the JetBrains Marketplace AI Plugin Campaign and the Mastra npm Supply Chain Attack, where trust in the integration layer created exposure. Organisations typically encounter the need to classify and trace model routing only after a leak, at which point the routing path becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret handling and exposure across non-human request paths. |
| NIST CSF 2.0 | PR.AC-1 | Access control must extend to machine-to-machine routing and brokers. |
| NIST Zero Trust (SP 800-207) | SC.ZT-1 | Zero Trust requires continuous verification across each provider hop. |
| NIST AI RMF | GV.2 | AI governance should account for external model dependencies and data flows. |
| OWASP Agentic AI Top 10 | LLM-03 | Agentic workflows can forward prompts to third parties without adequate containment. |
Verify each routing decision and downstream provider trust decision separately, not once at the edge.
Related resources from NHI Mgmt Group
- What breaks when an AI security tool depends on a third-party foundation model?
- How do third-party SaaS integrations create NHI risk and how should they be managed?
- What are the implications of using OAuth tokens in third-party integrations?
- How should security teams govern third-party AI agents that use OAuth access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
