Transparence et limites

Une plateforme qui gouverne les agents IA de votre infrastructure est un produit de sécurité. Si elle surestime ce qu’elle couvre, elle donne un faux sentiment de sécurité — ce qui est pire que pas d’outil du tout. Cette page est donc le contrat explicite : ce qui fonctionne aujourd’hui, ce qui est en phase de conception, et ce qui est hors périmètre intentionnellement. Le reste de la documentation s’y tient. Là où le produit ne couvre pas encore quelque chose, la page le dit plutôt que de l’impliquer.

Olivares AI est pré-1.0 et open-core. Considérez la profondeur au niveau des modules comme un travail en cours sauf indication contraire.

Ce qui fonctionne aujourd’hui

• Un binaire unique démarre avec un graphe d’accès peuplé. Le binaire du plan de contrôle se compile en un seul artefact statique avec l’interface web embarquée. Le démarrer contre l’environnement de démonstration synthétique et parcourir découverte → graphe R/RW → dérive permis-vs-observé → inventaire est exercé de bout en bout par la suite de tests. Le démarrage rapide reproduit ce chemin.
• Le premier lancement est sans identifiant. Une installation neuve n’a aucun identifiant par défaut. Au premier démarrage, sans utilisateurs, le moteur génère un token de configuration unique à usage unique et l’affiche sur stdout (jamais dans les logs) ; vous l’échangez pour créer le premier administrateur.
• L’API REST et le registre d’audit sont réels. La surface publique est décrite par le propre contrat OpenAPI 3.1 du produit. Le registre d’audit est append-only et chaîné par hash, avec des points de contrôle signés, et peut être exporté aux formats SIEM pour re-vérification hors ligne.
• La signature des releases est construite et se vérifie hors ligne — les preuves seront publiées avec la première release publique. Chaque release taguée porte des signatures cosign, une provenance SLSA, et des SBOM (SPDX et CycloneDX). Tout cela peut être vérifié sans accès réseau. La signature par clé (non-OIDC) est supportée pour les pipelines de build air-gappés, et un bundle air-gap est livré pour les installations sans sortie réseau.

Ce qui est en phase de conception ou pré-1.0

Le catalogue comprend 29 modules ; tous sont câblés dans une installation standard aujourd’hui. Voir la référence des modules pour le statut par module.

La fidélité de la carte R/RW est graduée, par conception

La fidélité dépend de ce que la source peut prouver, et la carte d’accès le montre honnêtement plutôt que de feindre la certitude. Voir fidélité pour le modèle complet.

• La couverture est clean sur les stores avec audit natif (SQL, object storage, entrepôts/lacs de données), lossy sur les document stores et vector stores où les arêtes existent mais sont grossières, et opaque là où il n’y a aucun signal passif lecture/écriture (par exemple Redis, SQLite, D1). Là où la distinction lecture/écriture ne peut pas être déterminée, l’arête est marquée unknown.
• L’attribution est firm quand une source porte une identité par agent, et se réduit à approximate quand un compte de service partagé la masque. Tout ce qui est non résolu reste approximate — jamais silencieusement promu en agent fabriqué.

Sources : observateurs hôte câblés ; certains connecteurs chargés à la demande

La racine de composition enregistre les observateurs R/RW au niveau hôte dans le chemin serve standard, configurables via la config des sources. Plusieurs connecteurs source sont construits mais pas encore câblés dans le serve standard — par exemple les sources de documents de connaissance, qui sont chargées à la demande par les requêtes d’ingestion plutôt que de fonctionner comme des observateurs permanents. Le guide de connexion de source et la référence des modules indiquent lesquels sont lesquels.

Le défaut est un binaire unique ; le bus distribué est opt-in

L’installation par défaut fonctionne comme un binaire unique avec un bus d’événements in-process — contre-pression bloquante, pas de perte locale. Un pont NATS distribué est construit et câblé pour le HA scale-out, opt-in via la config du bus ; un bus mal configuré échoue au démarrage plutôt que de partitionner silencieusement. La livraison inter-nœuds via le pont est documentée honnêtement comme at-most-once (la capture in-process est la frontière de durabilité) ; les pertes sont comptées dans les métriques, jamais silencieuses.

L’actionnement gouverné a trois états honnêtes

La plateforme observe et gouverne largement ; elle n’actionne pas largement. Lisez permis vs observé pour comprendre pourquoi cette ligne compte. L’actionnement tombe dans trois états :

