Concept
Two properties define how TunnelCrib grants access, and both matter independently: access is just-in-time (no standing connectivity exists between visits), and it is service-level (the unit of access is one Service on one Device, never a network).
A traditional VPN or mesh-network agent typically keeps a connection up in the background, ready to route traffic at any moment — whether or not anyone is actively using it. TunnelCrib does the opposite: there is no Tunnel until a TunnelCrib Client explicitly requests one for a specific Device and Service, and the Tunnel goes away when that session ends.
tunnelcrib-bridge process backing it exits automatically after an idle/session timeout (30 minutes by default), even if a Client forgot to close it.An Agent only ever advertises and forwards the specific Services it's configured for — a host:port pair, not a route into the rest of the Device's network. When a Tunnel is authorized, it reaches exactly that Service. It does not place the Client's machine inside the Device's subnet, and a compromised Client cannot pivot to other hosts on that network through the Tunnel.
This is the same property described throughout the site as "access the Service, not the network" — see the security architecture page for the full mechanism, and the use cases for concrete scenarios (customer support, MSP, database access, SSH, RDP).
Either property alone is a partial improvement. Service-level scoping without just-in-time connectivity would still leave a standing Tunnel that a compromised Client could reuse indefinitely. Just-in-time connectivity without service-level scoping would still expose an entire network for the duration of each session. TunnelCrib combines both: a Tunnel is created for one Service, for one session, and then it's gone.
Last reviewed 2026-09-09 against the current implementation. Corrections are welcome — support@gaur.is.