Resources
The MCP registry and gateway decide who may use which server; the MCP runtime creates isolated instances on demand on the ToolHive Kubernetes Operator and destroys them after use. Every tool call still goes through policy, DLP and approval.
Every file sent to the AI is quarantined, scanned by ClamAV and YARA-X and then validated before Docling, OCR or RAG can read it. Fully local, fail closed, logged and highly available.
How Navin Enterprise AI keeps autonomous agents under control: OPA policies stacked from platform to tenant to project, approvals with a human in the loop, a kill switch available at any time and a governance registry as the single source of truth.
Every call that crosses a Navin Enterprise AI gateway carries a W3C traceparent and produces OpenTelemetry spans, a Usage Event and an audit event chained by hash. Here is how the chain is built, sealed, archived in WORM storage and replayed.
Navin Enterprise AI tracks the cost of every model call in three stages: estimated before the call, measured afterwards from the Usage Event, then reconciled with the provider invoice. Token accounting, a pricing registry and quotas keep the cycle under control.
Autoscaling with HPA and KEDA, event triggers on NATS JetStream, durable checkpoints, quotas and GPU accounting: how Navin Enterprise AI runs many agents without losing work or control, with high availability declared per service.
A request to Navin Enterprise AI crosses the portal, the APISIX gateway with Coraza and the OWASP CRS, Cilium policies and then the Control Plane, and no layer assumes that the previous one did its job. This guide reviews each control, from the CSP nonce to PostgreSQL RLS.
From a single brick to a fully air-gapped cluster: the five deployment topologies of Navin Enterprise AI, the GitOps supply chain with signed images, and OS packages with offline archives for Debian, Ubuntu, the RHEL family and Arch Linux.