What SOC 2 Means for Self-Hosted Models

What does SOC 2 really demand from a self‑hosted infrastructure?

Organizations that run their own servers, containers, or databases must still prove that they meet the Trust Services Criteria that SOC 2 evaluates. The standard expects documented policies, evidence of controlled access, immutable logs of privileged actions, and proof that sensitive data is protected at rest and in transit. Auditors look for a clear chain of custody: who initiated a connection, what commands were executed, and whether any data exposure was approved or masked. Without a single source that captures these details, the compliance team is left piecing together ad‑hoc logs, SSH history, and manual change tickets – a process that rarely satisfies a SOC 2 audit.

Current reality in many self‑hosted environments

Most teams start with a pragmatic, but insecure, setup. A handful of engineers share a root SSH key that lives in a repository. Database administrators use a static admin password that rotates only when a breach is suspected. Access is granted on a standing‑basis, often via firewall rules that never change. Logging is optional; when it exists it is stored on the same host that runs the workload, making it easy for an attacker to tamper with or delete it. The result is a landscape where anyone with the shared credential can connect directly to the target, perform any command, and leave no trace for auditors.

What the standard fixes – and what it still leaves open

SOC 2 requires that access be granted on a least‑privilege basis and that each privileged action be recorded. The standard also mandates that sensitive fields be protected from unnecessary exposure. However, the requirement does not prescribe how the connection itself is mediated. In practice, the request still reaches the database, Kubernetes node, or SSH daemon directly, bypassing any checkpoint that could enforce approval, mask data, or guarantee an immutable audit trail. The missing piece is a control plane that sits between the identity that initiates the request and the resource that fulfills it.

Why the data path must host enforcement

The only place to enforce SOC 2 controls is on the network path that carries the request. Setup components – OIDC providers, service accounts, IAM roles – decide who is allowed to start a session, but they cannot block a dangerous command once the session is active. If enforcement lives inside the target process, a compromised agent could disable logging or alter masking rules. The gateway model moves the enforcement point out of the target’s control, ensuring that every request is inspected, approved, and recorded before it ever touches the resource.

hoop.dev as the SOC 2‑ready gateway

hoop.dev implements exactly this architectural requirement. It acts as an identity‑aware proxy that sits between users, AI agents, or service accounts and the self‑hosted resource. When a request arrives, hoop.dev verifies the OIDC token, extracts group membership, and applies policy decisions in real time. It can:

• Require just‑in‑time approval for high‑risk commands.
• Mask sensitive fields in database responses before they reach the client.
• Block prohibited commands outright.
• Record the entire session for replay and audit.

Because hoop.dev is the only component that sees the traffic, the enforcement outcomes exist solely because hoop.dev sits in the data path. Removing hoop.dev would revert the environment to the insecure baseline described earlier.

How hoop.dev generates SOC 2 evidence

Auditors require concrete artifacts that demonstrate control effectiveness. hoop.dev provides the following evidence automatically:

• Session logs: Every connection is timestamped, linked to a specific identity, and stored outside the target host. The logs include command strings, response metadata, and approval timestamps.
• Approval trails: When a privileged action triggers a workflow, hoop.dev records who approved, when, and why. This satisfies the “authorization” criterion of SOC 2.
• Data masking records: For any field that hoop.dev masks, the system logs the original value hash and the masked output, proving that confidentiality controls were applied without exposing the raw data to the client.
• Change‑management snapshots: Because hoop.dev mediates configuration changes, any alteration to connection credentials or policy rules is captured as a recorded event.

All of these artifacts are available through the built‑in audit UI and can be exported for the audit package. Because hoop.dev is open source and MIT‑licensed, organizations can inspect the code to confirm that the logging mechanisms meet their internal assurance requirements.

Getting started with hoop.dev for SOC 2 compliance

The first step is to deploy the gateway near the resources you want to protect. The official getting‑started guide walks you through a Docker Compose deployment that includes OIDC authentication, default masking policies, and session recording. After the gateway is running, register each self‑hosted target – a PostgreSQL instance, a Kubernetes cluster, an SSH host – in hoop.dev’s configuration. The gateway stores the service credentials, so engineers never see them directly.

Once the connections are registered, define policies that align with your SOC 2 control matrix. For example, you can require approval for any dangerous command such as dropping a database, mask columns that contain personally identifiable information, and restrict SSH access to a specific role group. The learn section contains detailed policy examples and best‑practice recommendations.

Because hoop.dev records every session, you can generate the audit reports required for the SOC 2 audit with a few clicks. The reports include user‑level activity, approval histories, and masking logs, giving auditors a complete picture of who did what, when, and why.

Call to action

Explore the source code, contribute improvements, or fork the project for your own compliance pipeline on GitHub.

FAQ

Do I need to replace my existing identity provider?

No. hoop.dev works as a relying party for any OIDC or SAML provider you already use. It reads the token, validates it, and applies your existing group memberships to its policy engine.

Can hoop.dev protect data that lives outside the gateway, such as backups?

hoop.dev only enforces controls on the traffic that passes through it. For backup storage you would need a separate solution, but you can still use hoop.dev to audit who initiates the backup operation.

Is the audit data stored securely?

The gateway records logs outside the target host, providing a reliable audit trail for the review period.