What a compliant environment looks like
In a fully compliant system, a narrowly scoped identity issues every machine‑to‑machine request, the system evaluates it against a central policy, records it in an immutable audit log, and automatically masks or blocks it when it touches sensitive data. You can trace any deviation back to a single identity and a single decision point. The audit trail is complete, the approval workflow is visible, and auditors see the evidence they require.
Why SOC 2 matters for machine identities
SOC 2 focuses on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For internal SaaS platforms, the security and confidentiality criteria are the most relevant when machines act on behalf of users. Auditors look for evidence that:
- Access is granted on a least‑privilege basis.
- All privileged actions are logged with identity, time, and outcome.
- Sensitive fields are protected from exposure.
- Exceptional actions require explicit approval.
When these controls are missing, the audit report will flag “inadequate monitoring of service accounts” or “unrestricted service‑account keys”.
The unsanitized starting state
Many teams still rely on static service‑account credentials that share across dozens of services. These credentials often have broad permissions, live in configuration files, and teams rotate them only when a breach is discovered. Engineers embed them in CI pipelines, and the same key accesses databases, Kubernetes clusters, and internal APIs. Because the connection goes directly from the service to the target, there is no single point where policy can be inspected. The result is:
- No real visibility into which service performed which query.
- No way to mask credit‑card numbers or personal identifiers that leak in query results.
- No approval step for destructive commands such as DROP DATABASE.
- Audit logs are scattered across each downstream system, making correlation painful.
Auditors see a landscape of “standing access” that violates the principle of least privilege and lacks verifiable evidence.
The missing enforcement layer
What organizations often fix first is the identity side: they move to OIDC‑issued service accounts, enforce short‑lived tokens, and tighten IAM policies. Those steps decide who can start a request, but they do not provide the enforcement point where a request can be examined, approved, or recorded. The request still travels straight to the database or Kubernetes API, leaving the audit gap untouched.
hoop.dev as the data‑path gateway
Enter hoop.dev. It forces all traffic from a non‑human principal through this gateway, making it the only place where policy can be applied.
Setup – identity and provisioning
Service accounts authenticate to the gateway via OIDC or SAML tokens. The gateway validates the token, extracts group membership, and maps the identity to a set of allowed connections. The gateway stores the credential inside itself, so the service never sees it.
The data path – where enforcement lives
Because every packet passes through hoop.dev, the gateway inspects the protocol, applies inline masking, blocks disallowed commands, and triggers just‑in‑time approval workflows.
Enforcement outcomes
hoop.dev records each session, including the identity, timestamp, command, and response. It masks fields such as SSNs or credit‑card numbers in real time, ensuring confidentiality. When a command matches a high‑risk rule, the gateway pauses execution and routes the request to a human approver. After approval, the gateway replays the command through the same path, preserving the audit record. Because the gateway owns the credential, the downstream service never sees the secret, eliminating credential leakage.
Mapping hoop.dev controls to SOC 2 criteria
Auditors ask for concrete evidence. hoop.dev provides it in the following ways:
- Security – access control: Just‑in‑time approval and policy‑driven command blocking enforce least‑privilege at the moment of use.
- Confidentiality – data protection: Real‑time masking hides sensitive fields before they reach logs or downstream consumers.
- Processing integrity – accurate execution: Session replay proves that commands were executed exactly as authorized.
- Auditability – traceability: Centralized logs contain identity, decision, and outcome for every machine request, satisfying the “complete audit trail” requirement.
Because the enforcement point sits outside the target system, a compromised downstream service cannot alter the evidence, which aligns with the integrity expectations of SOC 2.
Getting started
To adopt this model, begin with the getting started guide. Deploy the gateway near your internal SaaS services, configure OIDC for your service accounts, and define policies that reflect your SOC 2 control objectives. The learn section contains detailed explanations of masking rules, approval workflows, and session replay.
FAQ
Do I need to replace existing service‑account keys?
No. Existing keys can be rotated into the gateway’s credential store. Once the gateway mediates the connection, the downstream service no longer sees the original key.
Yes. The gateway supports databases, Kubernetes, SSH, and HTTP APIs, so you can protect all machine‑to‑machine traffic from a single control plane.
How does hoop.dev help during a SOC 2 audit?
The audit team can request the centralized session logs, approval records, and masking policies. Those artifacts demonstrate compliance with access‑control, confidentiality, and audit‑trail criteria without needing to collect logs from each downstream system.
Contribute or explore the code
Explore the source code and contribute on GitHub.
