How can you prove that every line of code run in your environment was authorized, executed by the right person, and left an immutable trail for auditors? The answer is to generate continuous compliance evidence that ties identity, action, and outcome together.
In many organizations the day‑to‑day workflow looks like this: a shared SSH private key is checked into a repository, engineers log directly to production servers, and the key never expires. Access is granted once and never reviewed. That setup gives no visibility into who ran what, and no way to stop a dangerous command.
Moving to federated identity providers and short‑lived tokens improves who can start a session, but the request still goes straight to the target host. There is still no single point that can record each command, mask sensitive output, or require a human approval before a risky operation proceeds.
Why traditional logs fall short
Auditors typically ask for three things when they review code execution: who ran the command, what the command did, and whether any sensitive data was exposed. Most organizations rely on operating‑system syslogs, cloud‑provider audit trails, or ad‑hoc script wrappers. Those sources have two major gaps.
- Missing context. A syslog entry may show a user ID, but it rarely captures the full command line, the exact output, or the downstream effects of the command.
- Uncontrolled exposure. When a script prints credentials or personal data, the raw output lands in the same log file that auditors later inspect, creating a privacy risk.
Both gaps make it hard to produce reliable compliance evidence that satisfies standards such as SOC 2, ISO 27001, or internal governance policies. Without a unified capture point, you end up stitching together fragmented data that can be disputed or, worse, altered before it reaches the audit team.
What a complete evidence strategy looks like
A comprehensive evidence pipeline for code execution must provide three capabilities at the point where the command is issued:
- Identity‑bound session recording. Every keystroke and command output is tied to the authenticated identity that initiated it.
- Just‑in‑time approval for risky actions. Commands that could modify production state, delete data, or expose secrets trigger a workflow that requires a human approver before the command is sent to the target.
- Inline data masking. Sensitive fields in command responses, passwords, tokens, or personal identifiers, are redacted in real time, preserving privacy while still keeping a verifiable audit trail.
When these controls sit on the same layer that brokers the connection, you gain a single source of truth that cannot be bypassed by the user or a compromised agent.
hoop.dev as the enforcement point
Enter hoop.dev. It is a Layer 7 gateway that sits between identities (engineers, service accounts, or AI agents) and the execution environment, whether that is an SSH server, a container exec endpoint, or a remote code‑execution API.
hoop.dev records each session in a secure audit store, attaching the user’s OIDC or SAML identity to every command and its output. The recording includes timestamps, the exact command line, and a replayable stream that auditors can review without needing access to the original host.
When a command matches a policy that marks it as high‑risk, such as a database schema change, a deployment script, or a privileged sudo operation, hoop.dev routes the request to an approval workflow. A designated approver receives a concise request, approves or denies it, and the decision is logged alongside the session. This workflow turns ad‑hoc “run‑as‑root” actions into auditable events.
Simultaneously, hoop.dev can mask sensitive patterns in the command output. For example, if a script prints an API key, the gateway replaces the key with a placeholder before the data reaches the user’s terminal. The masked output is still stored in the audit log, preserving the evidence that the key was accessed while protecting the secret from accidental exposure.
Because the gateway is the only component that sees the raw traffic, the evidence it generates cannot be altered by the client, the agent, or the target host. The audit records are written outside the execution environment, satisfying the “immutable evidence” requirement that many compliance frameworks demand.
How the evidence integrates with your audit process
All recorded sessions are indexed by identity, timestamp, and resource. You can feed the index into a SIEM, a compliance dashboard, or an automated report generator. The logs are searchable for queries such as “show every sudo command executed by the finance team in the last 30 days” or “list all commands that attempted to read the /etc/shadow file.” Because hoop.dev already masks the sensitive fields, you can safely share these logs with auditors without risking credential leakage.
Because hoop.dev is open source and MIT‑licensed, you can self‑host the gateway in your own network, ensuring that the audit data never leaves your control plane. The deployment options include Docker Compose for quick trials and Kubernetes manifests for production‑grade installations. Detailed instructions are available in the getting‑started guide and the broader learn section.
Frequently asked questions
What types of code execution does hoop.dev support?
hoop.dev proxies SSH, RDP, container exec, and any protocol that can be wrapped by its agent. This covers most scenarios where a developer or automation runs commands on a remote host, including CI/CD runners that need to execute scripts inside a protected environment.
How does hoop.dev guarantee the integrity of the audit records?
Because the gateway sits in the data path, it writes each session to a store that is separate from the target host. The write operation is performed after the command finishes, and the record includes a cryptographic hash of the raw output. The hash is computed before any masking occurs, ensuring the original data can be verified without exposing it.
Can I forward hoop.dev’s audit logs to an existing SIEM?
Yes. hoop.dev emits structured JSON events that can be streamed to any log collector, including Splunk, Elastic, or a cloud‑based SIEM. The events contain the identity, resource, command, and approval status, making it straightforward to build compliance dashboards or trigger alerts on policy violations.
Get started with continuous compliance evidence
If you need a single, enforceable point that produces trustworthy evidence for every piece of code that runs in your environment, the architecture described above is the only one that satisfies all three pillars, recording, approval, and masking, without relying on disparate tools. hoop.dev implements that architecture out of the box.
Explore the source code, contribute, or spin up a trial deployment by visiting the GitHub repository. The community and documentation are ready to help you turn continuous compliance evidence from a goal into a reality.
