OpenConnector: an auth gateway that keeps provider credentials out of agent processes

The problem: agents should not hold user credentials

AI agents need to act on behalf of users across Gmail, GitHub, Slack, Notion, and hundreds of other services. The naive approach is to give the agent an API key or OAuth token for each service. That spreads credentials into every agent process, makes rotation painful, and leaves no audit trail. OpenConnector positions itself as a gateway that sits between the agent and the provider. The agent talks to the gateway over SDK, CLI, MCP, or HTTP. The gateway holds the credentials, enforces scopes and policies, and returns only execution results. The README states that provider secrets stay behind the runtime boundary. This is a concrete answer to a specific problem: durable access to user tools without handing credentials to the agent process. The intended users are agent products that need reusable access across work apps, developer tools, data systems, and communication platforms.

Architecture: a gateway with an auth boundary and a provider catalog

The README includes a Mermaid flowchart that shows the data flow. An AI agent or app connects to the OpenConnector Gateway via SDK, CLI, MCP, or HTTP. The gateway then talks to a credential and OAuth boundary, a provider catalog, open-source action executors, a token and scopes policy layer, and run logs. The action executors reach out to the 1,000+ providers. A web console also connects to the gateway for administration. The key mechanism is that the agent never directly contacts the provider. Instead, it discovers actions, inspects schemas and scopes, selects a connection alias, and executes through the gateway. The gateway applies allow and block policies, manages runtime tokens, and stores redacted run logs. This design gives you a single place to audit who did what with which account. The catalog is shared, so the same provider ids and action ids work across deployments, which matters if you start with the hosted runtime and later move to self-hosted.

Three deployment paths with different trade-offs

The README lists three ways to run OpenConnector. First, OOMOL Hosted: a managed runtime with no deployment or OAuth app setup. You just use the Connector SDK or the oo CLI. Second, Cloudflare: deploy to Workers, D1, R2, and Static Assets inside your own Cloudflare account. You manage deployment and OAuth apps. Third, self-hosted: run locally or on your own infrastructure with Docker or Node.js, using SQLite or PostgreSQL for state and local or S3-compatible storage for transit. You manage storage and OAuth apps. The trade-off is clear: the hosted path is fastest but puts your runtime in someone else's hands. The Cloudflare and self-hosted paths give you control over data and credentials but require you to handle OAuth app registration, which is often the most tedious part of connecting to SaaS providers. The README also mentions Fly.io as a deployment option, though it does not give details. If you need to be in a specific region or comply with data residency rules, the self-hosted path is the only one that gives you full control.

Getting started: SDK, CLI, MCP, and HTTP endpoints

The README points to several tools. The Connector SDK is a thin TypeScript HTTP client. You use the OpenConnector class for self-hosted runtimes, or Connector and ProjectConnector for OOMOL-hosted personal and SaaS end-user connections. The oo CLI is a local agent relay. The command oo connector can search, inspect, and run actions against either hosted or self-hosted runtimes. For MCP-capable agent hosts, OpenConnector exposes actions at http://localhost:3000/mcp. For custom clients, you can call /v1/actions/* directly or inspect the generated /openapi.json document. The README does not give a full command sequence for installation, but it does say the project ships with a local Dashboard for browsing connectors, configuring credentials, and creating runtime tokens. The usage paths table in the README was truncated, so the exact commands for each path are not fully visible. You will need to consult docs/runtime-api.md for endpoint details, response envelopes, and auth headers, as the README explicitly references that file.

What the catalog and actions actually cover

The README claims a working connector catalog across products such as GitHub, Gmail, Notion, BigQuery, Google Analytics, Supabase, Airtable, Slack, and more. It also claims 10,000+ prebuilt actions. But the README does not list the full catalog. The provider names are trademarks of their respective owners, used only for identification. This is a limitation: you cannot verify from the README whether your specific long-tail SaaS is covered. The catalog is a core value proposition, so you would need to inspect the dashboard or the catalog search to confirm coverage before committing. The README also states that actions have inspectable contracts: request and response schemas, required scopes, and lazy-loaded executor source. That is a useful property for debugging and for building trust, because you can see exactly what an action does before you let an agent call it. But lazy-loaded executor source means the code is not all upfront; you fetch it on demand, which could add latency on first execution.

