Access

Access governs people: users and groups from your identity provider, the MCP servers and skills they can reach, and the models they can call. It is the human half of the product. The machine half — services your team built, authenticating with a key — is applications, and the two never overlap. When an application names one of its own end users on a call, that call is outside Access too: the gateway has no way to know who user_123 is, so what it may reach is the application’s set, not a level.

​

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.

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, including for sessions already open. On the data plane a change applies after the next config snapshot, usually within seconds, at most about 5 minutes. The organization owner is the exception: their level is All, for MCP and for models, on every gateway, and the panel states it instead of offering the switch. It moves with ownership.

​

Grants

A grant makes one server available to the users and groups it names, unless the person’s level is None. 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.

​

Models

On a SaaS gateway, the same panels carry a Models block above the MCP one, with the same three levels, set on users, groups and the gateway default, applied to LLM providers: Models add up rather than taking the first level set. A person reaches what their own level, their groups and the default give, together, with three exceptions:

• Their own None means no models at all.
• Without a level of their own, a group at None wins over their other groups and the default.
• A provider on their own level replaces that provider from their groups and the default, so their own selection of it is the one that counts.

A level gives a person nothing to configure: their personal key reaches what it grants, and the Employee portal shows it to them. It is enforced by the gateway on every call: a model the person’s level does not reach is refused before any provider is called, whoever else uses that provider. A change applies to the person’s key within seconds.

​

Requests instead of refusals

When someone on Selected wants a server outside their grants, or a model provider they do not have, the Employee portal files a request rather than turning them away — from the portal itself, or from their agent through the portal’s tools. 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 a server grants it to the requester alone or to one of their groups. Approving a model provider gives the requester its models. 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 Employee 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.