Post cover image

August 26, 2026

Forget Pipedream & Composio: OpenConnector Gives AI Agents 10,000+ Actions Across 1,000+ Apps

AI agents are getting surprisingly good at doing things for us. They can read emails, update Notion pages, create invoices, send Slack…

By CodeBun

5 min read

AI agents are getting surprisingly good at doing things for us. They can read emails, update Notion pages, create invoices, send Slack messages, manage GitHub issues, and connect dozens of different services.

But there's an uncomfortable question hiding underneath all of this:

How does the agent log in?

If your answer is "I give the agent my API key," we have a problem.

Giving an AI agent raw passwords, OAuth tokens, or API keys means putting some of your most sensitive credentials directly into a system that was never designed to hold them.

That's where OpenConnector gets interesting.

It takes a different approach:

Let the AI agent ask for an action, but never give the agent the actual credentials required to perform it.

Instead, OpenConnector sits between the agent and your external services.

Think of it as a security gateway for AI agents.

None

The Problem With Giving Agents Direct Access

Imagine you build an agent that needs to do this:

  1. Read your Gmail.
  2. Find an invoice.
  3. Extract the amount.
  4. Add the invoice to Airtable.
  5. Send a notification to Slack.

Without some kind of credential layer, you might end up giving the agent access to all three services.

Something like:

AI Agent
   |
   +--> Gmail API key
   |
   +--> Airtable API key
   |
   +--> Slack token

Now your agent has access to your credentials.

That's not ideal.

The problem isn't necessarily that the agent is malicious.

The problem is that AI agents operate on instructions and context.

A prompt injection, a buggy tool call, or a badly designed workflow could potentially cause an agent to use credentials in ways you didn't intend.

And once a secret enters the model's context, you have another problem:

How do you guarantee it never leaks?

OpenConnector changes the architecture.

Instead of:

Agent ---> Credentials ---> Service

you get:

+------------------+
                 |  OpenConnector   |
                 |                  |
Agent ---------->|  Actions         |----> Gmail
                 |  Credentials     |----> Slack
                 |  Policies        |----> Notion
                 |  Logs            |----> Airtable
                 +------------------+

The agent doesn't need to know the password.

It only needs to know what action it wants to perform.

The Agent Asks for an Action

This is probably the simplest way to understand OpenConnector.

Suppose the agent wants to find the current GitHub user.

It can call an action like:

curl -s -X POST \
  http://localhost:3000/v1/actions/github.get_current_user \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Notice something important.

There is no GitHub token in that request.

The agent simply says:

Run github.get_current_user.

OpenConnector handles the authentication behind the scenes.

The architecture becomes:

AI Agent
   |
   | "Run github.get_current_user"
   v
OpenConnector
   |
   | Uses stored credential
   v
GitHub

The credential stays inside the runtime.

That separation is the whole idea.

It's Basically a Tool Firewall

I think the easiest mental model for OpenConnector is a firewall for agent actions.

A traditional firewall decides things like:

Can this machine connect to that server?

An agent gateway can decide:

Can this agent call that action?

For example, maybe your agent can:

ALLOW
✓ gmail.search
✓ gmail.read_message
✓ slack.send_message

But you don't want it doing:

BLOCK
✗ gmail.delete_message
✗ slack.delete_channel
✗ github.delete_repository

This distinction becomes increasingly important as agents become more autonomous.

An agent that can read your email is one thing.

An agent that can read, send, delete, modify, purchase, deploy, and cancel things is something else entirely.

The more capable the agent becomes, the more important the permission layer becomes.

Credentials Stay Behind the Gateway

OpenConnector supports different types of authentication, including API keys and OAuth-based connections.

For example, you can configure a GitHub connection with an API key:

curl -s -X PUT \
  http://localhost:3000/api/connections/github \
  -H 'content-type: application/json' \
  -d '{
    "authType": "api_key",
    "values": {
      "apiKey": "github_pat_..."
    }
  }'

The important part is where this happens.

The credential is registered with the runtime.

The agent doesn't need to receive it every time it wants to use GitHub.

Then the agent can simply call:

curl -s -X POST \
  http://localhost:3000/v1/actions/github.get_current_user \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

That's a much cleaner separation.

Your application logic can deal with:

"Do this action"

instead of:

"Here's the secret you need to do this action."

800+ Services Changes the Equation

