Espaces de travail et droits d’accès

Un assistant IA connecté à Emailit ne peut jamais faire plus que vous. Ce qu’il peut faire dépend de trois éléments : les espaces de travail que vous avez autorisés, votre rôle dans chacun d’eux et la portée que vous avez approuvée.

Accès aux espaces de travail

Lors de la connexion, la page de consentement vous demande quels espaces de travail l’application peut utiliser :

Si vous en autorisez plusieurs, vous choisissez aussi celui où l’application démarre : son espace de travail par défaut pour les requêtes qui n’en nomment pas.

Vous pouvez modifier ces deux choix plus tard sous Account›Connected apps avec Edit access. Les modifications s’appliquent à la requête suivante de l’application, sans reconnexion. Si vous quittez un espace de travail, ou si quelqu’un vous en retire, l’application perd aussi l’accès à cet espace de travail.

Choisir l’espace de travail d’une requête

Avec OAuth, chaque outil en dehors du groupe d’outils Espace de travail accepte aussi un argument facultatif workspace : un ID d’espace de travail ou le nom exact de l’espace de travail. Il exécute cet appel dans cet espace de travail sans modifier l’espace par défaut : deux conversations qui travaillent dans des espaces de travail différents ne se gênent donc pas. Les assistants le transmettent quand vous nommez un espace de travail (« Dans Acme Client, listez les domaines »).

L’espace de travail par défaut est conservé lors des actualisations de jetons : une longue session continue donc là où vous l’avez laissée.

Rôles

Les outils s’exécutent avec votre rôle dans l’espace de travail cible, exactement comme dans le tableau de bord. Les propriétaires et les administrateurs peuvent faire tout ce que la portée permet. Les membres ayant le rôle Member ne peuvent pas :

• créer, renommer, supprimer ou régénérer des clés API (create-api-key, update-api-key, delete-api-key, regenerate-api-key),
• supprimer des domaines d’envoi (delete-domain).

Quand un membre demande l’une de ces actions, l’outil renvoie une erreur admin_role_required qui indique l’espace de travail et votre rôle, et rien n’est modifié. Demandez à un administrateur de l’espace de travail de le faire, ou de modifier votre rôle. Les mêmes contrôles de rôle s’appliquent aux appels OAuth à l’API REST.

Portées

La plupart des outils d’IA demandent les deux portées. Quand une connexion sans full appelle un outil qui en a besoin, l’outil renvoie une erreur de portée manquante. Les clients qui prennent en charge l’autorisation renforcée (step-up), comme ChatGPT, affichent de nouveau l’écran d’autorisation Emailit pour que vous puissiez accorder full ; avec les autres clients, révoquez la connexion et reconnectez-vous avec un accès complet.

Les connexions par clé API fonctionnent différemment : le serveur masque les outils que la clé ne peut pas appeler, si bien qu’une clé Sending Only ne voit jamais que les outils d’envoi.

Jetons et sessions

La réutilisation d’un ancien jeton d’actualisation révoque toute la connexion, ce qui vous protège en cas de fuite d’un jeton. Le serveur MCP lui-même est sans état : il n’y a donc pas de session qui expire ; les clients actualisent les jetons en arrière-plan.

Connexions par clé API

Une clé API agit sur l’espace de travail dans lequel elle a été créée. Elle n’a pas d’argument workspace, pas d’accès aux outils d’espace de travail qui nécessitent OAuth (list-workspaces, switch-workspace, create-workspace) et pas de limites liées au rôle, car c’est la clé elle-même qui porte les droits. Créez une clé Sending Only pour les agents qui ne font qu’envoyer.

Consulter et révoquer l’accès

Account›Connected apps liste chaque application que vous avez approuvée, les espaces de travail qu’elle peut utiliser, son niveau d’accès et sa date de connexion. Revoke access désactive immédiatement ses jetons ; l’application doit redemander l’autorisation pour se reconnecter. Consultez Applications connectées, ou gérez les autorisations depuis votre code avec l’API des autorisations.