Un routage d'agents qui respecte votre frontière d'identité.

Donnez aux agents et aux workflows un accès au contexte organisationnel courant, sans leur remettre des identifiants d'accès à l'annuaire illimités ni intégrer la logique d'identité dans chaque application.

Roster sépare la résolution des participants de l'authentification, de l'autorisation, des annuaires sources et de l'exécution des workflows — pour que les contrôles de sécurité restent là où ils doivent être.

Consulter la sécurité RosterExplorer l'autorisation

Chaque appel resolve traverse cinq couches gouvernées

Un agent qui demande « qui doit agir ? » ne touche jamais directement à l'annuaire. La requête franchit cinq contrôles indépendants avant que Roster ne renvoie un participant — chacun relève d'un enjeu de sécurité distinct, chacun est auditable séparément.

Caller
Agent IA · workflow · tâche CI
01
authn
Authentification
Qui ou quoi se connecte à Roster ? Humain via SSO, agent via clé API, compte de service via identifiant d'accès à portée limitée.
02
portée
Portée de l'identifiant
Quelles capacités REST ou MCP cet identifiant d'accès peut-il invoquer ? mcp:resolve, participants:read, rien d'autre.
03
rôle
Rôle plateforme
Cette identité est-elle administrateur, propriétaire de projet ou membre ? Les rôles gouvernent la configuration et la portée inter-projets.
04
ressource
Autorisation de ressource
À quels projets, participants, délégations et enregistrements cette identité peut-elle accéder ?
05
resolve
Résolution des participants
Compte tenu de tout ce qui précède, quel utilisateur, groupe, rôle ou délégué doit être impliqué dans le workflow maintenant ?
Resolved
Participant gouverné
// accès effectif = portée d'identifiant ∩ droits du propriétaire ∩ règles de ressource

Un seul modèle d'identité pour les humains, les agents et les charges

Chaque acteur reçoit sa propre identité Roster — avec une authentification, des identifiants d'accès, un cycle de vie et une attribution d'audit distincts. Pas de clés partagées, pas d'appelants ambigus.

01
identity.human
Membres humains d'équipe

S'authentifient via les fournisseurs de connexion configurés et opèrent sous leur identité Roster mappée — avec une piste d'audit complète liée au sujet SSO d'entreprise.

02
identity.agent
Agents IA

Identités de premier ordre pour les agents autonomes, avec clés API dédiées, métadonnées de responsabilité et portées propres à chaque agent — un agent compromis n'usurpe jamais un humain.

03
identity.service
Comptes de service

Pour les applications, intégrations, tâches planifiées et automatisations de charges — durables si besoin, révocables à tout moment, jamais confondus avec une personne.

04
identity.key
Clés API

Appartiennent à une seule identité, portent des portées explicites, se renouvellent indépendamment et sont révocables sans perturber l'identité ni son historique.

connecteurs, sans custodie

Adossé à l'annuaire. Pas un nouveau système IAM.

Roster lit les données organisationnelles depuis les annuaires que vous exploitez déjà. Les fournisseurs restent la source de vérité. Roster ne matérialise que les enregistrements et relations d'appartenance nécessaires à la résolution — jamais l'ensemble de l'effectif, jamais pour chaque agent.

Microsoft Entra IDOktaGoogle WorkspaceWorkdayLDAPActive DirectoryCSV
roster matérialise

La couche de résolution des participants qui s'intercale entre vos annuaires et vos agents — gouvernée, à portée limitée, auditable. Jamais un fournisseur d'identité. Jamais un SIRH. Jamais un raccourci autour de l'IAM.

Des identifiants d'accès à portée chirurgicale, pas un accès général

Un agent limité à Resolve a besoin de quatre portées, pas de trente. Chaque clé API est émise à une identité précise, porte une liste de capacités explicite et peut être révoquée ou renouvelée sans toucher au reste de la plateforme.

Clé API
roster_agent_prod_a7f9…
identitéagent.procurement-bot
Portées autorisées
mcp:resolve
mcp:projects:read
mcp:participants:read
mcp:resolve-requests:read
Refusé par la portée
mcp:team-members:write
mcp:api-keys:write
mcp:provider-connectors:write
mcp:platform-settings:write
mcp:audit-events:read

La portée autorise l'appel. L'identité active doit encore avoir accès au projet, aux participants et aux enregistrements sous-jacents. Même une clé trop permissive ne peut atteindre que ce que son identité est autorisée à voir.

Autorisation et résolution ne sont pas la même chose

Les moteurs de politique répondent à la question de savoir si un acteur connu peut effectuer une action connue. Roster répond à la question de savoir quel acteur doit même être impliqué. Les deux ont leur place dans un workflow en production. Aucun ne remplace l'autre.

autorisation
Votre moteur de politique
Q. Cet acteur peut-il effectuer cette action ?

OPA, OpenFGA, Cedar ou votre système IAM évaluent des permissions sur des sujets déjà connus. Roster leur remet un candidat gouverné à évaluer.

résolution
Roster
Q. Quel acteur doit être impliqué ?

Pour un contexte de workflow donné, Roster renvoie l'utilisateur, le groupe, le rôle ou le délégué que l'état organisationnel courant désigne — puis votre couche d'autorisation prend le relais.

Roster résout le candidat. L'autorisation vérifie qu'il peut agir. Le moteur de workflow exécute. Trois préoccupations séparables, trois pistes d'audit séparables, un résultat responsable.

Des contrôles de sécurité intégrés au chemin de résolution

Chacun des contrôles ci-dessous est appliqué côté serveur, au moment de la résolution — jamais laissé au prompt, au code de l'agent ou aux auteurs de workflows.

01
Portées étroites

Émettez des identifiants d'accès avec seulement les capacités dont la charge a besoin. Un agent limité à Resolve n'obtient jamais d'accès en écriture, d'administration ou de configuration.

02
Frontières projet

La portée autorise l'appel d'outil, mais l'identité active doit encore avoir accès au projet et aux participants concernés.

03
Identifiants d'accès séparés

Des clés distinctes pour des agents, environnements, applications et responsabilités distincts — révoquez-en une sans perturber les autres.

04
Gestion du cycle de vie

Désactivez ou supprimez les identités d'agents et de services retirées, puis révoquez ou renouvelez leurs clés — avec la piste d'audit préservée.

05
Séparation des fournisseurs

Les clients IA reçoivent des identifiants d'accès Roster, pas des jetons directs Entra, Okta, Google, Workday ou LDAP. Les identifiants d'accès amont ne quittent jamais le connecteur.

06
Contrôles PII

Configurez la rédaction au niveau des champs et le comportement de rétention pour les enregistrements de modèle et d'exploitation de Roster, par projet ou globalement.

07
Audit et export de télémétrie

Événements d'audit durables et export OTLP optionnel : traces, métriques et journaux acheminés vers votre SIEM et votre pile d'observabilité — jamais vers Advantys. Les fenêtres de rétention sont configurées par classe d'enregistrement.

Questions fréquentes

Non. Le client s'authentifie auprès de Roster avec un identifiant d'accès émis par Roster. Les identifiants d'accès des fournisseurs d'annuaire restent une configuration de connecteur côté serveur et ne quittent jamais la plateforme.

Gouvernez le contexte organisationnel que vos agents peuvent utiliser

Offrez aux agents et aux automatisations un chemin contrôlé vers la résolution des participants — sans contourner les pratiques d'identité de l'entreprise.

Consulter la sécurité RosterExplorer l'autorisationExplorer toutes les solutions