> ## Documentation Index > Fetch the complete documentation index at: https://docs.corepillar.ai/llms.txt > Use this file to discover all available pages before exploring further. # Access control > How ModelHub stays chat-only: the deployment variant and server-side redirects, the hub role hierarchy, the AgentHub gate for Users, the shared-membership caveat, and how to remove someone. ModelHub and AgentHub are two deployments of the same application, reading the same database. What makes ModelHub a chat-only product is the **deployment**, enforced on the server. What decides whether someone can also use AgentHub is their **role**. ## Chat-only is enforced by the deployment ModelHub is built as the employee variant of the platform. On that build: * The sidebar carries exactly two pages, **Chat** and **AI Usage**, plus **New chat**, conversation history and (for admins) **Settings**. * The logo links to the chat. * Every other project page is **redirected to the chat by middleware before the page renders**. That includes Overview, Model Manager, Cost Calculator, Evaluation, Simulations, Traces and Reports. Typing the URL does not work; you get the chat of the same organization and project instead. This is server-side enforcement, not a hidden menu item. A redirect happens before anything renders, so there is no blank page or partial content. | Path on ModelHub | Result | | - | - | | `/org/project/playground` | The chat | | `/org/project/usage` | AI Usage | | `/org/project/anything-else` | Redirected to `/org/project/playground` | | `/org/settings/...` | Allowed by the deployment, then gated by role (see below) | | `/login`, `/signup`, `/auth/...`, `/invite/...` | Public | | Anything else while signed out | Redirected to `/login`, remembering the destination | On the AgentHub build, the same slot that is the chat on ModelHub is the organization-wide **AI Usage** dashboard, and the chat is not offered. ## Hub roles Each person has a hub role derived from their organization role: | Hub role | Comes from | ModelHub | AgentHub | Settings tabs | | - | - | - | - | - | | **Super Admin** | A per-domain list in the platform configuration, never stored in the database | Yes | Yes | General, User Management, SSO, Tracing keys, Platform access | | **Admin** | Organization role **Owner** or **Admin** | Yes | Yes | General, User Management | | **AI Builder** | Organization role **Editor** | Yes | Yes | None | | **User** | Organization role **Viewer** | Yes | No | None | * The hub role is shown as a badge under each person's name in the sidebar. * Super admins act with the full Owner permission set in every organization they can reach, whatever their database role there. * The super admin list is deliberately kept outside the database. It is the root of the access system: if it lived in the tables it governs, a bad write or an unreachable database could lock every administrator out. * People without settings tabs have no **Settings** link, and opening a settings URL directly sends them back to the organization's first project (the chat, on ModelHub). * In **User Management**, admins can assign Editor and Viewer; only super admins can add, change or remove Admins. Full permission lists per role are in [Roles and permissions](/agenthub/settings/roles-and-permissions). ## The AgentHub gate for Users When a User (Viewer) signs in to AgentHub and opens any project page, they see a full-screen notice instead: > **Your account has ModelHub access only** > AgentHub is available to admins and AI Builders. You can keep using ModelHub to chat with models. Ask an admin if you need AgentHub access. with a **Go to ModelHub** button and a **Sign out** link. Organization-wide usage is gated separately: on both hubs, the organization view of AI Usage (cost per person, the log of removed personal data with its values) loads only for Owners, Admins and super admins. The check runs before the query, so the data is never fetched for anyone else. ## The per-organization caveat **Membership is per organization, not per deployment.** Both hubs read the same database, so a person you add to an organization is a member on both. The URL you hand out decides where they usually go; the role decides what they can do if they reach the other hub. In practice: * A **User** who opens AgentHub sees the gate above. * An **AI Builder** or **Admin** has the full platform on AgentHub. Do not use those roles for people who should only chat. * Anyone who can reach an organization's settings or usage can do so from either hub. If you need a harder boundary, put chat-only staff in a **separate organization**. They are then not members of the organization whose data AgentHub reports on, and there is nothing for them to see there whatever their role. The cost is a second set of model configurations and keys. ## Removing someone Do both of these when someone leaves: 1. **Remove the membership.** In **Settings** → **User Management**, delete their email from every box and click **Save changes**. A dialog titled **Remove this person?** lists who will lose access ("Saving will remove their access to this organization (or revoke their pending invite).") Click **Remove and save**. The save summary shows "Removed from the organization." or "Pending invite revoked." 2. **Block sign-in.** In **Settings** → **Platform access** (super admins), **Remove** their address from the **Allowlist** if it is listed there. Removing the membership alone still lets them sign in with an email code. If they sign in with Okta, also unassign them from the CorePillar app in Okta. The current Platform access screen only offers **Deny** on **Pending requests**. There is no button to revoke an address that was approved from a request, or to deny one person whose whole `@domain` is on the allowlist. An explicit denial would beat the domain rule, but it cannot be set for an already-approved address from the UI today. For those people, removing the membership is the effective control: they can still sign in, but they belong to no organization of yours. Removing the domain entry blocks everyone on that domain who was not approved individually. Limits on removal: | Message | Meaning | | - | - | | You can't remove yourself. | Ask another admin. | | Only a super admin can remove admins. | Admins can only be removed by a super admin. | | This is the org's last Owner — can't be removed. | Assign another Owner first. | Their past chat turns stay in the organization's usage records, masked, so spend and privacy history remain accurate. ## Checking a deployment If anyone on ModelHub ever sees platform pages such as Traces or Model Manager, the deployment was built with the wrong variant. ModelHub must be built with `NEXT_PUBLIC_APP_VARIANT=user`. The value is fixed at build time, so one deployment cannot serve two different products. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.