Qu'est-ce qu'Olivares AI ?

Olivares AI est une plateforme ouverte et auto-hébergeable qui répond à une question que la plupart des équipes ne peuvent pas répondre aujourd’hui : quels agents IA fonctionnent sur mon infrastructure, et que peut réellement atteindre chacun d’entre eux ?

Elle fonctionne là où vos agents fonctionnent, les découvre passivement, et construit une carte d’accès lecture/écriture — pour chaque agent, les ressources qu’il peut toucher et s’il peut les lire ou les lire et écrire. À partir de là, vous pouvez gouverner cet accès et prouver, après coup, exactement ce qui s’est passé.

La carte d’accès lecture/écriture

La carte est le cœur du produit (module III). Chaque agent IA devient un nœud ; chaque ressource qu’il peut atteindre — une base de données, un object store, un serveur MCP, une API — devient aussi un nœud ; et chaque arête est typée R (lecture) ou RW (lecture/écriture).

Cette distinction lecture-versus-écriture est le point central. Un agent qui ne peut que lire un store de production est un rayon d’impact très différent de celui qui peut l’écrire. La carte rend cette différence explicite au lieu de la laisser enfouie dans des politiques IAM dispersées.

Permis vs Observé

Ce qui distingue la carte est la différence entre deux couches :

• Permis — ce qu’un agent est autorisé à toucher, d’après les autorisations et la politique.
• Observé — ce qu’il a effectivement été vu en train de toucher, d’après la télémétrie.

Les comparer fait remonter deux découvertes qui comptent :

• Accès inattendu — observé mais jamais attendu. La chose que vous voulez détecter.
• Autorisations inutilisées — permises mais jamais exercées. Votre liste de nettoyage du moindre privilège.

Transparent sur ce qu’il peut prouver

La carte ne fabrique jamais de certitude. La fidélité est graduée et affichée comme telle :

• La couverture de lecture-vs-écriture est clean sur les sources avec audit natif (PostgreSQL via pgAudit, object storage via CloudTrail, entrepôts et lacs de données), lossy sur certains document/vector stores, et opaque là où elle ne peut simplement pas être reconstituée passivement (Redis, SQLite, D1) — l’arête est alors marquée unknown plutôt que devinée.
• L’attribution est firm quand une source porte une identité par agent et se réduit à approximate quand un compte de service partagé masque qui a fait quoi.

Vous voyez toujours combien le produit sait réellement : les niveaux sont affichés dans l’interface plutôt que masqués, donc une arête clean/firm et une unknown/approximate ne sont jamais présentées comme la même chose.

Auto-hébergé et open-core

Olivares AI est open-core : le produit complet est libre et open source sous AGPL-3.0 — pas une édition communautaire allégée. Il se déploie comme un binaire statique unique avec la console web embarquée.

Le plan de contrôle fonctionne dans votre propre infrastructure et peut fonctionner air-gappé — vos données de gouvernance et d’observation ne quittent jamais votre périmètre. Une réserve honnête : les modèles hébergés comme Claude ne sont pas auto-hébergeables, donc toute inférence de modèle atteint toujours l’API du fournisseur (directement ou via Bedrock/Vertex/Foundry). « Air-gappé » signifie que les données de votre environnement restent chez vous, pas que le modèle fonctionne hors ligne. Seuls les modèles véritablement auto-hébergeables (par exemple via vLLM/Ollama) fonctionnent entièrement hors ligne.

Où en est le produit aujourd’hui

La plateforme est pré-1.0. Elle livre un catalogue de 29 modules de capacités, tous raccordés dans une installation standard aujourd’hui. Le produit est lecture d’abord et détective par défaut — il observe et gouverne, et là où il peut agir, il le fait fermé par défaut. Rien ici ne prétend faire quelque chose que le code ne fait pas.

Prêt à le voir ? Commencez par le démarrage rapide.