Policy-driven LLM routing

When a tool runs, it can declare a security / LLM scope: which models are allowed to see that tool’s data and continue the turn. Nexus then auto-routes to only those policy-allowed LLMs. A public model that is fine for a weather lookup cannot be used after a tool that pulled confidential plant or HR records.

Why it matters

Enable-and-rank in Settings → LLMs is the workspace default. Tool policy is the override that security teams actually need: the data the tool just fetched decides the model, not the user’s last-used provider. That is how Nexus keeps Private AI models on confidential paths without banning public LLMs for everything else.

How it works

  1. You configure Private AI models and public LLMs, enable them, and rank the default order.
  2. An MCP / tool invocation can specify an LLM scope (for example: private only, a named provider, or a class of models your policy allows).
  3. Nexus intersects that scope with what is enabled in Settings. The turn continues only on a model in that intersection.
  4. If nothing in the catalog satisfies the scope, the tool path does not fall through to a disallowed LLM.

Default ranking still chooses which allowed model to prefer. Policy chooses the set that is allowed at all.

What you can do

  • Let general chat use public LLMs when no sensitive tool has run
  • Require Private AI models (Diode-tunneled, self-hosted or partner-hosted) when a tool reads confidential systems
  • Keep workspace ranking as the operator control; keep per-tool scope as the security control
  • Inspect the route in conversation Show Pipeline when a tool call caused a model switch