Use case
A support engineer needs to reach one Service — a web admin panel, a database, an SSH shell — inside a customer's environment to resolve a ticket. The customer does not want to grant your team standing network access.
A VPN or private-network connection would give the engineer's laptop reachability to the customer's entire subnet: every other server, printer, and internal API on that network, not just the one Service the ticket requires.
The customer installs a TunnelCrib Agent on the Device that hosts the Service, and advertises only that Service. Your support engineer's TunnelCrib Client requests a Tunnel to that Device and Service; the Central Server checks organization boundary and Agent-access policy before allowing it. The engineer's machine never joins the customer's network — it receives one local Tunnel to one Service.
# On the customer's Device, after the Agent is registered and running:
$ tunnelcrib connect acme-support-01:web-admindevice identity verified
direct Tunnel negotiated
Service Tunnel active
localhost:49318The customer (or your own admin, if the customer delegates it) scopes which Client Devices may reach the support Agent, and for which Service, using Agent-access policy (allow/deny, per Client, per Service). Access can be revoked by removing that grant.
The engineer opens their browser to localhost:49318 exactly as if the admin panel were local. No VPN client, no route into the customer's subnet, and no other customer system is reachable from the engineer's machine.
The Tunnel request, grant/deny decision, and session lifecycle are recorded to the organization's activity log (see audit events).
Because the Agent only forwards its own advertised Service, a compromised support laptop cannot use the Tunnel to reach anything else in the customer's environment. See the threat model for what a compromised Agent host or Relay would still expose.
Comparing tools for this use case? See TunnelCrib vs. Tailscale for when a mesh VPN is a better fit than a scoped Tunnel, and vice versa.