Access Policies
What are Access Policies?
Access policies are the primary mechanism for controlling which users are allowed to reach a circuit's backend service. Every circuit in Horizon has exactly one access policy, and that policy is the first identity-level decision point in the request pipeline - it determines whether the person making a request is authorized to access the circuit at all, before any other security rules (such as IP filtering or country blocking) are evaluated. Access policies are a direct implementation of the Zero Trust principle of "verify explicitly": rather than assuming that anyone who can reach the circuit's public domain should be allowed through, Horizon requires a conscious, deliberate decision about the level of access each circuit should have. When a circuit is created, one of three policy tiers must be selected, and this selection fundamentally shapes the security posture of that circuit. A circuit with no access policy configured will not serve traffic - the platform enforces that every circuit has an explicit policy before it becomes active. This design ensures that there is no possibility of accidentally exposing a service to the internet without having made a deliberate choice about who should be able to access it.
Policy Tiers
Horizon provides three distinct access policy tiers, each representing a different level of restriction. The tiers are mutually exclusive - a circuit uses exactly one policy tier at any given time, though the tier can be changed after creation.
| Tier | Name | Authentication Required | Who Can Access | Use Case |
|---|---|---|---|---|
| 1 | Public | No | Anyone on the internet with the URL | Public dashboards, status pages, documentation sites, demo environments, or any service intentionally meant to be openly accessible. |
| 2 | Project Members | Yes (Mutexer account) | Any authenticated user who is a member of the project | Internal tools, monitoring dashboards, configuration panels, or any service that should be available to the team but not to the general public. |
| 3 | Specific Users | Yes (Mutexer account + explicit allowlist) | Only authenticated users whose email addresses appear on the circuit's allowed users list | Sensitive services, vendor access, administrative interfaces, or any service where access must be restricted to a defined set of named individuals. |
The Public tier is the most permissive policy available. When a circuit is set to Public, any HTTP request that arrives at the circuit's domain is allowed through the access policy layer without any identity verification. The user does not need to be logged in to the Mutexer platform, does not need to have a Mutexer account, and does not need to be a member of the project. This tier is appropriate for services that are intentionally public-facing - for example, a public status dashboard displaying device health metrics, a documentation site served from an edge device, or a demo environment that external stakeholders should be able to access without creating accounts. Even on a Public circuit, all other security layers remain active: IP rules and country blocks still apply, and bot detection still operates. The Public tier only removes the identity verification requirement - it does not disable any other security mechanism.
The Project Members tier requires the user to authenticate with a valid Mutexer account and verifies that the authenticated user is a member of the current project's environment. When a request arrives at a circuit with this policy, the Horizon proxy checks for a valid authentication session. If the user is not authenticated, they are redirected to the Mutexer login page. After successful authentication, the proxy verifies that the user's account is a member of the project's environment. If they are a member, the request is allowed through; if they are not, the request is denied with a 403 Forbidden response. This tier is the most common choice for internal tools and team-facing services, as it leverages existing project membership to control access without requiring maintenance of a separate allowlist.
The Specific Users tier is the most restrictive policy available. It requires the user to authenticate with a valid Mutexer account, verifies that they are a member of the project's environment, and additionally checks that their email address appears on an explicit allowlist configured on the circuit. This allowlist is managed through the circuit's settings panel, where email addresses can be added or removed at any time. When a request arrives, the proxy performs the same authentication and membership checks as the Project Members tier, and then performs an additional check against the allowlist. Only if the user's email address is on the list is the request allowed through. This tier is designed for situations where project membership alone is not sufficient - for example, when a project has many members but only a few should have access to a particular administrative interface, or when access must be granted to a specific vendor contact who has been added to the project environment for a limited engagement.
INFO
Changes to a circuit's access policy tier take effect immediately. No propagation delay or restart is required.
DANGER
Setting a circuit to Public means that anyone on the internet who discovers or is given the URL can access the backend service. While other security layers (IP rules, country blocks, bot detection) still apply, there is no identity verification. Only use the Public tier for services that are intentionally designed to be openly accessible.
How Policy Enforcement Works
When a request arrives at a circuit's public domain, the access policy is evaluated as part of the Horizon proxy's security pipeline. The exact enforcement behavior depends on the policy tier. For Public circuits, the policy check is a pass-through - no identity verification is performed, and the request proceeds to the next security layer immediately. For Project Members circuits, the proxy inspects the request for a valid Mutexer authentication session (typically a session cookie set during a previous login). If no valid session is found, the proxy returns a redirect response that sends the user's browser to the Mutexer authentication page, with a return URL parameter so the user is redirected back to the circuit after login. Once authenticated, the proxy queries the platform's membership API to verify the user belongs to the project's environment. If membership is confirmed, the request proceeds; otherwise, a 403 response is returned. For Specific Users circuits, the same authentication and membership verification occurs, followed by an additional lookup of the user's email address against the circuit's configured allowlist. A 403 response is returned if the user is authenticated and is a project member but is not on the allowlist. In all cases, the result of the policy check - whether allowed or denied, and the identity of the user if authenticated - is recorded in the circuit's access logs, which are visible in the monitoring dashboard.
Changing Policies
A circuit's access policy can be changed at any time through the circuit's settings panel in the Horizon management interface. Policy changes take effect immediately - there is no propagation delay. When changing from a more restrictive tier to a less restrictive tier (for example, from Specific Users to Project Members, or from Project Members to Public), access is immediately broadened to include the new tier's scope. When changing from a less restrictive tier to a more restrictive tier, access is immediately narrowed, and users who were previously allowed may be blocked on their next request. When switching to the Specific Users tier, at least one email address must be added to the allowlist for anyone to be able to access the circuit through the identity policy. Changing the access policy does not affect any other security configuration on the circuit - IP rules, country blocks, and the enabled/disabled state all remain unchanged.
TIP
When granting temporary access to a vendor or external collaborator, consider using the Specific Users policy tier in combination with a circuit expiration date. This way, the vendor's access is both identity-restricted and time-limited, following the Zero Trust principle of least privilege.