La carte d'accès lecture/écriture

La carte d’accès lecture/écriture est la structure de données sur laquelle tout le reste repose. Si vous la comprenez, vous comprenez le produit.

Nœuds et arêtes typées

La carte est un graphe. Les agents sont des nœuds. Les ressources qu’ils peuvent atteindre — bases de données, object stores, serveurs MCP, API, files d’attente — sont des nœuds. Chaque arête est une relation d’accès typée : R (l’agent peut lire la ressource) ou RW (l’agent peut la lire et l’écrire).

Typer chaque arête lecture/écriture est un choix délibéré. Le principe de moindre privilège et le rayon d’impact d’un incident sont tous deux fonction de l’accès en écriture, pas de la simple connectivité. Un agent de reporting qui ne peut que lire un entrepôt de données et un agent de déploiement qui peut le réécrire ne représentent pas le même risque, et une simple liste « a accès » masque précisément cette distinction.

Permis vs Observé

La carte comporte deux couches et les compare en continu :

• Permis — ce que l’agent est autorisé à faire, dérivé des autorisations et des politiques.
• Observé — ce qu’il a effectivement été vu en train de faire, dérivé de la télémétrie et des journaux d’audit natifs.

C’est dans la différence que réside la valeur :

• Accès inattendu — une arête qui a été observée mais n’était pas attendue. C’est la découverte qu’une équipe de sécurité veut réellement voir remonter.
• Autorisations inutilisées — une arête qui est permise mais jamais exercée. C’est votre liste concrète de nettoyage du moindre privilège, pas une vague injonction « révisez votre IAM ».

La visite produit en direct montre cette superposition sur une capture réelle.

La fidélité est graduée — et affichée

La carte n’est fiable qu’à la mesure de ce qu’une source peut prouver, et elle le dit plutôt que de bluffer. Deux axes indépendants sont affichés par arête :

• Couverture lecture/écriture :
  • clean — l’audit natif rend R/RW sans ambiguïté (PostgreSQL via pgAudit, object storage via CloudTrail, entrepôts de données et lacs de données).
  • lossy — signal partiel, par exemple certains document stores et vector stores.
  • opaque — impossible à reconstituer passivement (Redis, SQLite, D1). L’arête est marquée unknown plutôt que devinée.
• Attribution :
  • firm — la source porte une identité par agent.
  • approximate — un compte de service partagé masque quel agent a agi.

Comme les deux axes accompagnent l’arête, une relation connue avec certitude et une à peine visible ne sont jamais rendues comme si elles étaient également certaines.

Lecture d’abord par conception

Construire cette carte est une activité d’observation, pas d’interception. Olivares AI ne se place pas dans le chemin de requête entre un agent et ses ressources ; il ingère la télémétrie et l’audit natif hors bande. Consulter la carte est elle-même une action privilégiée, scopée au tenant et entièrement auditée. Le produit observe et gouverne d’abord ; là où il peut agir, il le fait en mode fermé par défaut — jamais en tant qu’exécuteur généraliste.

Voir aussi

• Qu’est-ce qu’Olivares AI ? — le produit en une page.
• Démarrage rapide — voir la carte sur l’environnement de démonstration.
• Architecture — comment les pièces s’assemblent, auto-hébergé et compatible air-gap.