Many teams believe that simply assigning service accounts is enough to satisfy soc 2, but that view ignores the need for continuous, auditable control over machine‑initiated actions.
In most on‑prem environments, non‑human identities – service accounts, CI/CD tokens, and automation bots – are provisioned once and then left to run indefinitely. Credentials are often stored in shared files or environment variables, and the same secret may be reused across dozens of pipelines. When a job fails or a script misbehaves, there is rarely any record of which identity issued which command, what data was returned, or whether the operation complied with policy. The result is a black box that auditors cannot inspect.
Even when organizations adopt modern identity providers and enforce least‑privilege roles, the enforcement point remains at the identity layer. An OIDC token may prove who the caller is, and an IAM role may restrict which resources can be touched, but nothing stops the caller from issuing a destructive SQL statement, reading raw logs, or exfiltrating data once the connection is established. The audit trail is limited to authentication events; the actual activity inside the session is invisible.
What soc 2 expects for machine access
soc 2 focuses on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For the security criterion, auditors look for evidence that every access request – human or machine – is authorized, monitored, and recorded. Specific artifacts include:
- Authenticated identity logs showing who or what initiated a connection.
- Authorization decisions that tie a request to a policy (e.g., least‑privilege, just‑in‑time approval).
- Detailed activity logs that capture each command or query executed during a session.
- Evidence of data protection, such as masking of sensitive fields in responses.
- Retention of session recordings that can be replayed for forensic analysis.
Without a mechanism that captures these artifacts at the point of interaction, organizations rely on ad‑hoc scripts or manual log collection, which are error‑prone and often incomplete. Auditors will flag the lack of granular, immutable evidence as a control weakness.
The missing control surface
Identity management and role‑based policies address “who may access,” but they do not address “what is done once access is granted.” The missing piece is a data‑path enforcement layer that sits between the non‑human identity and the target system. This layer must be able to:
- Inspect each request in real time and enforce command‑level policies.
- Require a human approval step for high‑risk operations before they are forwarded.
- Mask or redact sensitive fields in responses to protect confidentiality.
- Record the full session for later replay and audit.
Only when such a gateway exists can an organization produce the full set of soc 2 artifacts that auditors demand.
How hoop.dev fulfills the data‑path requirement
hoop.dev is a Layer 7 gateway that sits in the data path for every connection made by a non‑human identity. By proxying traffic to databases, Kubernetes clusters, SSH servers, and HTTP services, hoop.dev can apply the controls listed above without exposing credentials to the calling process. The gateway records each session, masks configured fields, and can pause a request for a just‑in‑time approval workflow. Because the enforcement happens outside the agent that runs the workload, the agent never sees the secret, and the policy engine cannot be bypassed by the workload itself.
From an auditor’s perspective, hoop.dev generates the evidence required by soc 2: