Connectors

Every tool your company runs on. None of the keys.

Connect a tool once, for the whole company. Agents reach it through one scoped token that Kortix brokers server-side — so the raw credential never lands in the machine the model is driving.

Get started Talk to sales

3,000+ apps · MCP · OpenAPI · GraphQL · raw HTTP

+ 3,000 more

Policy

Decide what runs, what asks, and what never happens.

Every action a connector exposes gets one of three answers, and you set them. One tool at a time, or one pattern that covers a hundred — a glob by default, or a regular expression when you wrap it in slashes.

Allow

Runs on its own

The call goes straight through. For reads and for the routine writes you have already decided you trust.

gmail.list_messages

Ask

Pauses for a human

The run stops at the call and waits. A person approves it once, approves it for the rest of the session, or denies it.

gmail.send_email

Block

Never runs

The action is not available, and no approval can lift it in the moment. Deleting a customer stays off the table.

stripe.delete_customer

A tool left on Default has no rule of its own and falls through to the project default. Until you set that default to risk — reads run, writes and destructive actions ask — an untouched project runs everything.

The Permissions tab of the Google Drive connector in Kortix: a default rule, then every Drive tool set to Allow, Ask, Block or Default. — Permissions on a real Google Drive connector — 51 tools, one answer each.

The pause is real

An approval stops the run. It does not fail it.

A gate that errors out teaches an agent to retry around it. A Kortix gate holds the call open, so the agent is still mid-task when you answer — and picks up exactly where it stopped.

running
The agent drafts the reply and reaches send_email.
waiting
The call is held. You see the action and its arguments.
approved
You approve. The same call completes and the run continues.

Rules that read the arguments, not just the tool name

A tool-name rule can only ask “may the agent send email?” — which is rarely the question. A condition points at a value inside the call and matches it with a glob or a regular expression, so a rule can allow sending to your own domain and stop at everything else. A list argument passes only when every entry passes, so one off-list recipient is enough to hold the call. Anything the rule cannot decide resolves toward less access, never more.

Project-wide rules are evaluated first and cannot be overridden by whoever adds a connector later.

ActionWhenThen

send_emailto ends with @acme.comAllow

send_emailanything elseAsk

/^(share|publish)_/alwaysAsk

delete_*alwaysBlock

Connect once

One connection. Every agent, every session, every person.

A connector belongs to the project, not to a laptop or a login. Add it once and every session that project starts can reach it — with no second setup and no key passed around in a DM.

Easy connect

3,000+ apps, OAuth handled

Pick the app, click through its OAuth screen, done. Kortix stores the connection, not your password — Gmail, Notion, Linear, Salesforce, HubSpot, Zendesk, Google Drive and thousands more.

Custom

Your own APIs, in the same shape

Point Kortix at an OpenAPI or Postman spec, a GraphQL endpoint, a remote MCP server, or a bare HTTP base URL. It reads the source, works out the authentication, and turns every operation into a tool.

Channels

The places people already talk

Slack and email connect the same way, so an agent can be reached and can reply where the work already happens.

The Kortix connector catalogue, showing Notion, Google Sheets, Linear, Google Drive, Salesforce, HubSpot, GitHub, Gmail and more, each one click from connected. — Connectors → Add app → Easy connect. Real screen, real project.

The credential never travels

The agent gets a token. It never gets the key.

A sandbox is a real Linux machine the model can run anything on. So we do not put your credentials in it. The sandbox carries exactly one Kortix token, scoped to the project, and every outbound call is assembled on our side of the wall.

The usual way

A drawer of keys in the agent’s environment

STRIPE_API_KEY=sk_live_…
NOTION_TOKEN=secret_…
SLACK_BOT_TOKEN=xoxb-…
GITHUB_PAT=ghp_…

Every key sits in the environment the model reads from. Revoking one means rotating it everywhere it was copied, and any of them can end up in a log line.

How Kortix does it

One scoped token, and nothing else

KORTIX_EXECUTOR_TOKEN=kortix_pat_…

Scoped to one project and narrowed again by what that agent is allowed to touch. Turning a connector off takes effect on the next call. Nothing in the sandbox needs rotating, because nothing in the sandbox was ever a secret of yours.

Inside the sandbox

Server-side · Kortix

The agent asks

executor.call("gmail", "send_email", {…})

The agent calls a tool. It names the connector and the action — it has no URL, no host, no key.

Kortix brokers

POST /v1/executor/call

The gateway checks this agent may use this connector, resolves the policy, decrypts the credential server-side, and attaches it to the outbound request.

The API answers

Authorization: Bearer ••••••••

The third-party API sees a normal authenticated request. The response comes back to the agent. The credential stays behind.

Never crosses into the sandboxAPI keysOAuth access tokensRefresh tokensClient secrets

Encrypted at rest

Connector credentials are encrypted with a per-project key and stored apart from the values a sandbox is allowed to read.

Injected at call time

The secret is attached to one outbound request and thrown away. It is never written into the sandbox environment.

Connector keys stay server-side

The model is never shown a credential, and the ledger stores a hash of the inputs rather than the inputs themselves.

Scope

The same connector, readable by one agent and invisible to another.

Reach is granted, not inherited. An agent gets the connectors you list for it and nothing else, and effective access is always the intersection of what the person can do and what the agent was granted.

Per project

A connector lives in one project. Another project cannot see it, call it, or read its credential — a project is its own blast radius.

Per agent

Each agent lists the connectors it may use. The support agent reaches Zendesk and Gmail; the reporting agent reaches neither, and cannot discover that they exist.

Per person

Choose who the connection belongs to: one project-managed account everyone shares, or a personal authorization where each member acts as themselves and an automated principal cannot act at all.

kortix.yaml

[[agents]]
name = "support"
connectors = ["zendesk", "gmail"]

[[agents]]
name = "recruiting"
connectors = ["greenhouse", "gmail"]

[[agents]]
name = "reporting"
connectors = ["warehouse"]

Grants are text in the repo, so a change to who can reach what is a diff someone reviews — not a setting that quietly moved.

Audit

Every call it made, and who let it.

The gateway that resolves the credential is also the thing that writes the record. There is no path to a connected tool that skips it.

Action

The connector and the exact action called.

Acted by

The agent and the person or trigger behind the session.

Outcome

Ran, denied, waiting on approval, or errored.

Risk

Whether the action reads, writes, or destroys.

Approved by

Who released a held call, and when.

Inputs

A hash of the arguments, and a redacted result — never a raw secret.

Read the trail for any session inside the app. Audit access is part of Enterprise.

Connect the first one in a minute.

Start free, connect a tool, and watch the first approval gate stop an agent mid-run. Self-host it if you would rather the whole thing lived in your own environment.

Open source and self-hostable — Kortix Cloud, your VPC, or on-prem.
Credentials encrypted, brokered server-side, never handed to the model.
Allow, Ask, or Block on every action, with a human in the loop where it matters.

Get started Read the docs

kortix

Kortix connectors | Kortix