Leina’s Secure Connections and Open Source Commitment

Conceptual illustration: team tasks reach business apps through authorized connections.

Before asking AI to organize email, find documents, or update business records, a team needs clear access boundaries: which account is used, which operations are allowed, who may use a connection, and who receives the result.

Leina accesses business apps through authorized connections and uses member and group permissions to manage available access. OpenConnector handles app connections. Raw account credentials stay within the connection runtime, while the agent uses the operations and results needed for the task. Connection architecture

We publish key component code and documentation so developers can examine credential handling, permission declarations, and call logic, and help improve them. The public projects provide implementation details and collaboration records; credentials and business data remain subject to connection authorization and access configuration.

Making Access Boundaries Open to Review

A security design should have concrete implementation details to examine. Public source lets developers check:

• Credential handling: Which runtime boundary holds raw credentials, and which call paths use them.
• Required permissions: Which scopes a connector declares, and what authorization reading and writing require.
• Validation of changes: Which problem a fix addresses, which regression checks it adds, and who contributed.

This gives the community a public entry point for review. Developers and security researchers can inspect implementations, raise questions, and report potential vulnerabilities privately through the security policy. Teams still configure account authorization and access to match their tasks.

Alongside maintaining these capabilities, we make the connection, workflow, and client projects available for developers to reuse in their own products.

Defining Authorization Around a Team Task

Imagine a team asking Leina:

Read this week’s customer emails, identify follow-up items, include links to the original messages, and prepare a draft for me.

This example explains the connection relationship. Available operations depend on connector support, account authorization, and team settings.

Leina needs to interpret the request, select the operations for reading email, and organize the result. OpenConnector provides the connection and execution capabilities for those operations: using an authorized account, checking the relevant access boundaries, and calling the business app.

flowchart TB
  accTitle: From a task to authorized apps
  accDescr: A team requests work in chat. Leina selects the required operations and uses OpenConnector authorization and access controls to reach authorized business apps.
  T(Team task):::channel --> L(Leina):::agent
  L --> G("OpenConnector\nAuthorization and access control"):::gateway
  G --> A("Authorized apps\nEmail, documents, business records"):::resource

Leina provides the team AI experience. OpenConnector provides the app connection infrastructure. The gateway can run independently, with SDK, CLI, MCP, and HTTP/OpenAPI access. Other developers can connect it to their own agents or applications. Architecture and access paths

How Credentials, Actions, and Data Access Fit Together

Business apps differ in authorization methods, permission definitions, inputs, outputs, and error handling. Reading an email and changing a customer record also require different access. As the number of apps and tasks grows, these details affect whether an agent can complete its work reliably.

We maintain connection capabilities in a separate gateway. Clients can discover actions, inspect input and output schemas and required permissions, then choose a connection to execute. Raw provider credentials stay behind the runtime boundary; agents receive the metadata and results needed for the run. Gateway capabilities

This division also gives improvements a clear home. A provider may need a read-only scope declaration, an action may need a corrected input schema, or a file download may need better handling. Each can be examined and changed in the connection layer, with a public record of the work.

The same provider IDs, action IDs, and contracts can serve different access paths. Developers can organize tasks around their products while reusing the connection work. Developer tools

Our Contributions to the Open Source Community

Our contribution to open source includes an independently usable gateway, tools for calling it, and an ongoing space for maintaining these projects together.

Developers can inspect permission declarations, action schemas, and executor code. They can also run their own OpenConnector. Self-hosted operators configure storage, authentication, and their own OAuth apps, and maintain the environment according to the deployment documentation. Self-hosted setup

OpenFlow puts workflow steps on an inspectable canvas. It can run independently and use a connector runtime such as OpenConnector to discover and execute app actions. Account credentials stay in the connection layer while workflows refer to connection identities. The project is currently in beta. How OpenFlow connects apps

These projects provide connection, workflow, and client access capabilities. Each repository’s license defines its open-source scope, while third-party services and assets retain their own terms. Our Open Source page brings together the projects, Star counts, and participation paths.

Improving Authorization and Connection Security Together

The value of a contribution becomes clear in the problem it solves. These two merged community pull requests address permission declarations and connection lifecycle handling. They demonstrate improvements in the public repository; they do not establish that Leina’s current production version has deployed these changes.

Gmail: Requesting Access for a Read-Only Task

The previous Gmail declaration used one scope list for both service accounts and user OAuth. That list was appropriate for service accounts, but it omitted gmail.readonly from the scopes a user OAuth integration could request. An integration that only needed to read messages could not request read-only access through that declaration alone.

In PR #586, contributor @bakey separated the lists. The user OAuth declaration adds read-only access, while service accounts retain their existing scope list. This lets read-only integrations choose an appropriate grant and preserves existing service-account authorization. The PR also adds regression checks for those boundaries.

For an email-summary task, details like this affect how much access the integration needs. Publishing the declarations and the change lets developers inspect the boundary and choose the scope appropriate for their own integration.

OAuth: Keeping a Disconnected Connection Disconnected

Authorization can overlap with other operations. An OAuth callback still in progress could finish after a user disconnects and write credentials back into storage.

Contributor @powerfulZ addressed that race in PR #698. Disconnecting advances a durable retirement generation. Before storing credentials, the authorization flow checks whether its captured generation is still valid. An outdated authorization flow can no longer restore a disconnected connection, while fresh explicit consent can reconnect it.

The PR’s validation record covers the relevant SQLite, D1, and PostgreSQL storage paths. The improvement makes the state change behind “disconnect” more complete and gives maintainers public regression coverage to check it again.

These results combine project maintenance with community contributions. We preserve contributor credit and publish added capabilities, fixes, and participants in the release notes.

Check the Evidence and Match Access to the Task

Public source gives users and developers concrete things to examine: the permissions a connector declares, the inputs an action accepts, how its executor calls an upstream app, and the checks added by a fix.

Using it still requires checking the specific app, account, and operation. OpenConnector distinguishes catalog coverage, locally executable actions, and actions with evidence of verification against a real upstream API. Connection totals describe coverage; a particular task’s availability needs its own check. Project verification language

For team users, start through Leina with a clear read-only task. Review the result and its sources, then expand access as needed. Read Secure App Connections for account authorization and a first task, or Team Agent Permissions for shared access boundaries.

For developers, run OpenConnector, inspect the actions you need, and connect your agent or product. Report issues with reproducible steps. Follow the contribution guide when submitting code, documentation, and check results. Report credential exposure or potential vulnerabilities privately through the security policy.

We make key component implementations available for developer review and use public collaboration to improve authorization and connections. Teams can examine the foundation behind Leina, while other developers can reuse the projects and contribute improvements back to the community.