Conexiones seguras de Leina y compromiso con el código abierto

Ilustración conceptual: las tareas del equipo llegan a las aplicaciones empresariales a través de conexiones autorizadas.

Antes de pedirle a la IA que organice correos, busque documentos o actualice registros empresariales, un equipo necesita límites de acceso claros: qué cuenta se utiliza, qué operaciones están permitidas, quién puede usar una conexión y quién recibe el resultado.

Leina accede a las aplicaciones empresariales a través de conexiones autorizadas y utiliza permisos de miembros y grupos para gestionar el acceso disponible. OpenConnector gestiona las conexiones de aplicaciones. Las credenciales de cuenta sin procesar permanecen dentro del entorno de ejecución de la conexión, mientras que el agente utiliza las operaciones y los resultados necesarios para la tarea. Arquitectura de conexión

Publicamos el código de componentes clave y la documentación para que los desarrolladores puedan examinar el manejo de credenciales, las declaraciones de permisos y la lógica de llamadas, y ayudar a mejorarlos. Los proyectos públicos proporcionan detalles de implementación y registros de colaboración; las credenciales y los datos empresariales siguen sujetos a la autorización de conexión y a la configuración de acceso.

Hacer que los límites de acceso estén abiertos a revisión

Un diseño de seguridad debe tener detalles de implementación concretos que se puedan examinar. El código fuente público permite a los desarrolladores comprobar:

• Manejo de credenciales: qué límite del entorno de ejecución contiene las credenciales sin procesar y qué rutas de llamada las utilizan.
• Permisos requeridos: qué ámbitos declara un conector y qué requieren la lectura y la escritura autorizadas.
• Validación de cambios: qué problema resuelve una corrección, qué comprobaciones de regresión añade y quién contribuyó.

Esto proporciona a la comunidad un punto de entrada público para la revisión. Los desarrolladores e investigadores de seguridad pueden inspeccionar las implementaciones, plantear preguntas y reportar posibles vulnerabilidades de forma privada a través de la política de seguridad. Los equipos siguen configurando la autorización de cuentas y el acceso para adaptarlos a sus tareas.

Además de mantener estas capacidades, ponemos los proyectos de conexión, flujo de trabajo y cliente a disposición de los desarrolladores para que los reutilicen en sus propios productos.

Definir la autorización en torno a una tarea de equipo

Imagina que un equipo le pide a Leina:

Lee los correos de clientes de esta semana, identifica los elementos de seguimiento, incluye enlaces a los mensajes originales y prepárame un borrador.

Este ejemplo explica la relación de conexión. Las operaciones disponibles dependen del soporte del conector, la autorización de la cuenta y la configuración del equipo.

Leina necesita interpretar la solicitud, seleccionar las operaciones para leer correos y organizar el resultado. OpenConnector proporciona las capacidades de conexión y ejecución para esas operaciones: usar una cuenta autorizada, comprobar los límites de acceso relevantes y llamar a la aplicación empresarial.

flowchart TB
  accTitle: De una tarea a las aplicaciones autorizadas
  accDescr: Un equipo solicita trabajo en el chat. Leina selecciona las operaciones necesarias y utiliza la autorización y los controles de acceso de OpenConnector para llegar a las aplicaciones empresariales autorizadas.
  T("Tarea de equipo"):::channel --> L("Leina"):::agent
  L --> G("OpenConnector\nAutorización y control de acceso"):::gateway
  G --> A("Aplicaciones autorizadas\nCorreo electrónico, documentos, registros empresariales"):::resource

Leina proporciona la experiencia de IA para el equipo. OpenConnector proporciona la infraestructura de conexión de aplicaciones. La puerta de enlace puede ejecutarse de forma independiente, con acceso mediante SDK, CLI, MCP y HTTP/OpenAPI. Otros desarrolladores pueden conectarla a sus propios agentes o aplicaciones. Arquitectura y rutas de acceso

Cómo encajan las credenciales, las acciones y el acceso a los datos

Las aplicaciones empresariales difieren en métodos de autorización, definiciones de permisos, entradas, salidas y manejo de errores. Leer un correo y modificar un registro de cliente también requieren accesos diferentes. A medida que crece el número de aplicaciones y tareas, estos detalles afectan a si un agente puede completar su trabajo de forma fiable.

Mantenemos las capacidades de conexión en una puerta de enlace separada. Los clientes pueden descubrir acciones, inspeccionar los esquemas de entrada y salida y los permisos requeridos, y luego elegir una conexión para ejecutar. Las credenciales sin procesar del proveedor permanecen detrás del límite del entorno de ejecución; los agentes reciben los metadatos y los resultados necesarios para la ejecución. Capacidades de la puerta de enlace

Esta división también da a las mejoras un lugar claro. Un proveedor puede necesitar una declaración de ámbito de solo lectura, una acción puede necesitar un esquema de entrada corregido, o una descarga de archivo puede necesitar un mejor manejo. Cada uno puede examinarse y modificarse en la capa de conexión, con un registro público del trabajo.

Los mismos IDs de proveedor, IDs de acción y contratos pueden servir a diferentes rutas de acceso. Los desarrolladores pueden organizar tareas en torno a sus productos mientras reutilizan el trabajo de conexión. Herramientas para desarrolladores

Nuestras contribuciones a la comunidad de código abierto

