Concept

Just-in-time, service-level remote access

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).

Just-in-time: no standing Tunnel

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.

A direct (P2P) Tunnel exists only while the Client's local forwarder process is running.
A Relay-backed Tunnel additionally expires on its own: the tunnelcrib-bridge process backing it exits automatically after an idle/session timeout (30 minutes by default), even if a Client forgot to close it.
There is no persistent "always-on" agent-to-agent link comparable to a mesh VPN's background connection.

What this does not mean: the underlying authorization (which Client may reach which Agent/Service) is a standing Agent-access policy grant, not a per-session approval workflow. TunnelCrib does not currently include a formal time-boxed elevation/approval feature (of the kind sometimes called PIM/JIT access management) where an admin approves each session for a limited window. What's ephemeral today is the network path, not the entitlement decision. If you need per-session approval workflows, treat that as a roadmap question, not a shipped feature.

Service-level: not network-level

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).

Why both properties together

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 — [email protected].