Project Member Access
What is Project Member Access?
The Project Members access policy restricts access to a circuit to users who are members of the project's Mutexer environment. When this policy is active, any user who attempts to access the circuit's domain is first required to authenticate with Mutexer credentials. Once authenticated, the system verifies whether the user's account is associated with the environment that owns the project. If the user is a member of the environment, the request is allowed to proceed (subject to the other security layers). If the user is not a member - for example, if the user has a Mutexer account in a different environment, or if the account has been removed from the environment - the request is denied. This policy leverages the existing user management and environment structure of the Mutexer platform (see System Overview), meaning no separate user database or credentials need to be managed for Horizon access.
When to Use
Project Member access is the most common and often the most appropriate policy for internal tools and services. It is well-suited for team dashboards and monitoring interfaces that all project members should be able to view, development and staging environments where the whole engineering team needs access, internal APIs and management interfaces that are not sensitive enough to require per-user allowlists but should not be publicly accessible, and any service where the project team is the natural audience. This policy provides an effective balance between security (users must authenticate and be verified as project members) and convenience (no per-circuit user management is required, and the access list automatically remains in sync with the project's environment membership).
How Authentication Works
When a user navigates to the domain of a circuit with the Project Members policy, the system checks whether an active, authenticated Mutexer session exists. If no session exists, the user is redirected to the Mutexer login page to enter credentials. Once authenticated, the system queries the project's environment membership to verify the user belongs to it. If verified, the request is forwarded to the backend service. If the user does not belong to the environment, the request is denied and an access denied response is returned. Every authentication and authorization attempt - whether successful, failed, or rate-limited - is recorded in the access logs with the user's email address, source IP, geolocated country, the circuit accessed, and the outcome. This provides a complete audit trail of all circuit access and any unauthorized access attempts.