OpenConnector Deep Dive: 1.16M Lines of Code and 1,451 Providers Hide Ten Security Pitfalls

Forum topic · 二一 · 2026-08-29

Summary

A source-code-level review of the open-source project OpenConnector (oomol-lab/open-connector), an integration gateway that lets AI agents operate external SaaS tools without exposing credentials to the agent process. The author cloned the repository and verified claims against GitHub API data: 5,397 stars two months after launch, 1,451 provider directories, and 10,925 action definitions—the advertised numbers hold up, though 96.9% of the 1.16 million lines of TypeScript live in shallow provider wrappers, with only ~36k lines of actual gateway core. Notably, only 7% of providers support OAuth2, so most still require users to paste API keys. The review credits the project's credential isolation boundary and restrained MCP design (five meta-tools), but documents ten verified weaknesses, including zero-auth-by-default, fail-open encryption, a globally hardcoded KDF salt, a permissive proxy endpoint that bypasses action policies, and a static root-equivalent ADMIN_TOKEN. The post compares OpenConnector against Composio, Pipedream, and Arcade, and offers deployment recommendations: best fit for multi-agent research systems, caution for quantitative trading, and not recommended for consumer products without the five mandatory hardening steps listed.

Recently, while doing Agent technology selection, one question was unavoidable: when an Agent needs to operate external SaaS tools (GitHub, Gmail, Slack, Notion...), where do the credentials live? Having every team manage OAuth themselves is painful, and handing everything to a cloud vendor is uncomfortable. Pipedream and Composio are two ready answers, but both are closed-source SaaS. So I dissected the loudest project in the open-source camp: OpenConnector (oomol-lab/open-connector)—cloned the source and read it line by line, verified data via the GitHub API. Not second-hand README paraphrasing.

Verified Numbers

5,397 stars (launched 2026-06-29, two months old), 461 forks, only 4 open issues, 73 contributors, pushes still active yesterday—genuinely active maintenance.
Claimed: 1000+ providers / 10000+ actions. Measured in source: 1,451 provider directories and 10,925 defineProviderAction calls. The numbers aren't inflated.
But look at the structure: src totals 1.168 million lines of TypeScript, of which the providers directory is 96.9%. The real gateway kernel is only ~36k lines. Most providers are shallow three-file wrappers.
The auth-type distribution is sobering: 1,254 use api_key, only 58 use oauth2 (4%), plus 38 with dual support—OAuth coverage is roughly 7%. So-called "managed OAuth" doesn't exist for most providers; users still paste their own keys.

What It Gets Right: Credentials Never Enter the Agent Process

This is the project's soul. When an Agent invokes a tool, it only sees connection metadata (id, authType, grantedScopes). Full credentials with accessTokens are injected in-process via the executor context and never cross the HTTP boundary. Combined with sanitized runtime logs and allow/block policies, this boundary concept is correct and valuable. The MCP integration is restrained: only five meta-tools—list_apps / list_connections / search_actions / get_action_guide / execute_action—so 10,925 actions all hide behind execute_action and won't blow up the agent's context.

Ten Pitfalls (All Verified in Source)

The five harshest:

1. Zero auth by default, silently allowed. auth.ts:114—without adminToken configured, it simply sets authenticated: true. Combined with the Dockerfile's HOST=0.0.0.0 and compose's 3000:3000, starting the service per the README yields an unauthenticated gateway listening on the host port. Not a bug—a default-value choice. 2. Encryption fail-open. secret-codec.ts:39—when reading credentials, it checks the prefix; anything without the ciphertext prefix is returned as plaintext. Plaintext and ciphertext coexist in the same column, with no enforced "this instance must encrypt" assertion. Without an encryption key set, credentials are stored in plaintext with only a startup warning. 3. KDF uses a hardcoded global salt. All deployments share the same salt string, making cross-deployment precomputation theoretically feasible. Also, Node-side scrypt and Worker-side PBKDF2 produce incompatible ciphertexts (different prefixes), so migrating SQLite to D1 requires decrypt-and-re-encrypt—the docs don't mention it. 4. POST /v1/proxy/:service is a big hole at the boundary. It accepts arbitrary endpoint/method/headers/body, injects credentials, and forwards—action-level scopes and allow/block policies have no effect on it (docs' own words: "Action policy does not affect it"). This downgrades least-privilege to "full proxy power for whoever holds the key." Fully disabling it requires explicitly setting BLOCKED_PROXIES="*". 5. A static ADMIN_TOKEN is de facto root. No expiry, no rotation, no scopes—yet it governs credential writes and token issuance. Also worth noting: on 2026-08-27, Marketplace billing code landed on the open-source mainline—today's optional module may become tomorrow's default path.

(The other five: globally shared idempotency keys, the MCP three-hop discovery chain, schemas abandoning type safety, 1,451 machine-generated providers with no compile-time quality guarantees, and JWT only usable on the Node side—details in the full report.)

Competitive Landscape at a Glance

| Dimension | OpenConnector | Composio | Pipedream | Arcade | |---|---|---|---|---| | Open source | Apache-2.0, fully self-hostable | MIT core + managed commercial | Closed-source; acquired by Workday | Closed-source | | Strength | Highest self-hosting freedom; you own credentials | Most mature managed OAuth; 20k free calls/month | 3000+ apps, SOC2/HIPAA | Most refined authorization model, SOC2 | | Weakness | Poor default security posture; only 7% OAuth | Runaway bills at scale | Post-acquisition agent direction unclear | Narrow integration surface (44 apps) |

For comparison with bare MCP servers: with few services (≤3 headlining ones), just attach the official MCP servers directly for the deepest integration. Once services multiply, you need a gateway to consolidate the boundary—this is exactly OpenConnector's niche.

My Three Business-Line Judgments

Multi-agent research systems: best fit. MCP integration is natural; just accept the latency of the three-hop discovery chain.
Quantitative trading: proceed with caution. The proxy hole + globally shared idempotency namespace + static admin token can't support trading-grade permission auditing—and the brokers/data sources you need probably aren't among the 1,451 providers anyway.
Consumer products: not recommended. The zero-auth-by-default + plaintext-by-default posture is far from C-end compliance baselines. It's a self-hosted fixer-upper for people who know what they're doing, not a production-ready out-of-the-box product.

Closing

One sentence: "Credentials never enter the agent process" is the right and valuable banner; but the default security posture is "just make it run," and self-hosters must perform the coming-of-age ritual themselves.

If you adopt it, five hardening steps are non-negotiable: inject the encryption key from a vault, use a strong random ADMIN_TOKEN, issue per-caller runtime tokens, set BLOCKED_PROXIES="*", and remove port mappings so it listens only on an internal network.

The full report (architecture diagrams, source snippets, decision tree) is in my deep-research archive. Discussion welcome. Source HEAD 908351b, data as of 2026-08-29.