Livre blancGouverner les agents IA en production : politiques, approbations humaines et arrêt d'urgence.Lire le livre blanc
NavinAI Platform

Fiche technique · Agents

Des runtimes MCP isolés par utilisateur et par projet

Le registre et la passerelle MCP décident qui peut utiliser quel serveur ; le runtime MCP crée à la demande des instances isolées sur le ToolHive Kubernetes Operator et les détruit après usage. Chaque appel d'outil passe toujours par la politique, la DLP et l'approbation.

Publié le 3 min de lecture

Le Model Context Protocol permet aux agents d'utiliser des outils et des données externes. Navin Enterprise AI sépare deux responsabilités : la passerelle MCP décide qui accède à quel serveur, et le runtime MCP exécute des instances de serveur isolées, créées à la demande et détruites après usage.

Registre et passerelle

Les serveurs MCP sont déclarés dans le registre MCP (brique D03) et ne sont joignables que par la passerelle MCP (brique D04). Chaque serveur a sa liste d'accès, et la passerelle refuse un serveur qui appartient à un autre projet ; ce refus est audité. Les appels d'outils suivent le même chemin que tous les autres : politique, DLP et approbation avant l'exécution.

Un runtime par utilisateur et par projet

Le runtime s'appuie sur le ToolHive Kubernetes Operator, sous licence Apache-2.0 et auto-hébergé, piloté par un contrôleur de cycle de vie Navin. Les instances sont isolées par utilisateur et par projet, la sécurité est imposée dès le provisioning, et une tâche de nettoyage supprime les instances inactives, après 900 secondes par défaut. Les exécutions peuvent en plus tourner dans un bac à sable gVisor ou Kata (brique C12).

Caractéristiques

  • Une instance par utilisateur et par projet, créée à la demande et détruite après usage.
  • Délai d'inactivité de 900 secondes par défaut.
  • Liste d'accès par serveur et contrôle du projet dans la passerelle, avec audit.
  • Politique d'admission Kyverno et politiques réseau Cilium dédiées au runtime.
  • Index OpenSearch séparé pour les journaux du runtime.
  • Secrets transmis par référence, jamais en clair dans le prompt.
  • Méthodes dans les quatre SDK : Python, TypeScript, Java et Go.

Hébergé aussi depuis le Navin Manager

Hors Kubernetes, le Navin Manager peut héberger des serveurs MCP avec navin-mcp-host : un processus par serveur, un jeton par serveur dont seul le sha256 est conservé, et un chemin qui porte le tenant, le projet et le nom du serveur. Les serveurs hébergés sont ensuite synchronisés dans la plateforme, leur jeton étant rangé dans le Credential Broker.

  • Fiche techniqueSécurité

    Analyse obligatoire des fichiers par ClamAV et YARA-X

    Chaque fichier envoyé à l'IA passe en quarantaine, est analysé par ClamAV et YARA-X puis validé avant que Docling, l'OCR ou le RAG ne puissent le lire. Entièrement local, en échec fermé, journalisé et hautement disponible.

    2 min de lecture
  • Livre blancGouvernance

    Gouverner les agents IA en production

    Comment Navin Enterprise AI garde les agents autonomes sous contrôle : politiques OPA empilées de la plateforme au tenant puis au projet, approbations avec un humain dans la boucle, kill switch disponible à tout moment et registre de gouvernance comme source de vérité unique.

    26 min de lecture
  • ArticleTraçabilité

    Une piste d'audit infalsifiable pour chaque appel d'IA

    Chaque appel qui traverse une gateway de Navin Enterprise AI porte un traceparent W3C, produit des spans OpenTelemetry, un Usage Event et un événement d'audit chaîné par hash. Voici comment la chaîne est construite, scellée, archivée en WORM et rejouée.

    3 min de lecture

Voyez ces principes appliqués à vos cas d'usage

Un architecte vous présente la plateforme sur vos propres contraintes.