Le problème : on ne peut pas gouverner ce que l’on ne voit pas
Les agents sont déjà là. Un assistant de code avec une identifiant de base de données, un service RAG interne qui a discrètement obtenu un accès en écriture à un object store, une tâche planifiée qui appelle un serveur MCP que personne n’a enregistré. Ils ont été provisionnés par des équipes qui avançaient vite, et l’organisation sécurité hérite du rayon d’impact sans jamais en avoir vu la cartographie. Les analystes ont un nom pour cette forme — la prolifération d’agents (« agent sprawl ») — et le déficit de gouvernance qui la sous-tend est mesurable.
Parmi les organisations ayant subi une compromission liée à l’IA, environ 97 % ne disposaient pas de contrôles d’accès IA adéquats (IBM Cost of a Data Breach 2025, Ponemon). Ce n’est pas une histoire de maturité d’outillage ; c’est l’absence d’une surface de contrôle. Dans le même temps, Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027, et projette que les « agents gardiens » représenteront 10 à 15 % du marché de l’IA agentique d’ici 2030 (Gartner, presse) — le marché intègre le fait que des agents non gouvernés ne survivent pas au contact d’un véritable examen de sécurité.
Le phénomène dépasse les équipes sécurité. Dans une étude préliminaire, pas encore revue par les pairs, environ 95 % des pilotes de GenAI n’ont montré aucun impact mesurable sur le compte de résultat, et les outils achetés en externe ont réussi environ deux fois plus souvent que les développements internes (MIT « GenAI Divide », projet NANDA, via Fortune, août 2025 — préliminaire). Quelle qu’en soit la cause, un parc rempli d’agents dont personne ne peut rendre compte est exactement la condition dans laquelle se cumulent le risque de compromission et le risque de pilote gaspillé.
Cela s’inscrit clairement dans le cadre AI TRiSM — trust, risk and security management for AI — où la gouvernance et l’inspection à l’exécution constituent des couches distinctes. Olivares AI est conçu pour être la couche qui découvre, observe et gouverne l’accès des agents, et il est honnête sur les limites de ce périmètre.
Ce qu’Olivares AI apporte à un responsable sécurité
Une cartographie typée des accès lecture/écriture comme surface de contrôle
La cartographie des accès modélise chaque agent comme un nœud et chaque ressource qu’il peut atteindre — bases de données, object stores, serveurs MCP, API, files d’attente — comme un nœud, chaque arête étant typée R (lecture) ou RW (lecture-écriture). Ce typage R-versus-RW est l’essentiel : la dérive du moindre privilège et le rayon d’impact d’un incident sont tous deux fonction de l’accès en écriture, et non de la simple connectivité, et une liste plate « a accès » masque précisément cela. C’est de la reconnaissance pour les défenseurs — la même cartographie qu’un attaquant voudrait, construite pour ceux qui défendent le parc.
Lire le graphe complet est délibérément une action privilégiée, cantonnée au tenant, et intégralement auditée, car une cartographie complète de ce que chaque agent peut atteindre est elle-même une feuille de route de reconnaissance. La cartographie stocke la relation — origine, ressource, R/RW, source, niveau de confiance, horodatages — et jamais les charges utiles, corps de requêtes SQL, secrets ou données personnelles qui ont transité par l’arête. Ce qui n’est pas stocké ne peut pas fuiter.
Autorisé vs observé : le diff qui devient un constat
Chaque arête porte deux faits indépendants : si l’accès est autorisé (une habilitation ou une politique le permet) et s’il a été observé (la télémétrie et l’audit natif montrent qu’il a lieu). Le diff entre ces deux couches est le signal de contrôle :
- Accès inattendu — observé mais non autorisé. Un agent a touché quelque chose qu’aucune habilitation ne couvre. C’est l’élément marquant du point de vue sécurité.
- Habilitations inutilisées — autorisées mais jamais observées. Votre liste concrète de nettoyage du moindre privilège, pas un vague rappel « revoyez votre IAM ».
Le diff est délibérément conservateur. Là où la plateforme ne peut pas encore relier
fermement un identifiant agissant à l’agent pour lequel son habilitation a été écrite,
l’arête est marquée reconciliation_pending — une incertitude honnête, jamais une
violation fabriquée. Voir autorisé vs observé
pour le contrat de réconciliation complet.
Une fidélité qui refuse de bluffer
Un outil de sécurité qui surestime ce qu’il sait est pire que rien. Chaque arête porte
deux axes honnêtes. La couverture de la classification R/RW est échelonnée
clean | lossy | opaque — clean là où l’audit natif la rend non ambiguë (Postgres
via pgAudit, object storage via CloudTrail, les entrepôts, plus un filet de sécurité
eBPF au niveau du noyau), jusqu’aux stores opaque (Redis, SQLite, D1) où le mode est
marqué unknown plutôt que deviné. L’attribution est firm là où un signal
d’identité par agent résout l’accès à un seul agent, et approximate là où un compte
de service partagé masque quel agent a agi. Une arête clean/firm et une arête à
peine observée ne sont jamais rendues comme aussi certaines l’une que l’autre — lisez
le modèle de fidélité.
Gouvernance deny-closed, double contrôle et coupe-circuit
La gouvernance est read-first et deny-closed. Le cœur d’autorisation est deny-by-default et cantonné au tenant, fermant par construction les classes de confused deputy et d’IDOR. Toute politique à base d’attributs que vous greffez par-dessus ne peut que restreindre davantage — la composition est une intersection, de sorte qu’une politique ne peut jamais élargir une habilitation.
Là où le produit place un point de validation sur une action, la boucle est la
suivante : une surface présente (une dérive, un constat) → un opérateur autorisé
décide → la décision est enregistrée. Le moteur d’approbation applique la séparation
des tâches (un demandeur ne peut pas décider de sa propre demande) et un garde-fou
contre la double décision, indexé sur une identité humaine stable — un token système
n’a pas d’identité et ne peut pas décider. Une action critical impose un seuil
obligatoire à deux personnes issu de NIST SP 800-53 AC-3(2), appliqué à la création
et re-dérivé à la décision, de sorte que même une politique opérateur qui abaisse le
niveau ne peut rendre une action critique exécutable par une seule personne. Une vanne
de bris de glace (break-glass) auditée existe pour l’incident de 03 h 00 — bruyante
par construction, soumise à une élévation matérielle, limitée dans le temps, et
contrainte à un examen a posteriori.
Le coupe-circuit est le point de blocage à l’échelle du parc. L’enclencher est délibérément peu coûteux (niveau admin, un motif, pas de quorum), car un arrêt qui attend un consensus n’est pas un arrêt ; chaque point d’actionnement gouverné consulte la ligne d’arrêt en direct et échoue en fermé (fail closed) en cas d’erreur de lecture. La réactivation n’est jamais unilatérale — elle est conditionnée à une nouvelle approbation en double contrôle et ne dispose d’aucune voie de bris de glace, car « le parc reste arrêté » est l’état sûr.
Des preuves inviolables
Chaque action mutante est ajoutée à un registre d’audit append-only, chaîné par hachage dans la même transaction que le changement, avec l’acteur réel ; les lectures sensibles s’auto-auditent dans une écriture validée (committed). Réécrire l’historique est détectable, et le registre ne contient jamais de données personnelles. Le module de conformité mappe ces preuves d’exécution sur des cadres de contrôle, de sorte qu’une évaluation est alimentée par la réalité observée plutôt que par un questionnaire.
Ce que c’est — et ce que ce n’est pas
- Auto-hébergé et souverain. Le control plane s’exécute sur votre propre infrastructure et peut être en air-gap. Olivares AI est une plateforme ouverte et auto-hébergeable (AGPL-3.0). Voir le modèle de sécurité et l’architecture.
- Détectif par défaut ; deny-closed là où il agit. Il observe et gouverne largement ; il n’actionne pas largement. Là où il peut prendre une action, cette surface est live, à la demande, ou une jointure déclarée — et le catalogue des modules indique laquelle. Une absence d’application (enforcement) est généralement intentionnelle.
- Pré-1.0, avec un catalogue publié de 23 modules (environ 20 câblés aujourd’hui). Tout n’est pas live ; nous précisons ce qui l’est et ce qui ne l’est pas plutôt que de laisser entendre une couverture complète.
- L’air-gap s’applique au control plane Olivares, pas à vos modèles. Un modèle hébergé comme Claude n’est jamais en air-gap ; seuls les modèles auto-hébergés (vLLM, Ollama) fonctionnent hors ligne. Olivares gouverne l’accès dans les deux cas.
- Non certifié. Olivares AI est conçu en vue de SOC 2, ISO/IEC 42001 et l’EU AI Act ; il ne détient aucune certification et nous n’en revendiquons aucune.
Les établissements d’enseignement supérieur et de recherche connaissent une version parallèle de ce problème — un usage large de l’IA parmi le corps enseignant et le personnel, alors que la gouvernance formelle de l’IA et la couverture des chartes d’usage acceptable accusent un retard (recherche EDUCAUSE, 2025). Si c’est votre contexte, voir enseignement supérieur ; les équipes plateforme qui exploitent l’infrastructure devraient commencer par ingénierie plateforme.
Où aller ensuite
- Cartographie des accès — le graphe typé R/RW et la surcouche autorisé-vs-observé sur une capture réelle.
- Coupe-circuit — le point de blocage à l’échelle du parc, en termes produit.
- Conformité — des preuves inviolables mappées sur des cadres de contrôle.
- Concepts de gouvernance — read-first, deny-closed, double contrôle.
- Comparer — comment Olivares se positionne aux côtés des passerelles, de l’observabilité et des control towers.
- Démarrer — voir la cartographie sur un parc de démonstration.