One account per call, and the open source rule that picks it

Two sentences from Merge's explanation of the specification 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."

A server receives a token or a key and decides whether to accept it. It has no view of the person behind the request and no vocabulary for "Alice asked for this". Two clients presenting the same token look identical to it. The specification does put duties on both sides. Servers must validate inputs and implement access controls. Clients should confirm sensitive operations and log tool usage. Neither list names the identity a call carries, because the protocol has nowhere to put it.

That leaves the decision with whichever layer sits over the server: the client, the gateway, or the product that configured the connector. Finding that layer, and reading its rule, is the review worth doing.

A connector can hold several accounts at once: a team inbox, your own inbox, a service login. Each account carries an owner type, and the type decides who may run a call as it.

A shared account has owner_type: project. It reaches everyone in the project, and every agent whose connectors grant lists the connector, triggers included. You can narrow it to specific people, groups or agents. A person in the narrowed audience uses it only in a private session. An agent in that audience uses it in all its sessions, triggers included.

A private account has owner_type: member. Only its owner reaches it, and only in the owner's private sessions. One line then decides scheduled work: an unattended run, whether a trigger or code using a service account key (kortix_sa_…), never uses a private account.

Those two types explain most of the confusion in a team. A person who tests a connector with their own login has built something that stops working at the first scheduled job. What an agent can reach through that connector is the tool list, the grant and this account, and the account is the layer with a person's name on it.

When a call names no account, or names me or project, Kortix uses an account only when the choice is certain. Exactly one account is reachable, and the call uses it. Several are reachable and exactly one is pinned as the default, and the call uses the default.

Anything else is denied. The reason is account_required, the response lists available_accounts, and the status is 403. The docs state the condition plainly: "Several accounts are reachable, none is named, none is pinned." me limits the choice to your private accounts, and project limits it to shared accounts.

A named account that does not match is denied with connector_not_connected and the names you can use. Kortix never substitutes another account, so an ambiguous connector fails instead of running under a name nobody chose. That refusal is the property worth checking in any product that resolves identities on your behalf.

Every result carries account: { connection_id, label, owner_type }, which is how the transcript shows which identity ran the call.

Adding an MCP server from its URL starts a sign-in, and that sign-in creates the account and its audience together. Add account asks for a name and a choice of who can use it: Everyone in project creates a shared account, Only you creates a private one and is the default, and Specific people, groups, or agents creates a shared account for that audience only.

For a server with OAuth metadata, Kortix runs the standard sequence. It discovers the server's metadata (RFC 9728, RFC 8414), registers itself as a client when the server supports dynamic client registration (RFC 7591), and runs PKCE (S256) with a resource parameter (RFC 8707). With registration support, nobody creates an OAuth app.

When the server has no registration, the web app opens credential entry. It asks for the client ID and secret of an OAuth app you create with the provider, and that app needs this redirect URI registered on it: https://api.kortix.com/v1/connectors/oauth2/callback. On a self-hosted instance the URI is <KORTIX_URL>/v1/connectors/oauth2/callback, which is why the docs ask for a KORTIX_URL that never changes.

A server that answers 401 or 403 to a call opens Add account there. That path needs an auth scheme: one you pick under Auth, or one Auto-detect finds in the server's WWW-Authenticate challenge. Without one, the 401 or 403 is shown as the failure. A server that needs no sign-in, such as DeepWiki, is ready when the account exists. A provider: mcp connector is Kortix calling someone else's MCP server, so the identity belongs to Kortix's side of the call, which is a different thing from the server itself. Connector credentials are brokered server-side and never enter the machine.

An approval covers one exact request: the same connector, action, arguments and account. Change an argument and the decision starts again. After an approval, the identical call runs once when it repeats within 15 minutes, and a held call expires in 24 hours or the project's approvals.ttl.

The account is part of that scope, and that part is easy to miss. On a shared account, the same call from a second person with the same arguments falls inside the same window, because none of the four parts differs. The approval decided a request, and the request named no person. Every action is recorded. Reading, exporting and streaming the audit log depend on the plan.

Approval holds the call; the agent's turn pauses and resumes. Approval gates you set. Off until you set them, since policy.default_mode falls back to allow_all. There is also no session-wide approval. An action that must run with nobody present needs an Allow rule, since an approval needs a person to answer it.

Teams settle into one of three arrangements, and the choice turns on who the work belongs to.

1. A personal grant per person. Everyone adds an account with Only you, and each call runs as that person. Approvals bind to their account, and a scheduled run cannot use it. This fits mail, calendars and documents, where the data belongs to one person and a wrong identity is a visible mistake.
2. One shared account, narrowed to an audience. The account belongs to the project and is narrowed to a group, a set of people or a list of agents. People in the audience reach it in their own sessions, and agents in the audience reach it in every session, triggers included. This fits a support inbox or a shared drive, where the work product belongs to a team. Only a person changes the audience, and the change applies at Save.
3. A service account for unattended code. Code holding a service account key (kortix_sa_…) acts as the service account. It reaches shared accounts nobody narrowed, and never a private or narrowed account. So this arrangement only reaches an account you have deliberately left open to the project. It fits a nightly sync or a backend job, and it is the wrong tool for anything that should run as a person.

Pick the narrowest of the three that the work needs. Start with a private account for each person, move a work product to a narrowed shared account when a team owns it, and add an unnarrowed shared account for the service account only when the job cannot run with a person present.

Kortix names all of it: the account type, the audience and the agent grant are objects on the connector, and the resolution rule is documented. A reviewer can see which arrangement a connector uses before a call runs, and the same three choices answer the next server on the list.