Contrôle d'accès

Rebyte applique le contrôle d’accès à plusieurs niveaux. Chaque niveau est configuré et appliqué indépendamment.

Rôles de l’organisation

Deux rôles gérés via Clerk :

Rôle	Portée
Admin	Contrôle total de l’organisation — politiques réseau, politiques de sécurité, politiques d’agent, clés BYOK, invite système, clés API, canaux
Membre	Créer des espaces de travail, exécuter des tâches, utiliser les ressources configurées. Ne peut pas modifier les paramètres au niveau de l’organisation.

Permissions des ordinateurs agents

Chaque ordinateur agent (espace de travail) a un niveau de visibilité et des autorisations d’accès par utilisateur.

Visibilité

Niveau	Qui peut accéder
private	Créateur et utilisateurs explicitement autorisés uniquement
shared (par défaut)	Tous les membres de l’organisation — lecture et écriture
public	Tout le monde peut consulter. Les membres de l’organisation peuvent modifier.

Niveaux d’accès

Niveau	Peut faire
Owner	Contrôle total. Supprimer l’espace de travail. Attribué automatiquement au créateur.
Editor	Lire/écrire des fichiers, exécuter des tâches, configurer les paramètres. Accordé aux membres de l’ACL et aux membres de l’organisation (si partagé/public).
Viewer	Lecture seule. S’applique uniquement aux espaces de travail publics pour les utilisateurs non-membres de l’organisation.

Ordre d’évaluation

1. L’utilisateur est-il le créateur de l’espace de travail ? → owner
2. L’utilisateur est-il dans l’ACL de l’espace de travail ? → editor
3. L’utilisateur est-il dans la même organisation ET la visibilité est-elle shared ou public ? → editor
4. La visibilité est-elle public ? → viewer
5. Sinon → refusé

Accorder l’accès par utilisateur via les paramètres des membres/ACL de l’espace de travail.

Permissions des compétences

Les compétences d’équipe utilisent un modèle de permissions basé sur le créateur.

Action	Qui
Créer une compétence	Tout membre de l’organisation
Voir/télécharger une compétence	Visibilité publique : tout membre de l’organisation. Privée : créateur ou utilisateurs autorisés par l’ACL.
Mettre à jour les métadonnées	Tout membre de l’organisation
Supprimer une compétence	Tout membre de l’organisation
Changer la visibilité	Créateur uniquement
Gérer l’ACL de la compétence	Créateur uniquement
Annuler la version	Créateur uniquement
Voir l’ACL	Tout membre de l’organisation

Les compétences prennent en charge deux niveaux de visibilité : private et public (au sein de l’organisation). Le créateur contrôle la visibilité, les autorisations ACL et l’annulation de version.

Permissions du contexte de l’agent

Context Lake (connexions aux sources de données) utilise une création limitée aux administrateurs avec une ACL gérée par le créateur.

Action	Qui
Créer un jeu de données/une vue	Administrateur de l’organisation uniquement
Lister les jeux de données/vues	Tout membre de l’organisation
Interroger un jeu de données/une vue	Créateur, utilisateurs autorisés par l’ACL, administrateur de l’organisation, ou tout membre de l’organisation si la visibilité est shared ou public
Gérer l’ACL du jeu de données/de la vue	Créateur uniquement
Voir l’ACL	Créateur ou administrateur de l’organisation

Chaque jeu de données et chaque vue a sa propre ACL et son propre paramètre de visibilité. Les jeux de données partagés/publics peuvent être interrogés par tous les membres de l’organisation. Les jeux de données privés nécessitent des autorisations ACL explicites. Les entrées ACL incluent une piste d’audit granted_by.

Politiques de l’organisation (administrateur uniquement)

Les administrateurs contrôlent les politiques à l’échelle de la plateforme via les Paramètres.

Politiques d’agent

Contrôles par exécuteur :

Paramètre	Effet
enabled	Activer/désactiver un exécuteur (Claude, Gemini, Codex, OpenCode) pour toute l’organisation
authMethod	Forcer le mode api_key (BYOK) ou credits par exécuteur
disabledModels	Bloquer l’utilisation de modèles spécifiques

Politique réseau

Voir Agent Shield pour plus de détails. Les paramètres de la politique réseau peuvent actuellement être modifiés par tout membre de l’organisation.

Paramètre	Par défaut
Mode de liste blanche de domaines	package_managers_only
Domaines autorisés supplémentaires	Aucun

Politique de sécurité

Paramètre	Par défaut	Effet
Surveillance Shield	optional	required applique Shield sur tous les ordinateurs ; optional permet l’activation par espace de travail

Dérogation par espace de travail : les éditeurs d’espace de travail peuvent activer/désactiver la surveillance Shield sur des espaces de travail individuels lorsque la politique de l’organisation est optional.

Invite système

Les administrateurs peuvent définir une invite système personnalisée appliquée à toutes les exécutions d’agents dans l’organisation. Nécessite un abonnement Équipe.

Portées des clés API

Les clés API ont des portées granulaires contrôlant les opérations qu’elles peuvent effectuer :

Portée	Permission
tasks:read	Lister et visualiser les tâches
tasks:write	Créer des tâches, envoyer des suivis, supprimer
files:read	Voir les métadonnées des fichiers
files:write	Télécharger des fichiers
webhooks:read	Lister les webhooks, voir la clé publique
webhooks:write	Créer et supprimer des webhooks

Toutes les portées sont accordées par défaut lors de la création de la clé. La sélection granulaire des portées est prévue.

Résumé

Couche	Contrôlé par	Granularité
Paramètres et politiques de l’organisation	Administrateur de l’organisation	À l’échelle de l’organisation
Accès aux ordinateurs agents	Créateur + ACL	Par espace de travail, par utilisateur
Accès aux compétences	Créateur + ACL	Par compétence, par utilisateur
Accès à Context Lake	Admin (création) + Créateur (ACL)	Par jeu de données/vue, par utilisateur
Portées des clés API	Administrateur de l’organisation	Par clé
Sortie réseau	Administrateur de l’organisation	À l’échelle de l’organisation (via Agent Shield)