Connexions sécurisées et engagement open source de Leina

Illustration conceptuelle : les tâches d’équipe atteignent les applications métier via des connexions autorisées.

Avant de demander à une IA d’organiser des e-mails, de trouver des documents ou de mettre à jour des enregistrements métier, une équipe a besoin de frontières d’accès claires : quel compte est utilisé, quelles opérations sont autorisées, qui peut utiliser une connexion et qui reçoit le résultat.

Leina accède aux applications métier via des connexions autorisées et utilise les permissions de membres et de groupes pour gérer l’accès disponible. OpenConnector gère les connexions aux applications. Les identifiants de compte bruts restent dans le runtime de connexion, tandis que l’agent utilise les opérations et les résultats nécessaires à la tâche. Architecture des connexions

Nous publions le code des composants clés et la documentation afin que les développeurs puissent examiner la gestion des identifiants, les déclarations de permissions et la logique d’appel, et contribuer à les améliorer. Les projets publics fournissent les détails d’implémentation et les enregistrements de collaboration ; les identifiants et les données métier restent soumis à l’autorisation de connexion et à la configuration d’accès.

Rendre les frontières d’accès ouvertes à l’examen

Une conception de sécurité doit comporter des détails d’implémentation concrets à examiner. Le code source public permet aux développeurs de vérifier :

• La gestion des identifiants : quelle frontière de runtime détient les identifiants bruts, et quels chemins d’appel les utilisent.
• Les permissions requises : quelles portées un connecteur déclare, et ce que l’autorisation de lecture et d’écriture exige.
• La validation des modifications : quel problème une correction résout, quels contrôles de régression elle ajoute, et qui a contribué.

Cela donne à la communauté un point d’entrée public pour l’examen. Les développeurs et les chercheurs en sécurité peuvent inspecter les implémentations, poser des questions et signaler des vulnérabilités potentielles en privé via la politique de sécurité. Les équipes configurent toujours l’autorisation de compte et l’accès en fonction de leurs tâches.

En plus de maintenir ces capacités, nous mettons les projets de connexion, de workflow et de client à la disposition des développeurs pour qu’ils les réutilisent dans leurs propres produits.

Définir l’autorisation autour d’une tâche d’équipe

Imaginons une équipe demandant à Leina :

Lisez les e-mails clients de cette semaine, identifiez les éléments à suivre, incluez des liens vers les messages originaux et préparez un brouillon pour moi.

Cet exemple explique la relation de connexion. Les opérations disponibles dépendent du support du connecteur, de l’autorisation de compte et des paramètres d’équipe.

Leina doit interpréter la demande, sélectionner les opérations de lecture des e-mails et organiser le résultat. OpenConnector fournit les capacités de connexion et d’exécution pour ces opérations : utiliser un compte autorisé, vérifier les frontières d’accès pertinentes et appeler l’application métier.

flowchart TB
  accTitle: D'une tâche aux applications autorisées
  accDescr: Une équipe demande un travail dans le chat. Leina sélectionne les opérations requises et utilise l'autorisation et les contrôles d'accès d'OpenConnector pour atteindre les applications métier autorisées.
  T("Tâche d'équipe"):::channel --> L("Leina"):::agent
  L --> G("OpenConnector\nAutorisation et contrôle d'accès"):::gateway
  G --> A("Applications autorisées\nE-mails, documents, dossiers d'entreprise"):::resource

Leina fournit l’expérience IA pour l’équipe. OpenConnector fournit l’infrastructure de connexion aux applications. La passerelle peut fonctionner indépendamment, avec un accès SDK, CLI, MCP et HTTP/OpenAPI. D’autres développeurs peuvent la connecter à leurs propres agents ou applications. Architecture et chemins d’accès

Comment les identifiants, les actions et l’accès aux données s’articulent

Les applications métier diffèrent par leurs méthodes d’autorisation, leurs définitions de permissions, leurs entrées, leurs sorties et leur gestion des erreurs. Lire un e-mail et modifier un enregistrement client nécessitent également des accès différents. À mesure que le nombre d’applications et de tâches augmente, ces détails déterminent si un agent peut accomplir son travail de manière fiable.

Nous maintenons les capacités de connexion dans une passerelle distincte. Les clients peuvent découvrir les actions, inspecter les schémas d’entrée et de sortie et les permissions requises, puis choisir une connexion à exécuter. Les identifiants bruts du fournisseur restent derrière la frontière du runtime ; les agents reçoivent les métadonnées et les résultats nécessaires à l’exécution. Capacités de la passerelle

Cette séparation donne aussi aux améliorations un emplacement clair. Un fournisseur peut avoir besoin d’une déclaration de portée en lecture seule, une action peut avoir besoin d’un schéma d’entrée corrigé, ou un téléchargement de fichier peut nécessiter un meilleur traitement. Chacun peut être examiné et modifié dans la couche de connexion, avec un enregistrement public du travail.

Les mêmes identifiants de fournisseur, identifiants d’action et contrats peuvent servir différents chemins d’accès. Les développeurs peuvent organiser les tâches autour de leurs produits tout en réutilisant le travail de connexion. Outils pour développeurs

Nos contributions à la communauté open source

Notre contribution à l’open source comprend une passerelle utilisable de manière indépendante, des outils pour l’appeler et un espace continu pour maintenir ces projets ensemble.

