Make local AI reachable for staff and sites securely? WZ-IT connects the AI Cube through an existing VPN, NetBird, or a controlled gateway without exposing model servers and administration directly. Assess the AI Cube and connectivity
Local AI should compute within the organisation's environment without being restricted to the desk next to the device. Remote staff, other sites, and administrators need controlled access. This does not require putting the model server on the public internet.
Separate services consistently
A local AI platform has several endpoints: a user interface such as Open WebUI, model API, database and knowledge store, administration, monitoring, backup, and update paths. Only the interface or a deliberately released API belongs in the user path. Model, database, and administration stay in separate networks or policy groups.
Which access path fits?
| Requirement | Appropriate starting point |
|---|---|
| managed devices need several internal services | an existing corporate VPN with constrained network rules |
| users, devices, and sites need identity-based separation down to service and port | NetBird with groups, resources, and policies |
| one web service must be reachable without a VPN client | a hardened reverse proxy with SSO or MFA |
| an application needs automated model access | a defined API gateway path rather than direct model exposure |
These paths can be combined. User access, administration, and integrations should still receive separate rules and endpoints.
Option 1: existing corporate VPN
An existing VPN can connect the platform to the internal network. This fits when identity, device management, MFA, and network policy already operate reliably. Check whether the VPN provides only network reachability or application-level rules. Broad access to an entire subnet is rarely required for one AI service.
Option 2: NetBird identity and policies
NetBird creates a WireGuard-based overlay between approved peers. Networks and resources can make an internal service reachable through routing peers without installing a client on every target. Rules use groups, sources, and destinations.
An AI Cube policy can grant an “AI users” group access only to the web interface while “AI administrators” receive a separate management path. Staff can reach the service from remote offices or home without opening the whole site network.
Option 3: controlled reverse proxy
Where access without a VPN client is required, a reverse proxy can provide TLS, hostname, authentication, limits, and logging. It is the only public component and forwards only to the intended service. Database, model port, and SSH remain closed.
Public access also needs MFA or SSO, rate limiting, session policy, patching, monitoring, and an incident path. It is not only a convenience setting.
Treat hybrid model selection deliberately
Open WebUI can connect external providers alongside local models. This may be useful for approved tasks but changes the data path. Model access should be limited by group and clearly named in the interface. Sensitive knowledge must not be sent to an external endpoint unintentionally.
Integrating the AI Cube
The AI Cube is installed in the customer network with local interface and model. Remote access is not a blanket open port. WZ-IT assesses users, devices, sites, identity, and existing networks and then implements VPN, NetBird, or a gateway as a separate integration scope.
Update and support access are also planned separately for ongoing operation. Temporary approval, named administrators, and traceable logs are preferable to a permanent shared maintenance account.
Checklist
- release only the interface or defined API;
- do not expose model server, database, or SSH publicly;
- use SSO and MFA for external users;
- separate user and administrative paths;
- define device or peer trust;
- limit policy to service and port;
- clearly label external models and approve them by group;
- document access, update, and incident processes.