• Live dans le binaire par défaut, sans provisionnement : application budgétaire FinOps (un budget actif à son plafond refuse la dépense — in-process, toujours câblé), dispatch de notifications une fois qu’une destination est configurée, découvertes détectives de sécurité, et le runner de sandbox synthétique in-process.
• On-demand — backend construit et câblé, mais fermé par défaut ou dégradé jusqu’à ce qu’un opérateur le provisionne : deploy apply/retire (un 503 jusqu’à ce qu’un exécuteur soit provisionné), orchestration fire et dispatch voice (fermé par défaut jusqu’à ce qu’un dispatcher soit configuré), le runtime isolé sandbox/red-team (synthétique jusqu’à provisionné), et exécution de modèle (un 503 jusqu’à ce qu’un identifiant d’inférence soit configuré).
• Seam — une interface déclarée et fermée par défaut sans backend encore.

L’air-gap s’applique au plan de contrôle, pas à l’inférence Claude

C’est la réserve la plus importante. Le plan de contrôle — gouvernance et observation — fonctionne entièrement auto-hébergé et peut être air-gappé : nœud unique, release signée hors ligne, bundle air-gap.

Claude lui-même n’est pas auto-hébergeable. Anthropic ne publie pas les poids, donc toute inférence Claude atteint l’API d’Anthropic, directement ou via Bedrock / Vertex / Foundry. Dans Olivares AI, ces points d’inférence échouent en fermé : sans identifiant d’inférence, le juge LLM reste ignoré et les embeddings basculent sur un embedder local à zéro sortie. « Air-gappé » ici signifie que votre plan de gouvernance et d’observation et ses données restent dans votre périmètre — cela ne signifie pas que Claude fonctionne hors ligne. Seuls les modèles que vous hébergez véritablement (par exemple via vLLM ou Ollama sous le module de gestion des modèles) peuvent fonctionner air-gappés ; les modèles frontière courtiers ne le peuvent pas. Voir connecter Claude Code et sécurité.

Toutes les routes de modules ne sont pas dans le contrat API public

Certains endpoints de modules (par exemple le graphe de la carte d’accès et la dérive) sont accessibles mais ne font délibérément pas partie du document OpenAPI servi ; leurs contrats au niveau des champs vivent dans les interfaces typées du produit. La CLI et la configuration de référence couvrent la surface opérationnelle ; le contrat OpenAPI est la surface REST principale, pas le produit entier.

Non certifié

Olivares AI est conçu en vue de SOC 2, ISO 27001, et l’AI Act européen — il n’est pas certifié contre aucun d’entre eux. Voir conformité pour ce que « conçu en vue de » signifie et quelles preuves la plateforme produit.

Ce que le produit ne fait délibérément pas

• Pas de fonctionnalités offensives. Ce n’est pas un framework de commande et contrôle et il ne scanne pas les identifiants d’autrui. La carte d’accès est de la reconnaissance pour que les défenseurs gouvernent leur propre environnement — la consulter est une action privilégiée, scopée au tenant et entièrement auditée. La ligne défensive est intentionnelle.
• Pas de forwarder Splunk S2S natif. Le transfert vers Splunk est une posture documentée (pointez un Universal Forwarder vers un fichier que le plan de contrôle ajoute, ou poussez via Splunk HEC), pas un émetteur natif Splunk-to-Splunk.
• Pas de webhooks sortants dans le contrat REST. Le document OpenAPI ne définit pas de webhooks. La livraison sortante signée existe comme destination de notification interne, et le endpoint SCIM Security-Event-Token entrant est un récepteur — aucun des deux n’est un webhook OpenAPI.
• Pas de fine-tuning avant v1. Le fine-tuning de modèle (le module de gestion des modèles) est post-v1. Son absence est une décision, pas une lacune.

Note sur l’export d’audit

L’export CLI du registre cible cef, syslog, et otlp. Le chemin de push d’événements vers un SIEM rend un ensemble de dialectes plus large (incluant OCSF et LEEF) quand un sink est configuré. L’export pull est la bonne forme pour l’archivage WORM et la re-vérification hors ligne.

Si vous trouvez une commande qui ne se comporte pas comme documenté, c’est un bug dans la documentation ou le produit — signalez-le. Cette page est l’ancre de confiance ; tout le reste s’y réfère.