Topic starter
06/11/2026 6:36 pm
TL;DR: Oak’s guidance shows that SOC 2 evidence for service accounts, API keys, tokens and AI agents usually turns on common criteria such as CC6.1, CC6.2, CC6.3, CC6.6, CC6.8 and CC7.2, with auditors sampling inventory, ownership, approval, review, rotation and decommission records. Standing evidence matters because Type 2 testing lands on whatever exists on the day of the sample.
Editorial analysis by NHI Mgmt Group, based on content published by Oak: “What SOC 2 Asks for on Service Accounts and Other Non-Human Identities”.
By the numbers:
- 40% of machine identities have access to organizational data.
Key questions
Q: How should teams prove ownership for service accounts in SOC 2 audits?
A: Auditors should see each service account mapped to a named human or team, with a documented business owner, technical custodian, and approval trail.
Q: Why do shared credentials create SOC 2 evidence gaps for non-human identities?
A: Shared credentials create SOC 2 evidence gaps because you cannot prove which service account, token, or bot used a secret, when it was used, or who approved its scope.
Q: How does credential rotation affect SOC 2 evidence for API keys and tokens?
A: Credential rotation strengthens SOC 2 evidence when teams can show when API keys and tokens were replaced, why they were replaced, and who approved the change.
Practitioner guidance
- Build a non-human identity inventory with accountable owners Record every service account, API key, token and agent with system, type, owner, creation date and last use so auditors can trace one identity through its lifecycle.
- Attach approvals to the identity lifecycle Require dated provisioning approval before issuance and a documented review decision whenever access changes, so CC6 evidence is time-stamped instead of reconstructed later.
- Prove rotation in the target system Keep rotation records in the system that consumes the credential, not only in the vault, so the old secret cannot still function downstream.
Bottom line: SOC 2 evidence for non-human identities depends on lifecycle controls that can be traced to a named owner, a dated approval and a real revocation record.
What's in the full article
Oak's full blog post covers the operational detail this post intentionally leaves for the source:
- The criterion-by-criterion evidence table auditors use to sample service accounts and other non-human identities
- The practical differences between Type 1 and Type 2 evidence for identity governance
- The mechanics of standing evidence in a live graph, including how review and revocation records are produced
- The platform-specific workflow Oak describes for mapping ownership, review and removal to audited identities
👉 Read Oak's analysis of SOC 2 evidence for service accounts and AI agents →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:42 pm
Ownership is the control that makes SOC 2 evidence real. Without a named owner for each service account, token or agent, approval, review and removal all become unassignable. That is why the audit question is not only whether the secret exists, but whether someone can be held accountable for its lifecycle. In practice, ownership is the difference between a vault record and governance.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How does credential rotation affect SOC 2 evidence for API keys and tokens?
A: Credential rotation strengthens SOC 2 evidence when teams can show when API keys and tokens were replaced, why they were replaced, and who approved the change. Rotation records, secret inventory updates, and revocation logs help prove lifecycle control, while stale credentials with no documented turnover create gaps in ownership and access evidence.
👉 Read our full editorial: SOC 2 evidence for service accounts depends on ownership and review