Use case
An MSP's engineers support many customers, each with their own private network. An engineer may need SSH on one server at Customer A this morning and RDP on a workstation at Customer B this afternoon.
Granting VPN access per customer means managing many VPN profiles and, worse, giving each engineer standing network membership in every customer's environment — far more access than any single ticket requires, and a growing liability as the customer roster grows.
Each customer runs their own TunnelCrib Agent(s) on the Devices they want supported, scoped to their own organization. An engineer's TunnelCrib Client can belong to multiple organizations, but policies and target Devices remain organization-scoped: an engineer authorized for Customer A's database Service has no implicit access to Customer B's environment at all.
$ tunnelcrib connect customer-a/prod-web-01:ssh
$ tunnelcrib connect customer-b/workstation-12:rdpEach customer organization independently manages its own Agent-access policy: which of the MSP's Client Devices may reach which Agent, for which Service. One customer revoking access does not affect any other customer's grants.
The engineer picks a customer organization, Device, and Service inside TunnelCrib Client, and gets a local Tunnel scoped to exactly that Service — the same workflow regardless of which customer they're working with.
Each Tunnel is attributable to an engineer, a customer organization, a target Device, and a Service (see audit events).
Organization isolation means a security incident in one customer's environment does not, by itself, expose another customer's Devices or Services. See architecture for how organization boundaries are enforced at the Central Server.