TrustGateUser. It is the other side of TrustGate, which runs as an
application: no application is involved, and every call is the person’s, in
the audit trail and upstream.
With a personal key
The simplest way in is the person’s personal key, from the portal’s Personal key button. It needs no browser and reaches both their tools and their models.TrustGate(api_key=...) refuses a personal key and says to use TrustGateUser,
and TrustGateUser refuses an application’s key.
Signing in through the browser
Without a key, sign in the way an MCP client does. This reaches the person’s tools only: models take the personal key.url is the Employee portal’s MCP URL, from the gateway’s settings
(TRUSTGATE_STORE_URL when unset); its host alone works too.
The first run opens the browser. The session is kept in
~/.trustgate/sessions.json, readable only by you (TRUSTGATE_HOME moves it),
and renewed on its own until the sign-in ends — a day on NeuralTrust’s cloud, so
that what an admin changes in Access reaches you by then. Past that, the next
call raises LoginRequiredError, and login() signs in
again. logout() forgets the session.
The browser comes back to a port on your machine, so this is for your own
computer. A service acting for many people is an application with an API key,
naming its users — see Acting for end users.
A backend that already ran the OAuth flow for its user passes the token instead:
TrustGateUser(url=..., access_token=...) (TRUSTGATE_ACCESS_TOKEN).
Servers waiting for an account
A server whose account the person has not connected yet is not on their tool set.connect() does not refuse: the person is there to connect it. It names
those servers, and hands over the page to connect each one.
Using the tools
The handle is the same as an application’s: handmcp (the URL and its
headers) to a framework that brings its own MCP client, or translate the tools
with toolkit() for a model call — see Tools. The
person’s models work as an application’s do — see Models.