Retour aux docsConcepts clés

Autorisations

Contrôle connecteur par connecteur de ce qu'Okou peut faire : valeurs par défaut, approbations, audit, révocation.

Dernière mise à jour 17 septembre 2026 · 4 min read

Permissions

L'accès aux connecteurs comporte trois couches distinctes : la connexion d'un membre, l'autorisation d'un agent, et les permissions nommées accordées à cet agent. Connecter un service n'accorde pas silencieusement toutes les actions à tous les agents.

Connexion, autorisation et permission

CoucheCe qu'elle contrôle
ConnexionQuel compte membre ou quel identifiant peut être utilisé pour le service.
Autorisation d'agentQuel agent peut utiliser ce service connecté.
Octroi de permissionQuelles actions nommées cet agent peut demander, et pour combien de temps.

Pour les services à identifiants par membre, chaque membre connecte son propre compte. Un agent partagé agit toujours via le compte connecté et les octrois du membre qui l'exécute ; il n'hérite ni de la boîte mail, ni du jeton, ni de l'historique de chat privé d'un collègue.

Accorder l'accès

Quand un agent a besoin d'une permission de connecteur qu'il n'a pas, Okou affiche une demande de permission. Vérifiez le connecteur, l'agent, le nom de la permission et le motif avant de choisir Allow ou Deny.

Une permission accordée peut prendre l'une des durées proposées dans le produit :

  • Allow for 1h
  • Allow for 24h
  • Allow for 7d
  • Allow always

À l'expiration d'un octroi limité dans le temps, l'agent doit le redemander. Refuser une permission ne déconnecte pas le compte et ne supprime pas les permissions sans rapport.

Gérez l'accès actuel d'un agent aux connecteurs depuis ses paramètres d'autorisation. La vue d'accès aux connecteurs montre quels agents sont autorisés et si leur état de permission est autorisé, refusé ou mixte.

Gestion des identifiants

Les jetons OAuth et les secrets saisis manuellement sont stockés sur la plateforme. Pour les requêtes de connecteur, le pare-feu injecte l'identifiant à la frontière réseau ; le secret n'est pas exposé au code de l'agent sous forme de variable d'environnement.

Ne collez pas de clés d'API, de jetons OAuth, de mots de passe ou de secrets client dans un chat, une instruction d'agent, une instruction de workflow ou un fichier joint. Utilisez plutôt le flux de connexion du connecteur.

Déconnecter le connecteur d'un membre retire cette connexion des exécutions futures. Retirer une autorisation d'agent empêche cet agent d'utiliser le connecteur sans toucher aux autres agents autorisés.

Limites de l'approbation

La frontière que l'on peut faire respecter, c'est l'octroi de permission nommée du connecteur. Ne comptez pas sur une catégorie d'action générique pour garantir que chaque e-mail, publication, paiement, changement d'infrastructure ou suppression s'arrêtera toujours de la même façon.

Pour le travail qui doit rester revu par un humain :

  1. N'accordez que la permission de lecture ou de brouillon, et refusez la permission finale d'écriture ou d'envoi lorsque le connecteur les expose séparément.
  2. Énoncez l'exigence de relecture dans l'instruction de l'agent ou du workflow.
  3. Gardez l'action finale à l'humain, par exemple en produisant un brouillon Gmail ou un changement proposé au lieu de l'envoyer ou de l'appliquer.

Utilisez aussi les contrôles du service en amont : clés d'API restreintes, portées OAuth au moindre privilège, permissions de dépôt et identifiants de production séparés.

Chats, journaux et visibilité des administrateurs

Les membres accèdent à leurs propres fils de discussion. Publier un agent ou un workflow ne publie pas l'historique de chat privé ni les identifiants de connecteur du membre. Ne partagez une conversation ou un artefact qu'au travers d'une surface de partage explicite.

Les administrateurs de l'espace de travail voient des agrégats d'usage par membre, utilisés pour la facturation et la gestion de capacité. Cela ne donne pas une vue automatique du contenu des chats privés des autres.

Dans son propre chat, la vue d'activité enregistre la séquence visible de l'exécution, l'activité des connecteurs, les artefacts, les statuts et les erreurs. Servez-vous-en pour vérifier si une action de connecteur demandée a bien été exécutée et si elle a réussi.

Liste de vérification

  • Le connecteur est-il lié au compte membre voulu ?
  • L'agent voulu est-il autorisé ?
  • Seules les permissions nécessaires à cette tâche sont-elles autorisées ?
  • L'octroi peut-il expirer après 1 heure, 24 heures ou 7 jours plutôt que rester permanent ?
  • Le workflow garde-t-il les actions irréversibles ou tournées vers l'extérieur dans une étape revue par un humain ?
  • L'identifiant en amont peut-il être restreint davantage ?

Et ensuite

  • Voir Chat pour ce qui se passe à l'intérieur d'une frontière de chat.
  • Voir Connectors pour le catalogue et ce que chacun sait faire.
  • Voir For teams pour la configuration des permissions au niveau de l'organisation.