MCP connectors: open source is where the policy lives

Merge, which sells a connector product, defines one as "an MCP server that's either provided by the software solution or built and maintained by a 3rd-party." The definition gets the unit right. An MCP server supplies tools, and either the vendor or a third party can run it. What the sentence leaves out is who runs the call, and under which identity.

Products bend the word toward the layer they sell. Portkey's MCP Gateway describes itself as a proxy between MCP clients and servers, where one authentication, access control and logging layer applies to every call (Portkey). A managed catalog counts hosted servers as connectors. Each description is accurate about its own layer, and none of them tells a team which call may leave the building.

Keep the words apart and the rest gets easier. The server supplies the tools, the client asks for them, and the connector is the client-side entry with a name, a policy and an account. Four questions test any offering: which tools are on the list, which account a call runs as, whether a write waits for a person, and where the record of the call lives. Whether a connector is the same thing as a server is worth settling before a security review starts.

The specification is short and specific about the tool layer. "Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user's prompts." The model picks from what it can see. Clients send tools/list to discover the tools and tools/call to invoke one.

The spec also splits the security work by side. Servers MUST validate all tool inputs, implement proper access controls, rate limit tool invocations and sanitize tool outputs. Clients SHOULD prompt for user confirmation on sensitive operations, show tool inputs before calling the server, validate tool results and log tool usage for audit purposes.

That second list is a set of recommendations, and a client that skips every one of them still speaks MCP correctly. In production the difference shows on the first write: either it waits for a person or it does not. The protocol has no opinion either way.

Two sentences from Merge's explanation of the protocol mark the gap. "Authentication for MCP servers is implementation-specific, since MCP itself doesn't define a built-in authentication mechanism." And: "Tool access control is handled at the MCP server level, since MCP doesn't offer a built-in permissions system."

That gap is what a connector fills, and it is wider than the transport. The protocol standardizes how a tool is described, discovered and called. Two decisions shape what an agent does to a real system: whether a call runs, and whose authority it carries. The protocol leaves both to the server and the client. A client can hold connections to several servers at once and choose which server handles each call. That is useful, and it is one more place a call can land where nobody planned.

A connector in Kortix is a manifest entry: a slug, a display name, a provider, its actions and its policies. The manifest never holds a credential. A provider: mcp entry points at a remote server with a url and a transport (http by default), and a connector with that provider is Kortix calling someone else's MCP server.

Actions are always_run, require_approval, block, shown as Allow, Ask, Block. Approval holds the call; the agent's turn pauses and resumes. Kortix evaluates each call against four levels, and the first match wins:

1. Project-wide policies: in kortix.yaml, with fully qualified patterns such as gmail.send_email. A connector rule cannot override them.
2. The connector's own policies:, with patterns relative to it, such as send_*.
3. sensitive: true on the connector, after which every remaining action needs approval, reads included.
4. policy.default_mode: allow_all (the default) runs every remaining action, while risk runs reads and holds writes and destructive actions for approval.

The order is the design. A narrow rule at the top cannot be loosened by a broad one further down. A rule can also test the arguments of a call, so a draft can run only when its recipient is inside the company domain. Approval gates you set. Off until you set them. Read the fourth level twice, because policy.default_mode falls back to allow_all.

Identity is the other half. Every call runs as an account, and each account has an owner type. A shared account belongs to the project and reaches every agent whose grant lists the connector, triggers included. A private account belongs to one person and never runs unattended. When a call names no account, Kortix uses one only when the choice is certain, and otherwise denies the call rather than substituting someone else's identity. The credential stays on Kortix's side of the call, so the agent's sandbox never holds it.

Kortix connects 3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP. The manifest in the code panels has one connector, two rules and a grant. A get_* rule runs reads without a pause. A * rule holds everything else for approval. The agents: block is what lets release-bot reach the connector at all, because an omitted grant means none.

• An approval gate. The spec asks clients to confirm sensitive operations; a client can decline to ask. The gate is a rule on the connector, evaluated before the call leaves.
• An identity system. The server sees the credential the connector sends, not the person who typed the prompt. The platform's accounts decide who a call runs as.
• An audit log. The spec asks clients to log tool usage. Where that log lives, and who may read it, is a product decision.
• A limit on what the model may choose. The model decides which tool it wants. The policy decides whether the call runs.

Five checks work against any offering, Kortix included.

1. List the tools, and mark every one that writes. If the product cannot show the list before an agent calls a tool, the rest of the review does not matter. What an agent can see is the first question a reviewer should ask.
2. Name the account each call runs as. Ask which one a scheduled run uses, because an unattended run cannot use a private account.
3. Send one write and watch the pause. If nothing waits for a person, the gate is off, whatever the settings screen suggests.
4. Read the approval's scope. One approval should cover one exact call, with its arguments and account, and a changed argument should need a new one.
5. Find the record of a call before you need it. A team that cannot say where a call is logged cannot answer a question about it later.