Another interesting part is the provider catalog.

OpenConnector is designed around ready-made actions for hundreds of services.

That includes things like:

  • Gmail
  • Slack
  • Notion
  • Airtable
  • GitHub
  • and hundreds of other providers

Instead of writing custom authentication and API wrappers for every service, an agent can work with a standardized action layer.

For an AI application, that's useful.

You can think of the system like this:

OpenConnector
                         |
        +----------------+----------------+
        |                |                |
      Gmail            GitHub           Slack
        |                |                |
     Actions           Actions          Actions

The agent doesn't need to understand every provider's authentication system.

It just needs to understand the available actions.

MCP Makes This Even More Interesting

OpenConnector also speaks MCP out of the box.

That's important because MCP has become a common way for AI applications to discover and use tools.

Instead of creating a completely custom integration between every agent and every service, you can have:

AI Agent
   |
   | MCP
   v
OpenConnector
   |
   +---- Gmail
   +---- Slack
   +---- GitHub
   +---- Notion
   +---- Airtable

The gateway becomes the common interface.

This is especially useful when you're building agent systems where tools may change frequently.

You don't necessarily want your agent to know the details of every API.

You want it to know:

Available tool:
github.get_current_user
Available tool:
gmail.search_messages
Available tool:
notion.create_page

The gateway takes care of the messy part.

Runtime Tokens Are Better Than Real Keys

One of the more interesting security ideas here is the use of runtime tokens.

Imagine your agent needs access to OpenConnector.

You don't necessarily want to give that agent your actual GitHub token.

Instead:

GitHub Token
     |
     v
OpenConnector
     |
     v
Runtime Token
     |
     v
AI Agent

The agent receives a token that represents its access to the runtime.

The real provider credential stays protected behind the gateway.

This creates another useful boundary.

If the agent token gets exposed, you can revoke or restrict that runtime access without having to distribute the underlying provider credentials.

Policies Are Where This Gets Powerful

Credentials are only half of the problem.

The other half is authorization.

Just because an agent can technically access an API doesn't mean it should be allowed to perform every action.

OpenConnector provides allow/block policies so you can control what the agent is permitted to do.

For example:

Agent: Invoice Assistant
ALLOW:
  gmail.search
  gmail.get_message
  airtable.create_record
BLOCK:
  gmail.delete_message
  airtable.delete_record
  github.create_repository

Now your agent has useful capabilities without having unrestricted access to everything.

That's a much better model for production agents.

How It Works

flowchart LR
  Agent["AI Agent / App"] -->|"SDK / CLI / MCP / HTTP"| Gateway["OpenConnector Gateway"]
  Gateway --> Auth["Credential & OAuth Boundary"]
  Gateway --> Catalog["Provider Catalog"]
  Gateway --> Actions["Open-source Action Executors"]
  Gateway --> Policy["Tokens, Scopes, Allow/Block Policy"]
  Gateway --> Logs["Run Logs"]
  Actions --> Providers["1,000+ Providers"]
  Console["Web Console"] --> Gateway
  Cloudflare["Cloudflare Workers, D1, R2"] -. deploy .-> Gateway

Getting Started

The quickest way to run OpenConnector is through Docker Compose.

docker compose up

This pulls the published runtime image:

ghcr.io/oomol-lab/open-connector:latest

If you want to build it yourself instead:

docker compose \
  -f docker-compose.yml \
  -f docker-compose.build.yml \
  up --build

Once it's running, open:

http://localhost:3000

The generated API documentation is available at:

http://localhost:3000/docs

You can also test the runtime without configuring authentication first.

For example, Hacker News provides a simple no-auth action:

curl -s -X POST \
  http://localhost:3000/v1/actions/hackernews.get_top_stories \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

If that works, you've got the runtime running.

There's a Web Console Too

If you prefer a UI over curl commands, OpenConnector includes a web console.

During npm-based development, you can run it on:

http://localhost:5173

The Docker/built runtime serves the console from:

http://localhost:3000

The console lets you work with things like:

Provider browsing
      ↓
Credentials
      ↓
OAuth configuration
      ↓
Runtime tokens
      ↓
Action schemas
      ↓
Action debugging
      ↓
Run history

It also exposes the generated OpenAPI and MCP metadata.

So you don't have to build an entire administration panel just to inspect what your agent is doing.