Identifiants personnels vs partagés

Chaque identifiant qu’AiHummer possède — une clé API, un jeton, un secret de webhook — a un portée qui décide duquel des secrets un appel d’outil s’exécute avec. Il y a deux portées : partagé et personnelComprendre la différence, ainsi que l’ordre de résolution entre eux, est la clé pour donner à chaque agent et à chaque utilisateur exactement l’accès qu’ils devraient avoir et rien de plus.

Les deux portées

Portée	Appartient à	Utilisé lorsque
Partagé	L’espace de travail	Une action devrait s’exécuter sous un compte commun quel que soit celui qui l’a déclenchée
Personnel	Un utilisateur individuel	Une action doit être attribuée à une personne spécifique et limitée par l’autorisation propre de cette personne

Les deux types vivent dans le même coffre-fort chiffré (chiffrement par enveloppe, AES-256-GCM, clé par locataire sous une clé maîtresse) ; la différence réside uniquement dans qui un secret concerne, et non dans la manière dont il est stocké ou protégé.

Résolution par l’utilisateur agissant, avec un repli sur l’espace de travail

Au moment du tour, lorsqu’un outil a besoin d’un identifiant, AiHummer le résout par l’utilisateur agissant — la personne pour le compte de laquelle le tour se déroule — et revient à la espace de travail (identifiant partagé) lorsque l’utilisateur n’en possède pas de personnel :

need credential ─▶ personal credential for the acting user?
                     ├─ yes ─▶ use the personal credential
                     └─ no  ─▶ fall back to the shared (workspace) credential

Cette règle unique vous donne un comportement flexible : fournissez uniquement un identifiant partagé et tout le monde l’utilise ; laissez les individus ajouter le leur et il prend automatiquement la priorité pour cette personne, tandis que tout le monde continue à utiliser celui partagé.

[!NOTE] Le personnel l’emporte toujours sur le partagé pour le même utilisateur. Les informations d’identification de l’espace de travail sont un repli, pas une substitution — un utilisateur qui a connecté son propre compte agit avec leur propre autorisation.

Quand utiliser partagé

Choisis un partagé identifiant lorsque :

L’action représente l’organisation, et non un individu (une boîte aux lettres d’entreprise, un seul compte de service CRM, une clé de facturation).
Vous voulez un comportement cohérent peu importe qui a déclenché l’agent.
Émettre et faire tourner un secret de manière centralisée est plus simple que de le configurer pour chaque utilisateur.

Quand utiliser personnel

Choisis un personnel identifiant lorsque :

L’action doit être attribuée à un humain spécifique et limitée par ce que cela l’homme est autorisé à faire.
Différents utilisateurs devraient voir différentes données via le même agent et outil.
Vous avez besoin d’une révocation et d’un audit par utilisateur, indépendants de tous les autres.

Les identifiants personnels sont généralement les comptes individuels qu’un employé utilise pour se connecter. Connexions. Par défaut, ceux-ci incluent, par exemple, Gmail, Google Agenda, Google Contacts, Google Drive, Google Tasks, YouTube, Outlook Mail, Outlook Agenda, OneDrive, Microsoft To Do, Todoist, Asana, Jira Cloud, ClickUp, GitLab, Linear, monday.com, Fitbit, Oura Ring, Strava, Spotify et Samsung SmartThings — chaque utilisateur agit sous sa propre autorisation. Un identifiant partagé, en revanche, est un compte unique pour l’ensemble de l’espace de travail (par exemple, une boîte mail d’entreprise ou un compte de service CRM) que tout le monde utilise.

Le mettre en place en pratique

En termes simples :

Un identifiant pour tout le monde (partagé). Un opérateur enregistre un secret une fois à la niveau de l’espace de travail — sur le Secrets écran ou comme une connexion partagée. Ensuite, tous les agents et utilisateurs agissent sous un seul compte (par exemple un boîte mail de l’entreprise).
Un identifiant par personne (personnel). Un utilisateur connecte son propre compte via Connexions (complète une connexion OAuth) — et à partir de ce moment-là, leurs propres appels sont effectués sous leur autorisation, tandis que tout le monde sinon garde celui partagé.
Qui peut écrire à un agent est défini non pas ici mais sur le Chaînes écran : l’interrupteur « Répondre uniquement aux utilisateurs connus ».
Une persona/comportement personnel pour une personne spécifique provient de la combinaison connexions personnelles (cette page) avec les paramètres de l’agent ; mettre des règles à l’échelle de l’entreprise dans blocs partagés.

Rien de plus à « activer » : la règle de résolution (personnelle → sinon partagée) fonctionne automatiquement.

Comment il interagit avec Connections et le coffre

Connexions sont la façon la plus courante de personnel un identifiant prend naissance : l’utilisateur termine un flux d’autorisation OAuth2 par code, le jeton émis est scellé dans le coffre, et à partir de ce moment, il s’agit exactement de l’identifiant personnel que le résolveur choisit pour cet utilisateur. Un identifiant partagé, en revanche, est généralement un secret qu’un opérateur stocke une seule fois au niveau de l’espace de travail.

Dans tous les cas, le secret reste dans le coffre crypté et n’entre jamais dans le contexte du modèle, l’invite ou les journaux — la portée ne contrôle que quelle entrée du coffre l’utilisateur en action résout.

Où aller ensuite

Connexions (OAuth2 par utilisateur) — comment Les identifiants personnels sont autorisés.
Fournisseurs BYOK et LLM — clés par locataire.
Aperçu du marché et niveaux — Niveau 2 les compétences peuvent utiliser des identifiants personnels.