Travailler à plusieurs¶

AIM est multi-tenant dès la base. Trois populations peuvent coexister sans se voir : toi, tes collègues, et les équipes côté client.

Les rôles¶

Rôle	Peut
`reader`	Lire les faits, compiler le pack, interroger le MCP
`contributor`	Tout cela, plus : ingérer, extraire, réviser les faits
`owner`	Tout cela, plus : gérer les accès, supprimer le client

Le créateur d'un client en devient propriétaire dans la même transaction — un client sans propriétaire serait immédiatement inaccessible, y compris à celui qui vient de le créer.

Donner accès¶

Il faut l'identifiant d'objet Entra du bénéficiaire :

az ad user show --id prenom.nom@client.com --query id -o tsv

Puis :

aim member add <oid> --label "equipe-backend-acme" --role reader
aim member list

Le cloisonnement, précisément¶

Un principal ne voit que les clients dont il est membre.

flowchart TD
    subgraph Toi
        T1[acme] & T2[nordwind] & T3[globex]
    end
    subgraph "Équipe ACME"
        A1[acme]
    end

Trois garanties :

aim client list ne montre que ses clients. La requête part d'une jointure sur les appartenances ; il n'existe aucune méthode capable de balayer plusieurs clients à la fois.
Un client inaccessible répond 404, jamais 403. Un 403 confirmerait son existence. Pour un membre d'ACME, nordwind n'existe pas.
Le MCP applique exactement les mêmes règles, via la même implémentation. Il n'y a pas deux contrôles d'accès à garder cohérents.

Vérifié, pas seulement conçu

Le cloisonnement est testé contre l'environnement réel : un principal étranger reçoit « client introuvable » sur l'outil conventions et une liste de clients vide.

Retirer un accès¶

aim member revoke <oid>

Le retrait du dernier propriétaire est refusé : il rendrait le client définitivement ingérable, y compris pour celui qui exécute la commande. Nomme d'abord un remplaçant.

Journal d'audit¶

Toute action sensible est tracée côté serveur : création de client, ingestion, extraction, révision d'un fait, attribution et retrait d'accès, création et révocation de clé. Chaque entrée porte le principal, l'horodatage et le détail.

C'est indispensable dès lors que des équipes clientes accèdent à la plateforme, et utile pour répondre à « qui a validé cette règle ? ».

Donner accès à une équipe côté client¶

Le cas nominal :

Crée le client et ingère les sources sous ton compte.
Révise les faits — tu ne veux pas exposer des candidats non vérifiés.
Ajoute les personnes en reader.
Donne-leur l'URL de l'API et l'audience ; elles font aim login avec leur compte Entra si elles sont dans le tenant DYNECO.

Invités externes

Une personne extérieure au tenant doit d'abord y être invitée comme invité Entra. Son identifiant d'objet est alors celui de son compte invité, pas celui de son tenant d'origine.

Plusieurs machines, un seul utilisateur¶

Rien à faire : ta configuration ~/.aim/config.toml est propre à la machine, mais ton identité et tes clients suivent ton compte Entra. Sur un nouveau poste, aim login puis aim link dans chaque dépôt suffisent.