A single rogue admin command can erase years of work and ruin a SOC 2 audit.
Most organizations still rely on local administrator accounts that are shared across engineers, contractors, and automated scripts. Those credentials are often stored in plain text files, embedded in CI pipelines, or written on sticky notes. When a user logs into a workstation, the system trusts the local OS to enforce policy, but no central record shows which command was typed, which file was read, or whether a sensitive value was displayed on screen. The result is a black box: auditors see a signed SOC 2 report, but they cannot verify that every privileged action on a computer was observed, approved, or masked.
Even when companies adopt single sign‑on or MFA, the control stops at authentication. The identity provider confirms who the user is, but the request still travels directly to the endpoint. There is no inline guard that can block a dangerous shell command, no just‑in‑time approval workflow for a database dump, and no replayable session that proves a user complied with data‑handling rules. In other words, the setup provides identity but no continuous evidence.
Why continuous evidence matters for SOC 2
SOC 2’s Trust Services Criteria require that organizations demonstrate effective controls over security, availability, processing integrity, confidentiality, and privacy. For the “security” and “confidentiality” criteria, auditors look for logs that prove who accessed what, when, and what the outcome was. Those logs must be immutable, tied to a verified identity, and detailed enough to show that sensitive fields were protected. If a user runs rm -rf / on a production server, the evidence must capture the command, the user’s identity, and the fact that the action was either approved or blocked.
Continuous evidence also supports the “availability” and “processing integrity” criteria. A replayable session can reveal whether a service outage was caused by an unauthorized change, and it can help trace the root cause of data corruption back to a specific command. Without a mechanism that sits on the data path and records every interaction, the organization is forced to rely on periodic snapshots or after‑the‑fact forensic analysis, which does not satisfy SOC 2’s requirement for real‑time assurance.
Introducing a gateway that lives in the data path
To turn the black box into a transparent audit trail, the enforcement point must be the gateway that proxies every connection to a computer. That gateway can inspect the wire‑level protocol, enforce policies, and generate immutable logs before the request ever reaches the target host. This is where hoop.dev fits the architectural requirement.
hoop.dev sits between the user’s client and the workstation, container, or VM. It authenticates the user via OIDC or SAML, reads group membership, and then applies a series of controls on the live session:
- Session recording: hoop.dev records each keystroke, command output, and screen change, producing a replayable artifact that auditors can review.
- Just‑in‑time approval: before a high‑risk command such as a database dump or a privileged script runs, hoop.dev routes the request to an approver and blocks execution until consent is recorded.
- Inline data masking: when a command returns sensitive fields, credit card numbers, personal identifiers, hoop.dev masks those values in the response before they reach the client.
- Command blocking: dangerous patterns like rm -rf / or unsafe shell expansions are intercepted and denied by hoop.dev.
Because hoop.dev is the only point that can see the traffic, every enforcement outcome exists solely because hoop.dev sits in the data path. Remove hoop.dev and the session would flow directly to the computer with no audit, no masking, and no approval.
How continuous evidence aligns with SOC 2 controls
SOC 2 requires that each privileged access be traceable to an individual identity and that the organization retain evidence of that access for the audit period. hoop.dev satisfies these requirements in three ways:
- Identity‑bound logs: each session record includes the OIDC token subject, timestamp, and the exact command sequence, tying activity to a verified user.
- Durable retention: the recorded sessions are stored in a log that can be queried for any date range, ensuring the evidence is available when auditors request it.
- Policy‑driven masking: sensitive data never leaves the gateway in clear text, so the organization can demonstrate compliance with confidentiality clauses without exposing raw values.
These capabilities are described in the feature documentation and can be enabled with a few configuration steps outlined in the getting started guide. The open‑source nature of hoop.dev also lets security teams review the code that generates the audit evidence, reinforcing trust in the control plane.
FAQ
Does hoop.dev replace existing logging agents?
No. hoop.dev complements host‑based logs by providing a unified, protocol‑aware audit trail for every privileged session. It does not interfere with syslog or Windows Event logs; instead, it adds a higher‑level view that ties actions to identities and policy decisions.
Can hoop.dev be used with existing CI/CD pipelines?
Yes. CI jobs can invoke commands through hoop.dev just like a human operator would. The gateway will still enforce approvals and record the session, giving the same level of evidence for automated deployments as for manual actions.
Is the recorded session data encrypted?
The session payload is stored using industry‑standard encryption at rest. Encryption keys are managed outside the gateway, ensuring that only authorized auditors can decrypt and review the logs.
Get involved
hoop.dev is open source and welcomes contributions. Explore the code, submit issues, or start a pull request on the official repository:
https://github.com/hoophq/hoop
