The Model Context Protocol lets agents use external tools and data. Navin Enterprise AI separates two concerns: the MCP gateway decides who can reach which server, and the MCP runtime runs isolated server instances, created on demand and destroyed after use.
Registry and gateway
MCP servers are declared in the MCP registry (brick D03) and can only be reached through the MCP gateway (brick D04). Each server has its own access list, and the gateway refuses a server that belongs to another project; that refusal is audited. Tool calls follow the same path as every other call: policy, DLP and approval before execution.
One runtime per user and project
The runtime builds on the ToolHive Kubernetes Operator, licensed under Apache-2.0 and self-hosted, driven by a Navin lifecycle controller. Instances are isolated per user and project, security is enforced from provisioning onwards, and a cleanup task removes idle instances, after 900 seconds by default. Executions can also run inside a gVisor or Kata sandbox (brick C12).
Key characteristics
- One instance per user and project, created on demand and destroyed after use.
- Inactivity timeout of 900 seconds by default.
- Access list per server and project check in the gateway, with audit.
- Kyverno admission policy and Cilium network policies dedicated to the runtime.
- Separate OpenSearch index for runtime logs.
- Secrets passed by reference, never in clear text in the prompt.
- Methods in the four SDKs: Python, TypeScript, Java and Go.
Also hosted from the Navin Manager
Outside Kubernetes, the Navin Manager can host MCP servers with navin-mcp-host: one process per server, one token per server of which only the sha256 is kept, and a path that carries the tenant, the project and the server name. Hosted servers are then synchronized into the platform, with their token stored in the Credential Broker.