Many teams assume that non‑human identities automatically satisfy SOC 2 requirements, but that belief ignores the need for continuous audit evidence.
Non‑human identities, service accounts, automation bots, CI/CD runners, and API clients, are the workhorses of modern infrastructure. They hold the keys that let scripts spin up clusters, push code, or query databases without a human at the keyboard.
SOC 2 focuses on the five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For each criterion, auditors expect to see who accessed a system, what they did, and when they did it. The standard does not accept “it worked” as evidence; it demands a verifiable trail that can be examined at any time.
In practice, most organizations grant these bots static credentials that live in configuration files or secret stores. The bot connects directly to the target, say a PostgreSQL instance or a Kubernetes API, using the stored password or key. The connection bypasses any central control point, and the system rarely records which bot issued which command. Approvals, masking of sensitive fields, or real‑time command checks are absent.
This pattern fails SOC 2 on several fronts. Without a centralized log, you cannot prove that a service account performed only its intended actions. There is no way to demonstrate that privileged commands were reviewed before execution, nor can you show that sensitive data was protected during a query. Auditors therefore see a gap between policy and practice, and the organization risks non‑compliance.
SOC 2 evidence requirements for non‑human identities
The missing piece is a control surface that sits on the data path, where every request can be inspected, approved, or blocked. The control surface must be able to:
- Capture who (which identity) initiated each session.
- Record every command or query issued during the session.
- Apply inline masking to protect confidential fields in responses.
- Require just‑in‑time (JIT) approval for high‑risk operations.
- Make the audit trail available to your log storage of choice for later review.
When these capabilities are present, the organization can produce the continuous evidence that SOC 2 auditors demand.
Introducing an identity‑aware gateway
hoop.dev is an open‑source Layer 7 gateway that fulfills the data‑path requirement. It authenticates users and bots via OIDC or SAML, reads group membership, and then enforces policy on the wire before the request reaches the target system.
Because the gateway holds the credential for the downstream resource, the calling identity never sees the secret. The gateway can grant a short‑lived token that expires when the session ends, ensuring that standing access does not persist.
Enforcement outcomes that satisfy SOC 2
hoop.dev records every session, providing a complete log of who accessed what and when. It masks sensitive fields in real time, demonstrating confidentiality controls. It blocks dangerous commands before they reach the target, showing that processing integrity is enforced. For operations that exceed a predefined risk threshold, hoop.dev routes the request to a human approver, creating an auditable approval record. All of these outcomes are produced because hoop.dev sits in the data path, the only place enforcement can occur.
Continuous audit evidence
The logs generated by hoop.dev can be forwarded to your existing log‑aggregation pipeline or SIEM, providing a complete record for audit. Because each log entry includes the identity, timestamp, command, and any masking actions, auditors can query the data to verify compliance with the security and confidentiality criteria of SOC 2. Approvals are also stored alongside the session record, giving a single source of truth for the processing‑integrity requirement.
Operational benefits
By centralising access through hoop.dev, organizations reduce blast radius. If a service account is compromised, the attacker can only act within the constraints defined by the gateway. The continuous evidence also simplifies audit preparation: instead of hunting across disparate logs, the audit team pulls a single, filtered view from the gateway’s store.
Getting started
To adopt this approach, begin with the getting‑started guide, which walks you through deploying the gateway, configuring OIDC, and registering a non‑human identity. The learn section provides deeper coverage of masking policies, JIT approvals, and session replay.
Explore the open‑source repository on GitHub to review the code, contribute, or customize the gateway for your environment.
FAQ
Q: Does using hoop.dev replace existing secret‑management tools?
A: No. hoop.dev works alongside secret stores. It holds the credential for the downstream target, while the secret store supplies the credential to the gateway during registration.
Q: Can hoop.dev be used with existing CI/CD pipelines?
A: Yes. CI/CD jobs can obtain a short‑lived token from the gateway after authenticating via OIDC, then run their usual commands through the gateway without code changes.
Q: How does hoop.dev help with the confidentiality criterion of SOC 2?
A: By applying inline data masking on responses, hoop.dev ensures that sensitive fields never leave the target in clear text, and the masking actions are logged for audit.
