An engineer needs to read a row from a production database. They open their terminal and type:
psql -h pg-prod.hoop
That's it. No VPN toggle. No jump host. No credential to paste. The connection opens. The query runs. Hoop sat in the middle the entire time, checked who they were, confirmed what they were allowed to touch, and logged every command that crossed the wire. The engineer never noticed.
That is the whole idea behind Hoop Tunnel. And it is harder to build than it sounds.
Why does the secure path keep failing?
The standard secure path to a production database in a regulated environment has five steps. Open the VPN. SSH into the jump host. Find the shared credential in the vault. Paste it. Connect.
Engineers skip it. Not because they are careless. Because five steps is too many when you need to check one row and get back to work. So the credential ends up in an environment variable, the VPN stays off, and the audit log shows a shared service account instead of a person.
A staff security engineer at a personal-finance fintech said it plainly on a call this month: "Make the security controls good but easy, or the business is not going to use them."
The control that is hard to use is the control that gets routed around. Every time.
What does Hoop Tunnel actually do?
Hoop Tunnel is a small background program that runs on the developer's laptop. It wires up DNS so that any *.hoop hostname resolves as a local address. The engineer points psql, their database GUI, or any script they already wrote at pg-prod.hoop and it connects.
Hoop sits in the middle. Identity is resolved from the company IdP -- the same Okta or SSO behind every other internal tool. The raw credential never lands in the engineer's shell, never sits in an environment variable, never gets copied anywhere. The connection is bound to the person who opened it.
The engineer keeps their tools. The security team keeps the audit trail. Nobody changes how they work.
Where did the credential go?
Nowhere the engineer can see. That is the point.
The background service holds the authenticated session. The raw database password never leaves the gateway. When the engineer connects, the gateway issues a short-lived credential scoped to that session, hands it to the connection, and the credential expires when the session closes.
When someone leaves the company, there is no shared password to rotate. Their identity gets revoked once. Every connection they had stops working immediately.
|
The old secure path |
Hoop Tunnel |
| How you connect |
VPN, jump host, paste a credential |
psql -h pg-prod.hoop, native client |
| Where the credential lives |
On a laptop, in an env var |
Nowhere the engineer can reach |
| What the audit log shows |
A shared service account |
The person, the connection, the query |
| When someone leaves |
Rotate a shared password |
Revoke their identity once |
| Developer experience |
Five steps, every time |
The command they already type |
Does invisible mean uncontrolled?
No. Out of the way for the engineer is not out of the loop for security.
Every connection still runs through the gateway. Ports are enforced at connection time, so a session reaches only what it is allowed to reach. In-session controls still apply on the wire: a sensitive column gets masked before the result leaves the database, a destructive command gets stopped before it runs, a mutating action waits for a human approval that lands in the same audit trail.
The engineer sees a normal database connection. The security team sees who connected, to what, and every command that crossed the line.
What else shipped this week
Hoop Tunnel going on by default was one of three experimental features that graduated this week.
Async SSH fixes a parallelism problem inside the agent. Before, one slow SSH session would stall every other session behind it -- one engineer debugging a hung process could block three others from connecting. Each session now gets its own lane. One slow connection no longer freezes the queue.
Event Routing is an automated reaction engine. When something happens inside a session -- a risky command runs, an agent queries a sensitive table -- Hoop fires a predefined runbook in response. Before this, teams wired these reactions by hand with custom webhook code. Now an admin writes one rule and Hoop handles the rest.
All three shipped on by default. Every new Hoop deployment now covers database, SSH, and HTTP connections out of the box, under one enforcement layer, from day one.
What this means for the SRE team
The access governance problem in regulated environments is not a policy problem. It is a friction problem. Engineers bypass controls because the controls cost more time than the risk feels worth.
When the secure path and the fast path are the same path, engineers stop looking for workarounds. The audit log fills with real identities instead of shared accounts. Compliance gaps close without a policy fight.
Security teams have spent a decade as the office of no. The way out is not a stricter door. It is a yes that happens to be the easiest command to type.