Auditors will reject a tool‑use program that cannot prove who did what, when, and why.
Most organizations let engineers, scripts, or even AI agents run commands against databases, Kubernetes clusters, or remote servers using shared credentials or long‑lived service accounts. The convenience is real, but the audit trail is usually a handful of log lines that do not tie a specific identity to a specific query. When a regulator asks for proof that a privileged command was authorized, the answer is often "we don’t have that data". That gap creates risk, delays certifications, and can lead to costly penalties.
What auditors actually look for
Compliance frameworks require three core artifacts: a verifiable identity for every request, a record of the exact operation performed, and evidence that any sensitive data was protected during the interaction. The evidence must be immutable, time‑stamped, and tied to the policy that governed the request. In practice, this means you need session recordings, command‑level logs, approval workflow records, and inline masking logs that show what data was hidden.
How hoop.dev generates compliance evidence
hoop.dev sits on the data path between the caller and the target infrastructure. Identity is verified once via OIDC or SAML, and the gateway decides whether the request may proceed. Because the gateway is the only place the traffic passes, hoop.dev can enforce and record every action.
- Session recording: hoop.dev captures the full request and response stream for each connection. The recording lives outside the agent that runs the target, so the agent never sees the raw credential.
- Command‑level audit: each SQL statement, kubectl command, or SSH instruction is logged with the user’s identity, timestamp, and the policy that allowed it.
- Just‑in‑time approval: risky operations trigger a workflow that requires a human approver before the gateway forwards the command.
- Inline data masking: responses that contain personally identifiable information are masked in real time, and the masking event is logged as part of the audit trail.
All of these enforcement outcomes exist because hoop.dev is the gateway that inspects traffic. The underlying identity provider only tells hoop.dev who the caller is; it does not enforce command‑level policies or generate the session recordings that auditors demand.
Integrating hoop.dev into your compliance program
Start by deploying the gateway in the same network segment as the resources you need to protect. The quick‑start uses Docker Compose and requires only an OIDC configuration. Once the gateway is running, register each target, PostgreSQL, Kubernetes, SSH, etc., and let hoop.dev hold the credentials. From that point forward, every tool interaction flows through the gateway, automatically producing the compliance evidence you need.
Because hoop.dev is open source and MIT‑licensed, you can inspect the code, extend the masking rules, or ship the audit logs to a SIEM of your choice. The documentation walks you through connecting the gateway to your existing identity provider and setting up just‑in‑time approvals.
Mapping evidence to compliance frameworks
Regulations such as SOC 2, ISO 27001, or industry‑specific standards all require verifiable logs of privileged access. hoop.dev’s session recordings satisfy the “record of activity” clause, while the command‑level audit satisfies “who performed the action”. Inline masking logs address data‑privacy requirements by showing that sensitive fields were protected at the point of delivery. By exporting these artifacts to your audit repository, you can demonstrate continuous compliance rather than assembling ad‑hoc evidence during an audit window.
Best practices for audit readiness
- Enable retention policies that keep recordings for the period required by your regulator.
- Tag approval workflows with business justification fields so the auditor can see why a risky command was allowed.
- Integrate the audit stream with a centralized log analysis platform to enable searchable queries across all tool interactions.
- Periodically review masking rules to ensure they cover new PII fields as your applications evolve.
Getting started
For a hands‑on walkthrough, see the getting‑started guide. The learn section provides deeper coverage of session recording, masking, and approval workflows.
Explore the open‑source code on GitHub: https://github.com/hoophq/hoop.
FAQ
What kind of logs does hoop.dev produce?hoop.dev emits identity‑bound, time‑stamped logs for every command, plus separate records for approvals and masking events. The logs can be shipped to any log aggregation system.Can I use hoop.dev with existing CI/CD pipelines?Yes. Because the gateway presents the same wire‑protocol as the native target, CI tools can point at hoop.dev without code changes, gaining audit and masking automatically.Does hoop.dev replace my existing IAM policies?No. IAM or cloud‑provider policies still decide whether the gateway itself may access a resource. hoop.dev adds the enforcement layer that records and controls each individual request.
By placing the enforcement point on the data path, hoop.dev turns every tool interaction into verifiable compliance evidence, giving auditors the artifacts they demand without disrupting developer workflows.
