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. Name the person on each call and the gateway does it for you. Your backend sends an opaque id of its own; the gateway holds one set of upstream credentials per person, and hands your product a connect link whenever someone still has to sign in.

​
How it works

Call the MCP endpoint with the application key and the person’s id in X-NeuralTrust-End-User. Nothing is configured up front: the same key runs as the application when that header is absent and as that person when it is present, call by call. A request that names someone uses 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. The SDK also mints the link ahead of time, so you can offer Connect GitHub before the first call, and reads 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.

​
Who can name a person

The gateway does not verify the id: the application key is what it trusts. Anyone holding the key can name any id, reach the accounts that person connected through this application, or connect an account under it. Keep the key in your backend and take the id from your own authenticated session, never from client input. The id is namespaced by application, so it never reaches the person’s accounts in another application, or the ones they connected in the Employee portal. If the people are your own employees using their own clients — Claude, Cursor, a script — do not hand them an application key with their name in a header. Give them the Employee portal, where their sign-in or personal key identifies them.

​
Servers your users do not connect

Some servers hold one shared account that an administrator connected once, set on the server’s entry in the registry. Those serve every caller from that one account, so naming a person changes nothing about which credential is used — there is no link to show and nothing for your users to sign into. The same application can call both kinds in the same session.

​
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.