SOC 2 for non-human identities: governing machine access end to end (on AWS)

When a compromised service account silently copies data or spins up unauthorized resources, the financial and reputational damage can dwarf the cost of a single breach. Without a reliable audit trail, investigators spend weeks reconstructing what a machine did, and regulators may deem the organization non‑compliant.

For organizations bound by soc 2, the missing machine‑level evidence creates a direct compliance shortfall.

Why machine identities are a blind spot

Most teams treat non‑human identities, service accounts, CI/CD tokens, and automated IAM roles as static keys that are checked into code repositories or shared across pipelines. Those credentials often have broad permissions because engineering prefers "it works" over granular scoping. The result is a network where any compromised token can reach a database, an AWS API, or a Kubernetes cluster without triggering an alert. Because the token itself performs the request, there is no per‑action log that ties the activity back to a human decision.

What a compliance program actually requires

SOC 2 trusts principles such as Logical Access Controls and Monitoring. Auditors expect continuous evidence that every access request was authorized, that privileged commands were reviewed, and that sensitive data was protected in‑flight. For non‑human identities this means:

• Records that show exactly which service account executed each command.
• Proof that any request exceeding a risk threshold was approved by a designated reviewer.
• Visibility into data that left a system, with sensitive fields masked before they are stored in logs.
• Session recordings that are retained for replay during an audit.

Meeting these expectations is impossible if the enforcement point lives only in the identity provider or in IAM policies. Those layers decide who may start a request, but they cannot inspect the payload, block dangerous commands, or capture the response.

Putting the enforcement point in the data path

hoop.dev sits on the wire between the machine identity and the target service. Because every connection must pass through the gateway, hoop.dev can apply policy at the exact moment a command is issued.

hoop.dev records each session, stores the full request and response, and writes the log to a storage mechanism that retains its integrity for the audit period. It masks fields such as credit‑card numbers or personally identifiable information before the data reaches storage, ensuring that logs do not become a liability. When a request matches a high‑risk pattern, such as a wildcard delete on a production database, hoop.dev pauses the operation and routes it to a human approver. The approver’s decision is captured alongside the session, creating a single source of truth for the audit.

Because hoop.dev enforces these controls at the protocol level, the underlying service never sees unapproved commands, and the service account never sees raw credentials. The gateway’s policy engine is the only place where command‑level blocking, just‑in‑time approval, and inline masking occur.

How hoop.dev generates SOC 2 evidence

When an automated job runs a SQL query, hoop.dev captures:

• The identity of the service account that initiated the query.
• The exact statement, with any sensitive literals redacted.
• The timestamp and the originating IP address.
• A replayable recording of the session for forensic review.

For a Kubernetes exec, hoop.dev logs the pod name, the container, the command executed, and the result, while masking any secret values that appear in the output. All of these artifacts are stored in a secure audit log that auditors can query directly from the feature documentation. The continuous nature of this collection means that evidence is always fresh, eliminating the need for a manual “snapshot” before an audit.

Getting started with continuous compliance

Deploy the gateway near your workloads using the getting‑started guide. Register each target, RDS, EKS, or an SSH host, and bind the appropriate service account or IAM role to the connection. Once the gateway is in place, define policies that require approval for any command that modifies production data, and enable inline masking for columns that contain regulated information. From that point forward, every machine‑initiated action is automatically recorded and ready for SOC 2 review.

FAQ

Do I need to change my existing CI/CD pipelines?

No. The gateway works with standard clients (psql, kubectl, ssh). Pipelines simply point at the gateway endpoint instead of the raw service address.

Can I use hoop.dev with multiple cloud providers?

Yes. The gateway supports connections to AWS‑hosted databases, Kubernetes clusters, and other targets listed in the documentation.

How does hoop.dev handle secret rotation?

The gateway stores the credential for each connection. When a secret is rotated, you update the connection definition in the gateway; the change is propagated without exposing the new secret to the calling service.

Explore the source code, contribute improvements, and see how the project fits into your compliance roadmap at the official GitHub repository.