Olivares AI se trouve-t-il sur le chemin des requêtes de mes agents ?

Non. La découverte et la carte d'accès sont construites hors bande, à partir de la télémétrie et de l'audit natif des sources, de sorte qu'une panne d'Olivares ne peut pas mettre vos agents hors service. Les seules surfaces en ligne sont les gates d'actionnement optionnelles, fermées par défaut (deny-closed), que vous câblez explicitement — et là, un état d'arrêt illisible échoue en mode fermé, jamais ouvert.

Peut-il fonctionner en environnement air-gapped ?

Le control plane d'Olivares le peut. Vos données de gouvernance et d'observation restent à l'intérieur de votre périmètre. La réserve honnête concerne l'inférence des modèles : les modèles hébergés comme Claude joignent toujours l'API de leur fournisseur ; seuls les modèles réellement auto-hébergeables (vLLM, Ollama) fonctionnent entièrement hors ligne.

Qu'arrête réellement le coupe-circuit ?

L'arrêt à l'échelle du parc refuse toute surface d'actionnement gouvernée pour le tenant ; un arrêt limité à un agent ne refuse qu'un seul agent. Il est conçu en lecture d'abord : il ne peut pas atteindre une surface dans laquelle vous n'avez pas câblé de gate. L'enclenchement est peu coûteux et se fait en un clic ; la réactivation exige un double contrôle et une revue a posteriori obligatoire.

Le poste de pilotage des agents IA qui tournent sur votre infrastructure

Vous exploitez déjà les tableaux de bord de tout le reste du parc : hôtes, files d’attente, magasins de données, chemin des requêtes. Puis une douzaine d’agents IA font leur apparition — copilotes, serveurs MCP, tâches planifiées, une instance Claude Code que quelqu’un a branchée sur la production — et vous n’avez aucun endroit unique qui réponde à la première question de l’opérateur : qu’est-ce qui tourne, et qu’est-ce que chaque chose peut réellement atteindre ?

C’est exactement le même schéma que celui de l’infrastructure fantôme non gérée, à ceci près que ces charges de travail détiennent des identifiants et agissent de leur propre initiative. Parmi les organisations ayant subi une violation liée à l’IA, environ 97 % ne disposaient pas de contrôles d’accès à l’IA appropriés (IBM Cost of a Data Breach 2025, Ponemon). Le secteur a désormais un mot pour la cause — l’agent sprawl (prolifération d’agents) — et Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027 (Gartner), souvent parce que personne n’a pu les exploiter en toute sécurité une fois qu’ils se sont multipliés.

Ce qu’obtient un opérateur

Olivares AI est une plateforme ouverte et auto-hébergeable qui tourne là où tournent vos agents. Elle les découvre, construit une carte d’accès en lecture/écriture de ce que chacun touche, et vous donne les contrôles pour gouverner et auditer cet accès. Pour un SRE ou un administrateur système, cinq propriétés comptent plus que la liste des fonctionnalités.

Passif — hors du chemin des requêtes

La découverte est construite hors bande, à partir de la télémétrie et de l’audit natif des sources. La vue santé et fiabilité est un consommateur du bus d’événements, pas une sonde qui ouvre des sockets dans votre infrastructure — la vivacité est déduite de l’activité observée, et un agent qui cesse d’émettre constitue lui-même un signal. Parce qu’Olivares n’est ni un proxy ni un sidecar placé devant vos agents, une panne d’Olivares ne peut pas les mettre hors service. Les seules surfaces qui se trouvent un jour en ligne sont les gates d’actionnement optionnelles que vous choisissez de câbler, et celles-ci échouent en mode fermé.

Un seul binaire statique auto-hébergé

Le déploiement se fait sous la forme d’un unique binaire statique avec la console web embarquée — aucune flotte d’agents à déployer, aucun opérateur Kubernetes de control plane à surveiller. Le magasin est du SQLite pur-Go (Postgres pour le multi-tenant), il n’y a donc aucune chaîne d’outils C contre laquelle se battre. Vous installez un seul fichier, vous l’exécutez sous un utilisateur de service dédié, et vous disposez du poste de pilotage. Voir installation et auto-hébergement.

Le control plane tourne à l’intérieur de votre périmètre et peut fonctionner en air-gapped — vos données de gouvernance et d’observation ne le quittent jamais. Une réserve que les opérateurs doivent garder à l’esprit : ce n’est pas de l’IA hors ligne. Les modèles hébergés comme Claude joignent toujours l’API du fournisseur ; air-gapped signifie que les données de votre parc restent chez vous, pas que le modèle s’exécute en local. Seuls les modèles réellement auto-hébergeables (vLLM, Ollama) fonctionnent entièrement hors ligne. Pour en savoir plus : sécurité et architecture.

Ingestion OTel-native

