Skip to main content
A product that embeds tools for its customers has one API key and many users. If those users are to reach a ticket tracker or a repo host as themselves, someone has to keep their accounts apart — and it should not be your backend, because then your backend holds their tokens. That is what an application set to act for each end user, named by the application does. Your backend identifies the person on every call with an opaque id of yours; the gateway holds one set of upstream credentials per person and hands your product a connect link whenever someone still has to sign in.

​
The three ways an application can act

Changing this later moves where accounts live. Nothing is deleted, but what the application already connected stops being what it uses. Treat it as a migration.

​
How the middle option works

Your backend calls the MCP endpoint with the application key and the person’s id. The request runs as that person within that application: their vaulted credentials, their consent flow, their tool-list notifications. Two applications never share a user’s accounts even when they use the same ids. When a tool needs a server the person has not connected, the call fails with consent required, carrying a ready-made connect link for that person. Show it; they authorise the upstream once; the credential is vaulted under them. You can also mint the link ahead of time to offer Connect GitHub before the first call, and read each person’s connection state — connected, needs reconnect, not connected — to render it in your UI. Show a connect link only to the person it was minted for. The link carries their identity: whoever opens it links an account under that id.

​
What it is not

It is not Access. People an application names are your product’s users, not the identity provider’s, so levels, grants and approvals do not apply to them — the server set is the application’s, and who may use your product is your product’s decision. It is also not the same as attributing traffic to a person for reporting. That is end-user attribution, which records who a request was for and changes nothing about how it is authorised.