What SOC 2 Asks for on Service Accounts and Other Non-Human Identities

Introduction

Non-human identity audit evidence for SOC 2 comes mostly from the same common criteria that govern your people: CC6.1, CC6.2, CC6.3, CC6.6, CC6.8 and CC7.2. For service accounts, API keys, tokens and AI agents, this guide groups the evidence into six artifacts.

Those artifacts are inventory, ownership, provisioning approval, access reviews, credential rotation and removal at decommission.

A SOC 2 Type 2 report tests whether those controls operated across the whole period. Each artifact has to exist on whatever day the sample lands.

This guide maps each criterion to the evidence an auditor asks for and shows where manager-led processes break.

It also explains how Oak, the AI-native identity operating system, keeps that evidence standing.

Key takeaways

• CC6 and CC7.2 reach service accounts, keys, tokens and AI agents, because auditors commonly treat any principal that authenticates to an in-scope system as covered.
• Ownership is the evidence approval, review and removal all depend on.
• A vault proves storage, while owners and reviews prove control.
• Oak keeps that evidence standing between audits.

Which SOC 2 criteria reach non-human identities

The 2017 Trust Services Criteria define the common criteria, including CC6 logical and physical access controls and CC7 system operations. They are written as outcomes, and your organization designs the controls that meet them.

The CC6 criteria are not written for people alone. The criteria refer to users, infrastructure and software, so auditors commonly treat any principal that authenticates to an in-scope system as covered.

CC6.1 covers logical access security over protected information assets. Its points of focus include managing the asset inventory and managing credentials for infrastructure and software, which is where service accounts sit.

CC6.2 asks you to register and authorize users before issuing credentials, and to remove credentials once access is no longer authorized. CC6.3 asks you to authorize, modify and remove access based on roles, responsibilities or system design.

CC6.6 addresses threats from outside the system boundary. For non-human identities, that typically reaches third-party API credentials and agents calling into your systems.

CC6.8 asks for controls that prevent or detect unauthorized or malicious software. A pipeline account that can deploy code is a direct path for it.

CC7.2 asks you to monitor system components for anomalies. A service account calling an API it has never touched is exactly that kind of anomaly, provided you have a baseline to compare against.

Oak attaches a behavior baseline to each identity it classifies, so that departure has something to be measured against.

What non-human identity audit evidence for SOC 2 contains

Auditors typically pull a sample from your inventory and trace each item through its lifecycle. A passing artifact for each evidence type usually contains the following.

• Inventory: each account, key, token and agent, with system, type, creation date and last use.
• Ownership: a named human or team accountable for the identity, current on the sample date.
• Provisioning approval: a dated request and approval recorded before the credential was issued.
• Access reviews: reviewer, decision, date and the access that was kept or removed.
• Credential rotation: a rotation record that matches the credential the target system accepts.
• Removal at decommission: proof that access was revoked in the target system, with a date.

Oak attaches an owner, a risk level and a compliance posture to each identity it classifies, so those fields exist before the sample is pulled.

SOC 2 Type 2 tests operation across the period, so a sample can land on any month. An identity that was clean in month one and orphaned in month seven is an exception.

The sample pool is large. The 2026 Identity Security Landscape surveyed 2,930 security decision-makers.

It found 109 machine identities per human, and 40% of machine identities have access to organizational data.

Criterion-to-evidence table

The mapping below reflects common audit practice. Auditors typically sample this evidence, though the criteria do not prescribe it.

Ownership runs through every row. Without a named owner, nobody can approve, review or attest for the identity.

Where non-human identities break manager-led evidence

A service account usually has no manager and no HR record. When the engineer who created it leaves, joiner-mover-leaver processes never fire for the account.

The result is an orphaned service account with no owner, reviewer or approver. Your next CC6.3 sample finds a gap that nobody saw coming.

Shared credentials break attribution. When three pipelines and one engineer use the same key, a log entry cannot show who acted.

A vault proves where a secret is stored. It does not show who owns the identity behind it, whether anyone reviewed its access, or whether it was removed.

A rotation logged in the vault means little if the old credential still works downstream.

Inventory gaps sit where connectors never reached. Oak's ConnectAny reaches on-prem and homegrown systems, where service accounts often live outside your IGA's view.

