Le moindre privilège, de bout en bout
Chaque route vérifie une permission déclarée avant de s'exécuter, parmi 32 portées. Une clé d'API n'en porte qu'un sous-ensemble, avec une expiration facultative — jamais les clés de tout l'espace de travail.
32 portées de permission, des clés d'API limitées à un sous-ensemble, un coffre de secrets chiffré et des limites de débit que vous fixez.
Ce que vous obtenez
- Clés d'API à portée limitée — Créez une clé capable de déclencher un workflow, mais pas de lire un secret ni d'inviter un utilisateur. Chaque clé porte sa propre liste explicite de permissions et une expiration facultative : une intégration tierce ne reçoit jamais plus que ce pour quoi elle est là.
- Accès d'équipe par rôles — Invitez vos collègues dans un espace de travail avec un rôle : chaque endpoint vérifie la permission qu'il a déclarée avant de s'exécuter. Déployer, révéler un secret, approuver une exécution en pause et débloquer les tentatives sont des droits distincts, accordés séparément.
- Coffre de secrets chiffré — Stockez secrets de signature et identifiants par espace de travail et référencez-les par leur nom dans un workflow. Lister un secret et révéler sa valeur en clair sont deux permissions distinctes : on peut vérifier qu'un identifiant existe sans jamais pouvoir le lire.
- Des limites de débit que vous maîtrisez — Définissez des plafonds de débit par espace de travail et par domaine sortant, pour qu'une intégration bruyante n'épuise pas la capacité dont dépendent vos workflows de production, et qu'une API partenaire défaillante n'entraîne pas tout le compte avec elle.
Capacités de la plateforme
- 32: Portées de permission
- Refus par défaut: Comportement d'une route sans permission déclarée
- 2: Droits distincts pour lister un secret et lire sa valeur
Puis-je créer une clé d'API qui ne fait qu'une seule chose ?
Oui. Une clé est créée avec une liste explicite de permissions parmi les 32 portées disponibles, plus une expiration facultative. Une clé limitée au déclenchement d'exécutions ne peut ni lire de secrets, ni modifier les membres, ni déployer.
Que se passe-t-il si un endpoint est livré sans permission déclarée ?
Elle refuse toute identité à portée limitée. L'accès s'obtient par déclaration, pas par exclusion : une route qui n'a jamais déclaré de permission n'accorde rien à une clé d'API ni à un rôle — un oubli échoue en mode fermé plutôt que d'exposer discrètement l'endpoint.
Peut-on lire la valeur d'un secret simplement parce qu'un workflow l'utilise ?
Non. Lister les secrets et révéler leur valeur en clair sont deux permissions distinctes. Le workflow résout le secret à l'exécution, et un collègue peut vérifier qu'il existe et qu'il est bien référencé, sans que quiconque ait le droit d'en afficher la valeur.