Les développeurs peuvent inspecter les déclarations de permissions, les schémas d’action et le code de l’exécuteur. Ils peuvent aussi exécuter leur propre OpenConnector. Les opérateurs auto-hébergés configurent le stockage, l’authentification et leurs propres applications OAuth, et maintiennent l’environnement conformément à la documentation de déploiement. Configuration auto-hébergée

OpenFlow place les étapes de workflow sur un canevas inspectable. Il peut fonctionner indépendamment et utiliser un runtime de connecteur tel qu’OpenConnector pour découvrir et exécuter des actions d’application. Les identifiants de compte restent dans la couche de connexion tandis que les workflows font référence aux identités de connexion. Le projet est actuellement en bêta. Comment OpenFlow connecte les applications

Ces projets fournissent des capacités de connexion, de workflow et d’accès client. La licence de chaque dépôt définit son périmètre open source, tandis que les services et ressources tiers conservent leurs propres conditions. Notre page Open Source rassemble les projets, les nombres d’étoiles et les parcours de participation.

Améliorer ensemble l’autorisation et la sécurité des connexions

La valeur d’une contribution se révèle dans le problème qu’elle résout. Ces deux pull requests communautaires fusionnées traitent des déclarations de permissions et de la gestion du cycle de vie des connexions. Elles démontrent des améliorations dans le dépôt public ; elles n’établissent pas que la version de production actuelle de Leina a déployé ces changements.

Gmail : demander l’accès pour une tâche en lecture seule

La déclaration Gmail précédente utilisait une seule liste de portées pour les comptes de service et l’OAuth utilisateur. Cette liste convenait aux comptes de service, mais omettait gmail.readonly parmi les portées qu’une intégration OAuth utilisateur pouvait demander. Une intégration qui avait seulement besoin de lire des messages ne pouvait pas demander un accès en lecture seule via cette seule déclaration.

Dans la PR #586, le contributeur @bakey a séparé les listes. La déclaration OAuth utilisateur ajoute l’accès en lecture seule, tandis que les comptes de service conservent leur liste de portées existante. Cela permet aux intégrations en lecture seule de choisir une autorisation appropriée et préserve l’autorisation existante des comptes de service. La PR ajoute également des contrôles de régression pour ces frontières.

Pour une tâche de résumé d’e-mails, des détails comme celui-ci affectent la quantité d’accès dont l’intégration a besoin. Publier les déclarations et la modification permet aux développeurs d’inspecter la frontière et de choisir la portée appropriée pour leur propre intégration.

OAuth : maintenir une connexion déconnectée comme déconnectée

L’autorisation peut chevaucher d’autres opérations. Un callback OAuth encore en cours pouvait se terminer après qu’un utilisateur se soit déconnecté et réécrire des identifiants dans le stockage.

Le contributeur @powerfulZ a traité cette condition de course dans la PR #698. La déconnexion fait avancer une génération de retrait durable. Avant de stocker les identifiants, le flux d’autorisation vérifie si sa génération capturée est toujours valide. Un flux d’autorisation obsolète ne peut plus restaurer une connexion déconnectée, tandis qu’un nouveau consentement explicite peut la reconnecter.

L’enregistrement de validation de la PR couvre les chemins de stockage SQLite, D1 et PostgreSQL pertinents. L’amélioration rend le changement d’état derrière « déconnexion » plus complet et donne aux mainteneurs une couverture de régression publique pour le vérifier à nouveau.

Ces résultats combinent la maintenance du projet avec les contributions de la communauté. Nous préservons le crédit des contributeurs et publions les capacités ajoutées, les corrections et les participants dans les notes de version.

Vérifier les preuves et adapter l’accès à la tâche

Le code source public donne aux utilisateurs et aux développeurs des éléments concrets à examiner : les permissions qu’un connecteur déclare, les entrées qu’une action accepte, la façon dont son exécuteur appelle une application en amont, et les contrôles ajoutés par une correction.

Son utilisation nécessite toujours de vérifier l’application, le compte et l’opération spécifiques. OpenConnector distingue la couverture du catalogue, les actions exécutables localement et les actions avec preuve de vérification contre une API amont réelle. Les totaux de connexions décrivent la couverture ; la disponibilité d’une tâche particulière nécessite sa propre vérification. Langage de vérification du projet

Pour les utilisateurs d’équipe, commencez via Leina avec une tâche en lecture seule claire. Examinez le résultat et ses sources, puis élargissez l’accès selon les besoins. Lisez Connexions d’applications sécurisées pour l’autorisation de compte et une première tâche, ou Permissions d’agent d’équipe pour les frontières d’accès partagées.

Pour les développeurs, exécutez OpenConnector, inspectez les actions dont vous avez besoin et connectez votre agent ou produit. Signalez les problèmes avec des étapes reproductibles. Suivez le guide de contribution lorsque vous soumettez du code, de la documentation et des résultats de vérification. Signalez l’exposition d’identifiants ou les vulnérabilités potentielles en privé via la politique de sécurité.

Nous mettons les implémentations des composants clés à la disposition des développeurs pour examen et utilisons la collaboration publique pour améliorer l’autorisation et les connexions. Les équipes peuvent examiner la fondation derrière Leina, tandis que d’autres développeurs peuvent réutiliser les projets et contribuer des améliorations à la communauté.