Skip to main content
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, 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.
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.