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

When an auditor asks for evidence that every automated job, service principal, and container‑based agent is governed, the ideal evidence consists of a comprehensive, immutable audit trail that shows who requested access, when it was granted, what commands were run, and which data fields were protected.

Achieving that level of visibility for non‑human identities means moving beyond static secrets and trusting that a machine will behave correctly because its credentials are stored somewhere safe.

Understanding soc 2 requirements for machine identities

soc 2 focuses on five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. For non‑human identities the standard expects:

• Logical access controls that enforce least‑privilege for every service account.
• Documented approval workflows before privileged actions are allowed.
• Immutable logs that capture each request, the identity that initiated it, and the resulting activity.
• Mechanisms to mask or redact sensitive data in responses when confidentiality is required.
• Periodic review of access rights and evidence that those reviews were performed.

These controls must be demonstrable during an audit, which means the evidence cannot be generated solely by the application or by the identity provider.

Why the traditional Azure setup falls short

Most teams provision a service principal in Azure AD, assign it a role, and store its client secret or certificate in a vault. The application then uses that credential to call Azure APIs or connect to a database directly. This model satisfies the “who can call” part of the setup, but it leaves three gaps:

• The request travels straight to the target resource, so there is no point where the organization can inject approval or masking logic.
• The resource itself logs only limited audit trails, often omitting the originating machine identity or the exact command issued.
• If the secret is compromised, every standing connection becomes instantly exploitable until the secret is rotated.

In other words, the setup decides who may start a session, but it does not enforce policy on the data path, nor does it generate the evidence required by soc 2.

The missing enforcement layer

To meet soc 2, an organization must place a control surface between the identity provider and the target resource. That surface must be the only place where the gateway inspects each request, approves it, records it, and masks it when necessary before it reaches the backend.

Introducing hoop.dev as the data‑path gateway

hoop.dev inserts a Layer 7 gateway that sits directly in the network path between non‑human identities and Azure resources. Because the gateway is the sole conduit, it can enforce all required controls.

• hoop.dev records each session, capturing the service principal, timestamp, and exact commands executed.
• hoop.dev masks sensitive fields in responses, ensuring confidentiality without changing application code.
• hoop.dev requires just‑in‑time approval for privileged operations, pausing the request until an authorized human reviewer grants access.
• hoop.dev blocks disallowed commands before they reach the target, reducing blast radius.
• hoop.dev never exposes the underlying credential to the calling process; the agent authenticates to the gateway, which then uses its own stored secret.

All of these outcomes exist only because hoop.dev occupies the data path. The identity provider still decides who may request access, but the enforcement happens downstream, exactly where soc 2 demands evidence.

Mapping hoop.dev capabilities to soc 2 criteria

Security: By enforcing least‑privilege and just‑in‑time approval, hoop.dev ensures that machines cannot perform actions beyond their intended scope.

Processing integrity: Recorded sessions allow auditors to verify that each command was executed as authorized, and any deviation is visible.

Confidentiality: Inline masking guarantees that sensitive data never leaves the gateway unprotected, satisfying the confidentiality principle.

Availability: The gateway can be deployed in high‑availability mode, and its audit logs are stored independently of the target, proving that logging does not affect service uptime.

Privacy: Masking and selective redaction help meet privacy‑related requirements without redesigning the application.

Getting started with hoop.dev on Azure

Deploy the gateway using the provided Docker Compose file or the Azure‑specific deployment guide. Configure your service principals as OIDC clients, and register each Azure resource (SQL Database, Kubernetes cluster, etc.) as a connection. The getting‑started guide walks you through the steps, and the policy documentation explains how to define approval workflows and masking rules.

FAQ

Do I need to change my existing service principal permissions? No. hoop.dev works with the existing Azure AD identity. It simply adds a control layer that inspects every request before it reaches the target.

How long are session logs retained? Retention is configurable in the gateway’s policy store; logs remain available for the period required by your soc 2 audit schedule.

Can hoop.dev be used with other cloud providers? Yes. The gateway is cloud‑agnostic and can front resources in AWS, GCP, or on‑prem environments, but this article focuses on Azure.

Explore the open‑source code and contribute on GitHub.