Le chemin d’ingestion s’appuie sur les conventions sémantiques GenAI d’OpenTelemetry aux côtés d’OCSF, des formats SIEM et de W3C Trace Context — de sorte que la télémétrie que vous émettez déjà est celle qu’il lit. Une limite honnête : Olivares corrèle votre registre d’événements gouvernés par le trace_id W3C ; il ne stocke pas les spans OTel complets. Les durées et les statuts de la vue trace sont des fenêtres d’événements du registre, et non des données de span reconstruites. Les spans complets restent dans votre propre collecteur OTLP, là où est leur place. Olivares vous dit qui a touché à quoi et si c’était autorisé — ce n’est pas un remplaçant de votre backend de tracing. (Voir la page comparatif pour son positionnement face à LiteLLM/Langfuse.)

Sondes et santé, comme n’importe quel service que vous exploitez

Le binaire expose les endpoints que votre orchestrateur attend déjà :

GET /livez     liveness  — le processus est-il actif
GET /readyz    readiness — sert-il (et n'est-il pas un standby à froid)
GET /healthz   liveness exemptée du setup, pour les scrapers
GET /metrics   exposition Prometheus

/readyz renvoie 503 lorsque le magasin sous-jacent est injoignable, plutôt que de rester bloqué, de sorte qu’un répartiteur de charge draine le nœud au lieu de l’engloutir dans un trou noir. Par-dessus cela, le module XXII suit la santé, le SLA et la disponibilité des agents et des serveurs MCP eux-mêmes — ce qui est sain, ce qui est dégradé, et ce qui dépend de quoi — et émet des findings « down / dégradé / rétabli / violation de SLA » vers votre rail existant (Slack, PagerDuty, SIEM). Il produit le signal ; il ne cherche pas à être votre système de notification.

Lecture d’abord, avec un véritable arrêt à l’échelle du parc

Olivares est détectif par défaut et fermé par défaut (deny-closed). Il observe et gouverne largement ; il n’actionne pas largement. Mais quand un agent dérape à 3 h du matin, un opérateur a besoin d’un seul levier qui fonctionne sans cérémonie — c’est pourquoi le coupe-circuit est réel et conçu pour servir :

L’enclenchement est peu coûteux. Niveau admin, un motif obligatoire, un clic. Il n’y a ni gate d’approbation ni élévation de privilèges à l’enclenchement — un arrêt d’urgence qui attend un quorum n’est pas un arrêt. La portée à l’échelle du parc refuse toute surface d’actionnement gouvernée pour le tenant ; la portée agent arrête un agent sur toutes les surfaces où il peut être nommé.
La réactivation ne l’est pas. Lever un arrêt exige un double contrôle (deux personnes distinctes) et est suivi d’une revue a posteriori obligatoire qu’une troisième personne, non impliquée, doit signer. « Le parc reste arrêté » est l’état sûr.
Il échoue en mode fermé. Chaque gate d’actionnement consulte l’état d’arrêt en direct à chaque appel et refuse en cas d’erreur de lecture — un état d’arrêt illisible ne signifie jamais « vas-y ».

Soyez honnête avec vous-même quant à la portée : l’arrêt n’est aussi large que les gates que vous avez câblées. Il ne peut pas geler une surface dans laquelle Olivares n’a aucun point d’ancrage. C’est le compromis délibéré d’un système en lecture d’abord — et c’est pourquoi la découverte et la carte viennent en premier.

Ce que c’est — et ce que ce n’est pas

C’est un poste de pilotage passif et auto-hébergé : découvrir les agents, cartographier leur accès en lecture/écriture, surveiller leur santé, et garder un arrêt à l’échelle du parc à un clic.
Ce n’est pas un proxy en ligne, un backend de tracing, ni un système qui recâble silencieusement vos agents. L’actionnement se fait sur option, à la demande, et fermé par défaut (deny-closed) — vous câblez chaque point d’ancrage délibérément.
C’est un produit pré-1.0 et open-core. Le catalogue répertorie 23 modules de capacités ; une vingtaine sont câblés aujourd’hui, le reste est au stade de conception ou post-v1. La référence des modules indique ce qui est en service.
Ce n’est pas certifié. Olivares est conçu en visant SOC 2, ISO/IEC 42001 et l’EU AI Act — il ne détient pas ces certifications, et ne prétendra pas les détenir. Voir sécurité pour la posture honnête.
La fidélité est échelonnée et présentée comme telle. La couverture lecture/écriture est clean sur les magasins dotés d’un audit natif, lossy sur certains magasins de documents/vecteurs, et unknown là où elle ne peut pas être reconstruite passivement (Redis, SQLite, D1) ; l’attribution par agent est firm uniquement quand le signal le permet, approximate derrière un compte partagé. Rien n’est deviné. Voir fidélité.

Par où commencer

Mettez-le en place : auto-hébergement, puis le démarrage rapide pour un parc synthétique.
Câblez votre premier signal : connecter une source.
Comprenez le modèle : autorisé vs observé et la carte d’accès.
Personas proches de l’opérateur : ingénierie de plateforme et responsables sécurité.