A router is a capability dispatch layer that maps a requested tool to the correct backend service. It can discover and forward requests efficiently, but it does not know who is calling or whether the caller is authorised. That makes it suitable for internal discovery, not for enforcing enterprise policy or accountability.
Expanded Definition
In NHI and agentic systems, a router is the dispatch function that receives an intent or task request and forwards it to the most appropriate backend service, tool, or model path. It improves discoverability, reduces hard-coded coupling, and can make orchestration more efficient, but it is not an identity control. A router does not establish who the caller is, what privilege they hold, or whether the requested action should be allowed. That distinction matters because routing logic is often mistaken for enforcement logic, especially when teams use it as a convenient central point for internal traffic decisions.
Definitions vary across vendors, but the security boundary is consistent: routing selects a destination, while access governance decides whether execution is permitted. For that reason, routers should be treated as application plumbing within a wider control plane that also includes authentication, authorisation, policy evaluation, and audit logging. NIST’s NIST Cybersecurity Framework 2.0 reinforces this separation by tying access decisions to governance and protective outcomes rather than to transport mechanics alone. The most common misapplication is treating the router as an enforcement point, which occurs when teams assume that correct tool selection also implies caller legitimacy.
Examples and Use Cases
Implementing routers rigorously often introduces a control-plane dependency, requiring organisations to balance fast service selection against the cost of adding explicit policy checks elsewhere. In practice, that tradeoff is worth it when the environment includes multiple tools, multiple model endpoints, or changing backend routes.
- An AI agent submits a task to a router that sends code analysis requests to a static-analysis service and summarisation requests to a language model, while a separate policy layer approves the action.
- A developer portal uses a router to direct internal API calls to the right microservice, but service-account authentication and RBAC are handled upstream, not inside the router.
- A procurement workflow routes document extraction tasks to one backend and compliance classification tasks to another, with audit logging attached to the execution layer.
- A multi-tenant platform uses a router for capability discovery, but tenant boundaries are enforced through identity-aware controls and scoped credentials, not routing rules alone.
For broader NHI context on why dispatch layers can be deceptive when credentials are weak or overly broad, see Ultimate Guide to NHIs. In orchestration-heavy stacks, router design is often discussed alongside model selection and tool access in the NIST Cybersecurity Framework 2.0, but the framework itself does not treat routing as a substitute for identity assurance.
Why It Matters in NHI Security
Routers matter because they can create a false sense of control. A system may appear orderly if every request passes through a single dispatch layer, yet that layer still cannot prove the requester is authorised, rotate credentials, limit privilege, or enforce separation of duties. In NHI environments, those gaps are operationally dangerous because compromised service accounts, API keys, or agent credentials can still reach high-value tools if the router is trusted too broadly. NHIMG data shows that Ultimate Guide to NHIs reports only 5.7% of organisations have full visibility into their service accounts, which makes any routing-centric design even harder to govern reliably.
Practitioners should treat routers as part of the execution path, not the trust decision. They need companion controls for secret management, short-lived credentials, least privilege, and post-route authorisation checks, especially in agentic systems where tools can be chained quickly. Organisationally, the risk becomes visible only after an unintended tool call, credential misuse, or cross-domain data exposure, at which point the router becomes operationally unavoidable to review and constrain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Routers in agentic systems can hide unsafe tool selection and execution paths. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Routing is not identity control; NHI guidance separates dispatch from trust decisions. |
| NIST CSF 2.0 | PR.AA-2 | Identity proofing and access governance must occur outside simple request routing. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires policy checks at each access request, not trust in the router. |
| CSA MAESTRO | T2 | MAESTRO separates orchestration, tool use, and security controls for agentic workflows. |
Use the router only for forwarding and enforce per-request policy at the control point.
Related resources from NHI Mgmt Group
- How should security teams verify JWTs in Next.js App Router apps?
- How should security teams implement authentication in React Router apps with server-side rendering?
- Why do browser-based auth patterns break down in React Router v7?
- What do security teams get wrong about enterprise authentication for React Router apps?