Credential handling and policy controls

OpenConnector supports API keys, OAuth2, custom credentials, and no-auth providers. That covers most real-world cases. The runtime controls include connection identity, scopes, runtime tokens, action allow and block policies, temporary file transit, and redacted run logs. The allow and block policies are particularly important for safety: you can restrict which actions an agent can execute, even if the underlying account has broader permissions. The README says run logs are redacted, which is a sensible default for privacy, but it also means you might not see the full request and response payloads when debugging. The credential boundary is the core of the design. The agent receives metadata, safe account labels, and execution results, but not the secrets. This is a strong security posture for agent products, but it also means you need to trust the gateway itself. If you self-host, you control that trust. If you use the hosted runtime, you are trusting OOMOL with your users' credentials.

Limitations and failure modes

The most obvious limitation is that the README is light on operational details. It does not specify rate limits, latency characteristics, or what happens when a provider changes its API. The catalog and action executors are open source, so you can inspect them, but the maintenance burden falls on you if a provider breaks. Another failure mode: the self-hosted path requires you to manage OAuth apps for each provider. That is a significant operational cost, especially if you need to support hundreds of providers. The hosted path avoids that but introduces a dependency on OOMOL's availability and pricing, which are not described in the README. Also, the README mentions temporary file transit, which suggests the gateway can move files between the agent and the provider, but the details are not given. If your workflows rely on large file transfers, you need to verify the transit storage limits, especially on Cloudflare Workers where there are hard size constraints. Finally, the project is relatively young, with the latest release v1.4.0 pushed in August 2026, so the ecosystem around it, like community connectors, is still forming.

Alternatives: Pipedream and Composio take different approaches

The README explicitly names Pipedream and Composio as alternatives. Pipedream is a workflow automation platform that also offers a connector gateway, but its primary model is event-driven workflows with a hosted execution environment. You write Node.js or Python code steps that run on Pipedream's infrastructure. Composio, on the other hand, focuses on giving AI agents access to tools through a managed platform, with a strong emphasis on MCP and function calling. The difference in approach is where the runtime lives. Pipedream and Composio are primarily hosted services; you do not typically run their gateway on your own infrastructure. OpenConnector's differentiator is that you can self-host on Docker, Fly.io, or Cloudflare Workers, giving you control over credentials and logs. That matters for enterprises with compliance requirements. But it also means you take on the operational burden. If you want a fully managed solution and do not care about data residency, Pipedream or Composio might be simpler. If you need to keep everything inside your own cloud account, OpenConnector's self-hosted path is the relevant comparison.

Maintenance, upgrade, and licensing

The project is licensed under Apache-2.0, which permits commercial use, modification, and distribution, with the requirement to preserve copyright notices. That is a permissive license, but you should read the full LICENSE.txt in the repository for any additional terms, since the README links to it. The repository is actively maintained, with releases v1.4.0, v1.3.5, and v1.3.4 in August 2026, which suggests a regular release cadence. The README does not describe an upgrade process. Since the project is a gateway, upgrading likely involves swapping the runtime binary or container image, but you must check the release notes for breaking changes. The use of SQLite or PostgreSQL for state means migrations could be needed between versions. Also, the action executors are lazy-loaded, so updates to the catalog might be pushed separately from the core runtime. You should plan for a testing cycle before upgrading in production, especially if you have custom policies or connections that depend on specific action schemas.

Editorial conclusion

Adopt OpenConnector if your product needs durable, inspectable access to user SaaS accounts without exposing credentials to agent processes, and you want the option to start hosted then move to self-hosted. Skip it if you only need a handful of APIs, or if you cannot accept the operational burden of managing OAuth apps and storage in the self-hosted path. Before adopting, verify that the provider catalog covers your exact services and that the Action schemas match your workflows, since the README does not list the full catalog. Also confirm your preferred deployment target (Docker, Fly.io, Cloudflare Workers, or OOMOL hosted) is supported for your scale, and check the license terms for any commercial use restrictions beyond Apache-2.0.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes