Droits et rôles
Qui peut faire quoi dans votre organisation, jusqu’à une table et ses colonnes, pour une raison et une durée. Un agent n’a jamais que les droits de sa personne.
Mis à jour le 9 novembre 2026.
Vous, à votre agent : Donne à Camille la lecture de la base des ventes jusqu’à fin décembre.
Quand vous en servir
Servez-vous-en pour dire qui peut faire quoi, jusqu’à une table : un rôle, sur une portée, pour une durée.
Comment ça marche
Chaque attribution donne à une personne ou à un groupe un rôle sur une portée, de l’organisation jusqu’à une table et ses colonnes, pour une raison et jusqu’à une date. Un jeton ou un agent n’a jamais que les droits de sa personne, bornés à son projet, à la lecture ou à des environnements.
Ce qu’il faut savoir
Les droits d’une personne sont l’union de ses attributions en cours, directes et par ses groupes, et un groupe peut suivre un groupe du SSO. Une attribution peut aussi porter sur une connexion. On ne donne que ce qu’on a, jamais à soi-même, et tout va au journal. Donner le droit d’administrer des accès, ou changer la politique, attend la validation d’une autre personne.
Un jeton ou un agent se borne à son projet, à la lecture, ou à des environnements (production, previews, des noms) ; la lecture, elle, n’est jamais bornée par environnement. Une organisation peut exiger une validation pour toute mise en production, un retour arrière ou une tâche en production, jamais l’inverse.
Les droits sur les données, jusqu’à la table, sont appliqués par PostgreSQL, avec un rôle SQL par identité, pour query et l’export CSV ; l’appli, elle, garde le propriétaire de sa base. L’outil explain_access dit qui a accès, ce que peut faire une personne et pourquoi, et ses actions grant et revoke donnent et retirent les droits.
Les outils MCP de votre agent
Votre agent s’en occupe avec les outils explain_access, list_tokens et get_organization.