AI agents add a newer gap. An agent running on its builder's credentials reaches everything the builder can, and its actions look like the builder's in the log.

This is why rotation and removal evidence carry weight. The Verizon 2026 DBIR found credential abuse appears somewhere in the attack chain of 39% of breaches.

Where the evidence comes from on one live graph

Judge any platform for this audit on four questions. Does every identity have an owner, is each one reviewed, is removal enforced at the target, and can you export proof on demand?

The owner question also reaches beyond machines. Every identity needs certifying: service accounts, contractors, RPA bots, and AI agents, each tied to an accountable human owner.

Oak resolves a named human or team owner for each machine identity. It attributes every action to its trigger: a person, a script or an agent.

That ownership model sits at the core of AI agent identity governance.

It continuously correlates what every identity can access with what it actually uses, then routes risk-prioritized decisions to the right reviewers. Reviewers see context on every row: last used, peer comparison, sensitivity and an AI recommendation.

Overdue certifications and evidence gaps surface on the platform.

Each AI agent runs continuous reviews driven by its own risk profile. Access is checked against actual usage, and excessive permissions are removed at the source.

Revoke-driven deprovisioning means a revoke decision in a review removes the access in the target system itself. Auditor-ready exports then hand that record to your auditor.

Already running an IGA? The platform connects to the IGA you already run and covers what it cannot reach, such as keys and agents never tied to a person.

Keeping evidence standing, not assembled

Standing evidence is control evidence produced as a by-product of daily operation. It exists on any date an auditor picks.

Your Type 2 sample can fall on any day inside the observation period.

Use this checklist to test whether your evidence is standing.

• The owner field is never empty for an in-scope identity.
• Joiner-mover-leaver (JML) events trigger event-driven micro-certifications, alongside risk-driven and scheduled reviews.
• Rotation is logged in the target system, as well as in the vault.
• Decommission revokes access at the source and records the revocation.

Periodic reviews tell you what happened, never what is happening. Oak remediates from the source the moment an identity deviates.

Reviews, remediation and the access-to-usage correlation all run on one live graph, and Identity Risk Visibility & Intelligence reasons over it continuously, with full context. The record builds as the work happens.

Conclusion

Non-human identity audit evidence for SOC 2 holds up when ownership, review, rotation and removal are recorded as they happen.

For your GRC and IAM teams, a Type 2 sample then lands on a record that already exists. Your team spends the period governing access, with nothing left to assemble at the end.

Get a demo to see your service accounts and AI agents tied to owners and mapped to each criterion.

Frequently asked questions

How does non-human identity audit evidence for SOC 2 differ between Type 1 and Type 2?

Type 1 and Type 2 evidence for non-human identities differs mainly in time. A Type 1 report examines control design at one date, so a current inventory and a written ownership policy often carry it. Type 2 asks whether controls operated, which needs dated reviews and revocations. Oak gives you standing evidence of control, not a quarterly scramble.

Are AI agents in scope for non-human identity audit evidence for SOC 2?

Yes, AI agents are in scope for SOC 2 audit evidence whenever they authenticate to systems inside your boundary. One agent deployed in several places can look like several identities in a sample. Oak correlates those deployments into one identity and maps who each agent acts on behalf of, so one owner is accountable for it.

Do short-lived tokens remove the need for SOC 2 evidence for non-human identities?

No, short-lived tokens do not remove the need for SOC 2 evidence on the identities that use them. They shorten how long a stolen credential works, but the role, trust policy or integration that issues them persists, and that issuer still needs an owner, an approval and a review. Oak flags third-party integrations with standing tokens.

Who signs the access review in SOC 2 evidence for non-human identities?

In practice, auditors commonly look for a named human owner on the access review for each non-human identity they sample. Oak routes each decision to the resolved owner and supports delegation and escalation.

How should shared and break-glass credentials appear in non-human identity audit evidence for SOC 2?

Auditors typically expect shared and break-glass credentials to appear as tightly scoped exceptions, each carrying a named owner and a usage record. Oak handles break-glass through just-in-time access with an audit trail and writes expiry into the target system, so emergency access ends and use is correlated back to the request.