> ## Documentation Index
> Fetch the complete documentation index at: https://neuraltrust-92b43583-develop.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> These docs cover three products: TrustGate (AI agent gateway), TrustGuard (runtime security), and TrustTest (AI red teaming). Start from each product overview for the definition and How it works. Prefer the .md URL next to a page in /llms.txt when you need the full article. Use /llms-full.txt for a single-file dump of the site.

# Acting for end users

> An application whose own users connect their own upstream accounts, without your backend ever seeing their tokens. The application names the person; the gateway keeps their accounts apart.

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

| Acts as                                           | Who signs in upstream                                                           | Fits                                                                        |
| ------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **The application's own**                         | One set of accounts, connected once by an admin.                                | A batch job, a service with no human behind any given call.                 |
| **Each end user, named by the application**       | Each of your users, once, through a link your product shows them.               | A product whose users bring their own accounts.                             |
| **Each end user, signed in through the platform** | Each person, with the NeuralTrust login. An API key cannot act for one of them. | Anything where the person is present and should authenticate as themselves. |

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](/trustgate/access/overview). 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](/trustgate/observability/end-user-attribution), which
records who a request was for and changes nothing about how it is authorised.