SOC 2 for non-human identities: governing machine access end to end

The SOC 2 auditor stops on a single line in your access export: a service account that touched the production database 4,000 times last quarter. Who owns it. What was it allowed to reach. Did anyone approve that. The room goes quiet, because the team built every control for the people who log in and almost none for the machine accounts that never do. SOC 2 for non-human identities is the work of making those silent accounts answer the same questions a human operator would.

Non-human identities are service accounts, CI runners, batch jobs, and increasingly autonomous agents. They authenticate with keys and tokens, they run without a person watching, and they often hold the broadest standing access in the environment. Under SOC 2 they are in scope for the same trust services criteria as any user, and the auditor will ask about them the same way.

The questions an auditor asks about machine access

A SOC 2 access review of non-human identities tends to reduce to four questions, and they map cleanly onto the common criteria for logical access:

• Who is this identity? CC6.1 expects access tied to a defined identity. A shared key that three jobs reuse fails this before anything else, because the auditor cannot attribute an action to an owner.
• What can it reach, and is that the least it needs? The grant should name the specific database, cluster, or host, not a wildcard the account inherited and nobody trimmed.
• Who approved higher-risk access, and when did it end? CC6.2 and CC6.3 expect provisioning and de-provisioning to be authorized and bounded. "It has had that access since 2022" is the answer that produces a finding.
• What did it actually do? The monitoring criteria expect an activity record that is complete and outside the identity's own reach.

Most environments can answer the first two on a good day and stumble on the last two, because the only record of what a service account did lives in logs the account's own host can rotate.

Why the evidence has to live outside the identity

Here is the architectural point that decides whether you generate evidence for SOC 2 or only generate hope. The record that answers "who, what, approved by whom, and what happened" has to be produced and stored by something the non-human identity does not control. If a service account writes its own access log, that log is a claim, not evidence, and a skeptical auditor treats it as such. The control has to sit at the access boundary, between the identity and the infrastructure it reaches, where the identity cannot reconfigure it.

That requirement, evidence created at the boundary rather than reconstructed from inside the audited system, is the architecture hoop.dev is built around. Non-human identities reach databases, Kubernetes, SSH, and internal services through hoop.dev, a Layer 7 access gateway running a network-resident agent. Because every connection passes through that boundary, the per-identity access log, the approval on a higher-risk grant, and the recording of the session are all produced outside the identity using them. hoop.dev itself holds SOC 2 Type II, but the relevant point for your program is mechanical: the gateway emits the records an auditor asks for, by identity, as the work happens. The learn pages on the access model and the getting-started docs show how a machine identity is fronted.

What end-to-end governance produces

Walk one service account through it. A nightly job needs to read a reporting table. It connects through the gateway under its own identity, policy checks the request, the read runs, and the session is recorded on the gateway side. When the auditor pulls that account's history, every connection carries an identity, a scope, the approval state, and a recording. The 4,000 touches that looked like an unexplained mass become 4,000 attributable, scoped, recorded events. That is the difference between a service account that is a finding and one that is evidence.

FAQ

Does using hoop.dev make our non-human identities SOC 2 compliant?

No. SOC 2 is an audit of your organization, not a property of a tool. hoop.dev generates the access evidence, per-identity logs, approvals, and session records, that your SOC 2 program presents for the logical access criteria. The certification is yours to earn.

Are non-human identities really in scope for SOC 2?

Yes. The logical access common criteria do not distinguish human from machine. Any identity that can reach a system in scope is in scope, and machine accounts usually hold the widest access, so auditors look at them closely.

hoop.dev is open source. To put a recorded, per-identity access boundary in front of the infrastructure your machine accounts reach, start from the repository on GitHub.