Restricted User Access

What is Restricted User Access?

The Specific Users (Restricted) access policy provides the highest level of access control available in Horizon. When this policy is active, a user must not only authenticate with Mutexer credentials, but the account must also appear on the circuit's explicit user allowlist. Even users who are members of the project's environment but are not on the allowlist are denied access. This provides individual, per-person control over exactly who can reach the service behind the circuit. The allowlist is managed per-circuit, so each circuit can have a completely different set of allowed users, enabling fine-grained access control even within the same project.

When to Use

Restricted access is the appropriate choice for sensitive administrative interfaces where only specific operators or administrators should have access, vendor or contractor access scenarios where access must be granted to specific external individuals for a limited purpose, high-security services where regulatory or compliance requirements mandate that access be explicitly granted to named individuals and auditable at the per-user level, and any situation requiring defense-in-depth beyond what environment membership provides. For example, a project may have 20 team members, but only 2 senior engineers should have access to a device's firmware update interface. Restricted access enforces this without changing the project's environment membership.

Managing the Allowlist

To manage the user allowlist for a circuit, open the circuit's settings panel and navigate to the Access Policy section, then select Specific Users. The allowlist management interface provides a search field for finding users by name or email address - as text is entered, matching users from the project's environment are displayed, and selecting a user adds them to the allowlist. Added users are displayed in a list showing their full name and email address, with a remove button next to each entry. Clicking the remove button immediately revokes that user's access. Changes to the allowlist take effect immediately - there is no save or publish step. When a user is added, that user can begin accessing the circuit as soon as authentication is completed. When a user is removed, the next request from that user is denied.

Behavior

Users who are not on the allowlist receive an access denied response, even if they are authenticated and are members of the project's environment. This is the key distinction from the Project Members policy: environment membership is necessary but not sufficient. The allowlist is preserved when the access policy is temporarily switched. If a circuit is changed from Specific Users to Project Members (for example, to temporarily widen access during a team demo) and then switched back to Specific Users, the allowlist remains intact with the same users. Authentication failures and authorization denials for Restricted circuits are logged in the access logs with the user's email, source IP, country, and the outcome (failed or rate_limited), providing a full audit trail of access attempts.