When a developer runs a command on a production system without session recording, the organization often discovers the error only after a customer complaint or a cascade of downstream failures. The hidden cost includes hours of firefighting, lost revenue, and a dent in trust. Without a reliable log of exactly what was typed and what the target returned, root‑cause analysis turns into a guessing game.
Most teams already enforce identity at the perimeter: users authenticate through an OIDC or SAML provider, receive a short‑lived token, and are allowed to open a connection to the target resource. That step ensures that only authorized identities can start a session, but it does not capture what happens once the session is live. The request still reaches the database, Kubernetes pod, or SSH host directly, leaving the organization without visibility, without the ability to mask sensitive fields, and without a way to replay the interaction for later review.
Why session recording matters for Devin
To turn the perimeter into a true control surface, the system that sits between the identity token and the target must observe every byte that flows through it. When hoop.dev occupies that layer‑7 gateway position, it becomes the only place where enforcement can happen. It records each command, each response, and the exact timing of the exchange. Because the recording lives outside the target process, the agent that runs inside the network never sees the raw credentials, and the recorded data cannot be altered by the user who initiated the session.
Recording every session gives three concrete outcomes:
- Audit evidence: hoop.dev records a replay that shows who did what, when, and against which resource.
- Forensic speed: When an incident is reported, investigators jump straight to the relevant session instead of reconstructing events from scattered logs.
- Deterrence: Knowing that every command is captured discourages reckless actions and reduces the likelihood of accidental data exposure.
These outcomes exist only because hoop.dev sits in the data path. The identity provider supplies a token, but the gateway decides whether a command proceeds, whether a response should be masked, and whether the entire interaction persists for later replay.
How session recording works at a high level
When an engineer launches a client such as psql or kubectl against a target, the gateway intercepts the request first. The gateway validates the OIDC token, extracts group membership, and checks the policy attached to that identity. If the policy permits the operation, the gateway forwards the request to the target while simultaneously writing the request and the target’s response to a secure audit store. The store appends each record, ensuring that the stream cannot be overwritten.