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

# Access

> Which people reach which servers. One level per user or group, inherited from the gateway default, with everything outside a selection arriving as a request instead of a refusal.

**Access** governs people: users and groups from your identity provider, and the
MCP servers and skills they can reach.

It is the human half of the product. The machine half —  services your team
built, authenticating with a key — is [applications](/trustgate/access/applications),
and the two never overlap. An application that names its own end users is
outside Access entirely, because the gateway has no way to know who `user_123`
is.

## One level, inherited

Every person has an **access level**, and it is the first of these that is set:

1. Their own, on the user.
2. The most permissive level among the groups their login carries.
3. The gateway's **default access**.

| Level        | What it means                                            |
| ------------ | -------------------------------------------------------- |
| **All**      | Every resource, including ones added later.              |
| **Selected** | Only what is granted. Anything else has to be requested. |
| **None**     | Nothing: they cannot install or request.                 |

Inheritance is what keeps this manageable. Set the gateway default to what most
people should have, override on a few groups, and set almost nothing per person —
a per-user level is an exception that will outlive the reason for it, and nothing
reminds you it exists.

Levels are evaluated on every request, so a change lands immediately, including
for sessions already open.

## Grants

A grant makes one server available to the users and groups it names. It targets
either a **catalog code** — every instance of that server, including instances
added later — or one specific **instance**. Prefer the catalog code unless you
mean "this account and not the other one", because the instance-level grant
silently fails to cover the second instance somebody adds next month.

Each grant shows whether the server is actually usable: **ready** when the person
will connect their own account on first use, **configured** when a shared
credential is already in place, and **needs setup** when the server is still
waiting for an admin credential. A grant on a server that needs setup is not an
error; it just does nothing until someone finishes the registry entry.

The same grants are visible from the registry side, which is a view of this — not
a second place to set it.

## Requests instead of refusals

When someone on **Selected** wants a server outside their grants, the Portal files
a **request** rather than turning them away. This is the part worth designing
around: the default answer to "I need this tool" is a queue you control, not a
support ticket and not a shadow install.

A request carries the requester, the resource, the groups they held at the time,
their reason in their own words, and when they asked.

Approving grants the server to the **requester alone** or to **one of their
groups**. The group option is how a recurring request stops recurring — the third
time the same team asks for the same server, grant the group and the question is
answered permanently. A group the requester did not actually belong to is
refused, so an approval cannot quietly widen someone else's access.

Denied and approved requests both stay in history, with who decided and when.

## Seeing what someone else sees

Access rules are compositional — a personal level, group levels, grants from
several groups — which means reasoning about them from the rules alone gets
unreliable quickly. Rather than do that, preview the Portal as that person: it
shows their actual resources, and an admin can act on their behalf from it,
installing or requesting a server or opening a connect link for their own
account.

Use it before debating why somebody cannot see something. The preview never
reveals token material.