Cette page est la référence unique pour les permissions de partage et le flux d’identifiants sur les cinq types de ressources partageables — Agents, Skills, Knowledge Bases, Connectors et Workflows. Utilisez-la pour comprendre ce qui se passe lorsque vous partagez une ressource qui est elle-même construite sur d’autres ressources.
Les deux questions
Chaque décision de partage répond à deux questions indépendantes :
- Visibilité — l’autre personne peut-elle voir/utiliser cette ressource du tout ?
- Identifiants — avec quel secret (clé API, mot de passe BD, env serveur) s’exécute-t-elle ?
La visibilité concerne la ressource ; les identifiants sont une préoccupation distincte et par utilisateur que seuls les Connectors et les serveurs MCP portent. Gardez-les séparés dans votre esprit — la plupart de la confusion provient de la confusion entre « je peux le voir » et « je peux utiliser la clé du propriétaire ».
Visibilité : propre + abonné
Une ressource vous est visible uniquement si vous en êtes propriétaire ou vous avez un abonnement explicite à celle-ci. Il n’y a plus de “tout le monde dans mon organisation peut la voir” implicite — le partage organisationnel est livré via les abonnements.
| Portée de partage | Signification | Comment les autres accèdent |
|---|
| Personnel (par défaut) | Seul le propriétaire peut la voir. | — |
| Organisation | Publié dans une organisation. | Les membres de l’organisation s’abonnent depuis la Market (ou sont auto-abonnés à l’adhésion). |
| Global / Market | Publié sur la Market publique. | Tout le monde s’abonne depuis la Market. |
Les abonnements sont limités : quitter (ou être retiré de) une organisation révoque les abonnements que vous aviez uniquement via celle-ci, et supprime les identifiants par utilisateur que vous aviez enregistrés pour ces ressources.
Credentials & “Allow fallback”
Seuls les Connectors et les serveurs MCP détiennent des credentials. Chacun dispose d’un commutateur Allow fallback qui détermine si les abonnés peuvent emprunter la credential du propriétaire :
| État | Un abonné avec sa propre credential | Un abonné sans sa propre credential | Le propriétaire |
|---|
| Allow fallback OFF (par défaut) | Utilise sa propre credential. | Pas d’accès — l’outil est masqué et l’interface les invite à configurer leur propre credential. | Utilise toujours la sienne. |
| Allow fallback ON | Utilise sa propre credential. | Bascule vers la credential du propriétaire (et tout usage/facturation est imputé au propriétaire). | Utilise toujours la sienne. |
- OFF est l’état par défaut. Le partage de votre token est volontaire. Un connector ou serveur MCP nouvellement créé ne partage pas la credential du propriétaire, et les existants ont été migrés vers OFF.
- Le propriétaire est toujours exempté. “Allow fallback” ne régit que les autres utilisateurs ; vous pouvez toujours utiliser votre propre connector avec votre propre credential.
- Pas d’échec silencieux. Quand fallback est OFF et qu’un utilisateur n’a pas de credential, l’outil est retiré de l’ensemble d’outils plutôt que proposé puis échouant au moment de l’appel. Chaque surface (chat, le Playground, étapes de workflow) doit afficher une invite “configurez vos propres credentials” au lieu d’un outil défaillant.
Les ressources se composent. Partager une ressource expose implicitement les ressources liées en dessous — mais les identifiants d’accès ne circulent pas automatiquement avec elles.
| Conteneur | Peut référencer | Comment |
|---|
| Agent | Knowledge Bases, Connectors, MCP servers | kb_ids / connector_ids / mcp_server_ids |
| Agent | Skills | skill_ids (hérité — préférer Skill→Agent) |
| Skill | Connectors, Agents, … | resource_refs (le mécanisme @alias) |
| Workflow | Agents, Knowledge Bases, Connectors, MCP servers | par nœud agent_id / kb_id(s) / connector_id / mcp_server_id |
- Knowledge Bases n’ont pas d’identifiant d’accès par utilisateur, donc une KB liée à un agent partagé délègue son contenu : quiconque exécute l’agent lit les données du propriétaire de la KB (l’agent a besoin de sa KB pour fonctionner). Une recherche KB ad-hoc en dehors d’un agent lié est vérifiée en accès (propre + abonnée).
- Connectors / MCP servers portent des identifiants d’accès, donc ils délèguent uniquement quand Allow fallback est activé (voir ci-dessous).
Scénarios concrets
Vous possédez un Agent qui lie un connecteur personnel (vous n’avez pas partagé
le connecteur lui-même). Vous partagez l’Agent avec votre organisation ou globalement. Quelqu’un d’autre l’exécute :
| Scénario | « Allow fallback » du connecteur | Ce que l’autre utilisateur obtient |
|---|
| 3a | ON | L’outil connecteur est disponible et s’exécute avec vos identifiants — l’autre utilisateur peut l’utiliser. L’utilisation vous est facturée. |
| 3b | OFF (par défaut) | L’outil connecteur est masqué pour cet utilisateur. Le reste de l’agent fonctionne toujours ; l’interface utilisateur lui demande d’ajouter ses propres identifiants pour ce connecteur, après quoi l’outil réapparaît et s’exécute avec sa clé. |
C’est pourquoi le modèle recommandé pour un connecteur que vous avez l’intention de partager est :
laissez Allow fallback désactivé, et laissez chaque utilisateur lier ses propres identifiants. Activez-le
uniquement lorsque vous souhaitez délibérément prêter votre clé (et absorber l’utilisation) —
par exemple une API facturée à l’usage que vous êtes à l’aise de payer pour le compte d’autres.
