Auto Discovery

In Perimeter Managed mode, Nexus does not ask you to type Diode address:port for every model and tool. Your IT team gives the workspace ZTNA access to the infrastructure it is allowed to see. Your AI lead then configures which of those discovered LLMs, tools, and Insights this workspace — and the channels that serve customers and connections — should actually use.

Auto-discovery is the Discover flow on Settings → LLMs and Settings → Tools. It is available when the Diode Client is Perimeter Managed.

Why it matters

Policy is easy when nobody copies hostnames into a form. DevSecOps publishes approved Private AI, MCP, and related services into a ZTNA perimeter. The AI lead picks from what discovery found, enables and ranks them, and attaches channels. Users and customers never see the bind list — they just get a workspace whose mix matches the use case.

Two jobs, two personas

Persona What they do Where
IT / DevSecOps Provision the perimeter, ACLs, and port ranges. Publish the LLM, tool, and Insight services this team is allowed to reach. ztna.diode.io (and, for some deployments, Global Settings perimeter override per tenant)
AI lead (Owner / Admin) Turn on Perimeter Managed, Discover what IT published, add Diode Auto connections, enable/rank models, toggle tools, set policy-driven routing, and wire channels. Settings → Diode Client, then LLMs, Tools, Insights, Channels

Users and customers (Diode Collab zones, web embed, Vibe / ACP, OpenAI-compatible API) consume that mix. They do not Discover.

What IT gives you

  1. A ZTNA perimeter — join address from ztna.diode.io. ACLs and policies on that perimeter decide who may connect and which binds exist.
  2. Published infrastructure — Private AI endpoints, MCP tool servers, and other services as Diode binds in the port range assigned to this workspace.
  3. Base infrastructure that is already allowed — the workspace can only Discover what the perimeter actually exposes. Nothing extra is guessed from the public Internet.

On the Nexus side, Perimeter Managed hides manual address:port. Discovery is the only Diode path for new LLMs and tools. Pipeline Managed is the opposite: no Discover button; you type binds yourself.

What the AI lead configures

  1. Settings → Diode Client — Perimeter Managed on; join the perimeter IT provided (unless Global Settings already overrode it).
  2. Discover on Add LLM / Add Tool — Nexus lists perimeter binds, probes each one, and shows Found LLM or Found Tool. Add it as a Diode Auto connection (no raw localhost URL in the UI).
  3. Shape the mix — enable and rank Private AI models and public LLMs; enable or disable MCP tools (refresh / rediscover lists the tools on that server); attach Insights (guardrails and enrichers such as PII handling).
  4. Use case routing — policy-driven LLM routing so a sensitive tool cannot continue on a disallowed model.
  5. Connections — Channels for Collab, embed, ACP (including Vibe), and the OpenAI-compatible API so customers and apps get that same mix.

Rediscover on an existing MCP server re-lists tools without re-entering the connection. Binds outside the workspace port range are listed as invalid, not offered as Found.

How discovery decides LLM vs tool

The Discover panel asks the running Diode Client for perimeter binds, then probes each local port (LLM handshake vs MCP initialize / tools/list on HTTP /mcp). Only matches for the modal you opened are offered (Add this LLM vs Add this Tool). Ports already used by another entity are skipped.

The Diode Client and Nexus need to see the same localhost ports those binds land on — typically the same host as the workspace container. If a probe times out, the bind can still work in chat once added; refresh Discover after the service is up.