Skip to main content
Platform access decides who may sign in to CorePillar at all, on both ModelHub and AgentHub. It sits in front of organization membership: someone has to be approved here before they can sign in, and before anyone can invite them to an organization. “Decide who can sign in to CorePillar at all. Restricted to super admins — org owners and admins cannot see or change this.”

​
Who sees this tab

Only super admins. The tab does not exist for anyone else: org Owners and Admins don’t see it, and opening its URL returns a not-found page. Every action behind it re-checks that you are a super admin and otherwise returns “Not authorized.” The platform access list is shared by every organization on the site. An approval is not tied to one organization.

​
How sign-in is decided

When someone requests a sign-in code or signs up, AgentHub checks their email in this order:
  1. Super admins can always sign in.
  2. An explicit decision on the address wins in both directions. Approving one address lets it in with no domain entry. Denying one keeps it out even when its whole domain is allowlisted.
  3. The allowlist is checked next: either the full email (priya@acme.com) or its domain (@acme.com).
  4. Anything else is blocked.
Emails are compared in lowercase with surrounding spaces removed.

​
Fails closed

The access tables are the only source of truth. If AgentHub cannot read them, because the database is unreachable or the service is misconfigured, sign-in is denied, not waved through. The super admin list lives outside the database so that super admins can always get back in. When the server cannot read or write access records at all, the tab shows a warning: “A service-role key is not configured, so access records can’t be read or written. Until it is set, nobody but the super admins listed below can sign in.”

​
What a blocked person sees

Both record a pending request for the address, once. A later attempt from the same address does not create a second request, and does not reset an earlier decision.
The sign-up message mentions an email, but AgentHub does not send one when you approve someone. Tell them yourself.

​
The tab, section by section

​
Pending requests

“Sign-up and login attempts from addresses that are not approved yet.” Empty state: “No pending requests”.

​
Allowlist

“Approve a full email (a@b.com) or a whole domain (@b.com) ahead of any request.” Type into the field (placeholder you@company.com or @company.com) and select Add. The entry must contain @; otherwise you get “Enter a full email or an @domain entry.” Adding an entry that already exists has no effect. Empty state: “No allowlist entries”.

​
Super admins

The read-only list of addresses that can always sign in and are the only ones who can open this tab. It is configured by CorePillar per site and cannot be changed here.

​
Recent decisions

“Every approval and denial, and who made it.” Shown once there is at least one decision.
There is no button to reverse a decision from this tab. Once an address is denied, adding it or its domain to the allowlist does not let it in, because the denial takes precedence.
All times on this tab are shown in UTC.

​
Common tasks

Add @company.com to the allowlist. Anyone with an address at that domain can sign in. Then invite the people who need an organization role from User Management.
Approve their pending request, or add their full email to the allowlist before they try.
Their address needs a denied decision. If they have a pending request, select Deny. A denial outranks the domain entry.
Remove them from the organization in User Management, and deny their email here. Removing the membership alone still lets them sign in; denying the email alone leaves a membership behind.

​
Scope of the check

Platform access is checked when someone asks for an email sign-in code, signs up with a password, or is invited to an organization. Okta SSO sign-ins are not checked against it: who can sign in through SSO is controlled by assignment to your Okta application. See SSO with Okta. For the employee rollout view of the same controls, see ModelHub access control.