Nuestra contribución al código abierto incluye una puerta de enlace utilizable de forma independiente, herramientas para llamarla y un espacio continuo para mantener estos proyectos juntos.

Los desarrolladores pueden inspeccionar las declaraciones de permisos, los esquemas de acciones y el código del ejecutor. También pueden ejecutar su propio OpenConnector. Los operadores autoalojados configuran el almacenamiento, la autenticación y sus propias aplicaciones OAuth, y mantienen el entorno según la documentación de despliegue. Configuración autoalojada

OpenFlow coloca los pasos del flujo de trabajo en un lienzo inspeccionable. Puede ejecutarse de forma independiente y usar un entorno de ejecución de conectores como OpenConnector para descubrir y ejecutar acciones de aplicaciones. Las credenciales de cuenta permanecen en la capa de conexión mientras los flujos de trabajo hacen referencia a identidades de conexión. El proyecto está actualmente en beta. Cómo conecta OpenFlow las aplicaciones

Estos proyectos proporcionan capacidades de conexión, flujo de trabajo y acceso de cliente. La licencia de cada repositorio define su alcance de código abierto, mientras que los servicios y activos de terceros conservan sus propios términos. Nuestra página de código abierto reúne los proyectos, los recuentos de estrellas y las vías de participación.

Mejorar juntos la autorización y la seguridad de las conexiones

El valor de una contribución se hace evidente en el problema que resuelve. Estas dos solicitudes de extracción fusionadas de la comunidad abordan las declaraciones de permisos y el manejo del ciclo de vida de las conexiones. Demuestran mejoras en el repositorio público; no establecen que la versión de producción actual de Leina haya desplegado estos cambios.

Gmail: solicitar acceso para una tarea de solo lectura

La declaración anterior de Gmail usaba una única lista de ámbitos tanto para cuentas de servicio como para OAuth de usuario. Esa lista era adecuada para cuentas de servicio, pero omitía gmail.readonly de los ámbitos que una integración OAuth de usuario podía solicitar. Una integración que solo necesitaba leer mensajes no podía solicitar acceso de solo lectura solo a través de esa declaración.

En PR #586, el colaborador @bakey separó las listas. La declaración OAuth de usuario añade acceso de solo lectura, mientras que las cuentas de servicio conservan su lista de ámbitos existente. Esto permite que las integraciones de solo lectura elijan una concesión adecuada y preserva la autorización existente de las cuentas de servicio. La PR también añade comprobaciones de regresión para esos límites.

Para una tarea de resumen de correo, detalles como este afectan a cuánto acceso necesita la integración. Publicar las declaraciones y el cambio permite a los desarrolladores inspeccionar el límite y elegir el ámbito adecuado para su propia integración.

OAuth: mantener desconectada una conexión desconectada

La autorización puede solaparse con otras operaciones. Una devolución de llamada OAuth aún en curso podría finalizar después de que un usuario se desconecte y volver a escribir credenciales en el almacenamiento.

El colaborador @powerfulZ abordó esa condición de carrera en PR #698. La desconexión avanza una generación de retiro duradera. Antes de almacenar credenciales, el flujo de autorización comprueba si su generación capturada sigue siendo válida. Un flujo de autorización obsoleto ya no puede restaurar una conexión desconectada, mientras que un consentimiento explícito nuevo puede volver a conectarla.

El registro de validación de la PR cubre las rutas de almacenamiento relevantes de SQLite, D1 y PostgreSQL. La mejora hace más completo el cambio de estado detrás de “desconectar” y proporciona a los mantenedores una cobertura de regresión pública para volver a comprobarlo.

Estos resultados combinan el mantenimiento del proyecto con las contribuciones de la comunidad. Preservamos el crédito de los colaboradores y publicamos las capacidades añadidas, las correcciones y los participantes en las notas de la versión.

Comprueba la evidencia y adapta el acceso a la tarea

El código fuente público ofrece a usuarios y desarrolladores cosas concretas que examinar: los permisos que declara un conector, las entradas que acepta una acción, cómo su ejecutor llama a una aplicación ascendente y las comprobaciones añadidas por una corrección.

Usarlo sigue requiriendo comprobar la aplicación, la cuenta y la operación específicas. OpenConnector distingue la cobertura del catálogo, las acciones ejecutables localmente y las acciones con evidencia de verificación contra una API ascendente real. Los totales de conexiones describen la cobertura; la disponibilidad de una tarea concreta necesita su propia comprobación. Lenguaje de verificación del proyecto

Para los usuarios de equipo, empieza a través de Leina con una tarea de solo lectura clara. Revisa el resultado y sus fuentes, y luego amplía el acceso según sea necesario. Lee Conexiones seguras de aplicaciones para la autorización de cuentas y una primera tarea, o Permisos del agente de equipo para los límites de acceso compartido.

Para los desarrolladores, ejecuta OpenConnector, inspecciona las acciones que necesites y conecta tu agente o producto. Reporta problemas con pasos reproducibles. Sigue la guía de contribución al enviar código, documentación y resultados de comprobaciones. Reporta la exposición de credenciales o posibles vulnerabilidades de forma privada a través de la política de seguridad.

Ponemos las implementaciones de componentes clave a disposición de los desarrolladores para su revisión y usamos la colaboración pública para mejorar la autorización y las conexiones. Los equipos pueden examinar la base detrás de Leina, mientras que otros desarrolladores pueden reutilizar los proyectos y contribuir mejoras a la comunidad.