Architecture · Fonctionnement
Olivares AI s’exécute là où s’exécutent vos agents. La plateforme se déploie comme un artefact auto-hébergé unique, découvre passivement sans s’insérer dans le chemin des requêtes, et le control plane est conçu pour fonctionner entièrement isolé du réseau (air-gap). Voici comment les pièces s’assemblent. L’installation isolée (air-gap) et les mises à jour hors ligne relèvent d’Enterprise. Le chart Helm, l’opérateur Kubernetes et le fournisseur Terraform relèvent de Business.
Comment ça s’exécute
Installez le moteur comme un artefact auto-hébergé unique — un binaire, un conteneur ou sur Kubernetes. La console web est intégrée ; aucun front-end distinct à mettre en place.
Déployez des collecteurs au sein de votre propre infrastructure. Ils ingèrent passivement l’OpenTelemetry émis par vos agents et lisent les journaux d’audit natifs des systèmes qu’ils touchent — lecture d’abord, moindre privilège, émission uniquement.
La plateforme normalise ces signaux en un modèle d’agents, de sessions, de modèles, de serveurs MCP, de ressources et d’identités — et les arêtes d’accès qui les relient, en lecture ou lecture/écriture, chacune assortie d’un niveau de confiance honnête.
Sur cette cartographie, visualisez l’écart entre ce qu’un agent est autorisé à atteindre et ce qu’on l’a observé atteindre, appliquez vos politiques et acheminez les constats vers les outils que vous utilisez déjà — le tout via CLI, API et la console web.
La console, la CLI et l’API envoient des requêtes au moteur. L’identité, les permissions et les politiques déterminent l’accès. Les sessions admises utilisent les pilotes de fournisseurs configurés ; le moteur enregistre leur état et les événements d’audit de leur cycle de vie dans SQLite ou PostgreSQL.
Le cœur Community n’exige pas de licence commerciale. Les modules commerciaux ajoutent des capacités distinctes. L’application des politiques aux outils dépend de l’intégration.
Comment c’est construit
Les collecteurs s’exécutent au sein de votre propre infrastructure et capturent des arêtes et des relations — pas des payloads. Le control plane est auto-hébergé (une option managée figure sur la feuille de route). Les données de gouvernance — inventaire, carte des accès, état des politiques et preuves d’audit — restent par défaut dans une infrastructure que vous contrôlez.
Le moteur est pilotable en CLI d’abord et expose l’intégralité de ses fonctionnalités via une API stable ; la console web est une couche au-dessus de cette même API, livrée intégrée. Vous déployez une seule chose, pas un parc de services.
La plateforme écoute la télémétrie que vos agents émettent déjà et lit les journaux d’audit natifs, plutôt que d’intercepter le trafic. Un SDK de connecteurs stable, sous Apache-2.0, couvre un ensemble croissant de sources — modèles et fournisseurs, runtimes, magasins de données, identité et secrets, observabilité, et destinations de sortie.
La plateforme ingère la télémétrie OTLP et interopère avec la pile d’observabilité que vous utilisez déjà — en exposant des métriques et des points de terminaison de santé standard et en exportant vers les formats SIEM courants. Elle s’insère dans vos pipelines au lieu de les remplacer.
Le control plane auto-hébergé peut fonctionner dans un réseau isolé. Vérifiez les artefacts avant leur transfert : les contrôles keyless Sigstore et SLSA nécessitent un accès réseau. Les contrôles avec la clé de l’opérateur couvrent uniquement les fichiers signés avec cette clé. Les modèles hébergés accèdent toujours à l’API de leur fournisseur ; seuls les modèles que vous hébergez peuvent fonctionner entièrement hors ligne. L’installation isolée et les paquets de mise à jour hors ligne relèvent d’Enterprise.
Lecture d’abord et à risque asymétriquement faible. Les collecteurs n’émettent que vers l’extérieur, sans port d’écoute entrant ; le trafic vers le cœur est mutuellement authentifié par TLS ; seule la donnée minimale est conservée ; le journal d’audit est append-only et toute altération y est détectable ; et l’isolation multi-tenant est intégrée au modèle dès le premier jour.
Les libellés des diagrammes sont en anglais. Les descriptions présentent le parcours complet sur les petits écrans.
Déploiement
Le même produit, déployé selon les besoins de votre environnement.
Le moteur et la console web intégrée comme un artefact auto-hébergé unique — un binaire ou un conteneur, ou installé sur Kubernetes — pour un nœud unique.
Des collecteurs répartis sur de nombreux hôtes alimentant un control plane central doté d’une base de données externe, pour une montée en charge multi-hôte et une exploitation multi-tenant.
Le control plane et les collecteurs s’exécutent en local avec zéro egress et une licence hors ligne, pour les réseaux déconnectés, régulés ou classifiés. Les agents reposant sur des modèles hébergés ont toujours besoin d’un accès sortant vers leur fournisseur ; les agents reposant sur des modèles auto-hébergeables fonctionnent entièrement hors ligne.
Le control plane hébergé par nos soins — tandis que les collecteurs demeurent toujours au sein de votre propre infrastructure.
Les capacités et les options de déploiement dépendent de l’édition et de la configuration ; la documentation décrit chacune d’elles.
Auto-hébergez Community, le produit complet pour une personne ou une équipe, sur votre propre infrastructure, ou parlez-nous d’un déploiement distribué ou isolé du réseau (air-gap). L’installation isolée (air-gap) relève d’Enterprise.