Your Access Review Is Missing 90% of Your Identities

Your Access Review Is Missing 90% of Your Identities

You can't sign off on controls for identities you don't count. And most audit populations still only count people.

I was reviewing an access certification report last month for a mid-sized financial services client. Clean columns. Proper attestations. Every employee accounted for. The CISO was ready to sign off. Then I asked a simple question: "How many service accounts does this environment actually have?"

Silence. Then: "We'd have to check with IT."

The access review covered 847 human identities. The actual environment contained over 9,000 active credentials. The remaining 8,000+ were service accounts, API keys, automation scripts, and—increasingly—AI agents. All with permissions. All taking action. None of them in the audit population.

That gap isn't an IT problem anymore. It's a governance crisis hiding in plain sight.

The Audit Population Lag Cycle

Here's a pattern I've watched repeat itself three times in twenty years: operational reality changes first, then the tooling catches up, then the governance frameworks update, and finally the audit populations expand. That cycle takes 4-7 years. And during that lag, you're certifying a subset while the unmanaged majority carries the risk.

I call it the Audit Population Lag Cycle, and we're in the middle of turn three.

Turn one was shadow IT. I started doing cloud security work in 2012. Back then, access reviews listed on-premises domain accounts. Meanwhile, marketing was spinning up Salesforce instances. Finance had Box accounts. Sales was running HubSpot. Each one provisioning users, storing data, processing transactions—all outside the enterprise identity system.

Nobody was lying. The audit just didn't have language for what was actually happening. By the time governance frameworks adapted—by the time "SaaS management" became a product category—the average enterprise was already managing hundreds of cloud applications.

Turn two was cloud infrastructure. AWS launched in 2006. By 2015, engineering teams were provisioning IAM roles, security groups, and programmatic access faster than central IT could inventory them. Access reviews still listed Active Directory accounts while developers deployed Lambda functions with admin privileges. The gap between "certified access" and "actual access" stretched to years.

Turn three is AI agents. And this one's moving faster because the identities themselves are autonomous.

A service account runs a script someone wrote. An AI agent makes decisions in real time based on context. It reads your email. It interprets intent. It queries your ERP system and drafts a response. That's not a batch job. That's an actor—and you're about to certify that your access controls are operating effectively without mentioning it once.

The Madrid Signal

A small European startup called 8Layers just raised $2.9 million. Modest funding round. You've probably never heard of them. The money isn't the story.

The product is.

Their platform inventories four things as one population: human users, service accounts, APIs, and AI identities. An identity-security vendor, and the investors backing it, just put your employees and your AI agents in the same governance bucket.

That's the tell. When venture capital starts funding the tooling for a problem, the market has already moved. The question isn't whether non-human identities matter—it's whether your audit framework has caught up.

And here's the insight most people miss: we're now at the tooling stage of the Lag Cycle. That means governance frameworks will update in 18-24 months. External auditors will start asking questions 12 months after that. You have maybe two years before "we only count human identities" becomes an audit finding instead of an industry norm.

What We're Not Counting

When I say "non-human identity," I'm not talking about theoretical risk. I'm talking about credentials that are logging in, executing transactions, and moving data right now:

• Service accounts that run batch jobs, often with elevated privileges and passwords that haven't rotated in years

• API keys embedded in applications, granting programmatic access to databases, cloud storage, payment systems

• Automation scripts that provision infrastructure, deploy code, modify configurations—often with admin rights

• AI agents that read email, draft responses, query databases, update CRM records, and increasingly make decisions without human review

In every environment I've assessed in the past two years, machine identities outnumber human identities by at least ten to one. In cloud-native organizations, that ratio climbs to thirty or forty to one.

And in every single access review, the audit population lists employees.

As if the bots don't have keys.

The Control Population Mismatch

Here's the uncomfortable part, and I'm going to frame it in language auditors use.

Your SOC 2 report describes a control: "Management performs quarterly access reviews to ensure users have appropriate access to systems and data." The control objective is clear. The operating effectiveness is tested. The auditor signs off.

But the control population and the risk population don't match.

The control population is 847 human identities. The risk population is 9,000 active credentials. You've designed and tested a control that governs 9% of the access in your environment, and you've attested that access governance is operating effectively.

That's not a control deficiency. That's a scoping failure. And scoping failures are worse because they're not about whether you're doing the control right—they're about whether you're doing the right control at all.

I watched this exact scenario play out during an external audit last year. The auditor asked for the access review. The client provided it—847 users, all certified. Then the auditor asked to see the service account inventory. Long pause. IT eventually produced a spreadsheet with 200 accounts. The auditor asked how they knew it was complete. Another long pause.

The audit finding wasn't that controls were weak. It was that the control population was undefined. You can't test the operating effectiveness of a control when you don't know what's in scope.

The Autonomy Threshold

Machine identities have been around for decades. Service accounts aren't new. APIs aren't new. So why does this matter now?

Because AI agents crossed the autonomy threshold in 2024.

Here's what I mean by that. Traditional automation follows explicit rules: IF condition, THEN action. A service account runs backup.sh every night at 2am because someone wrote a cron job. The decision tree is deterministic. You can audit it by reading the script.

AI agents don't work that way. They receive objectives, not instructions. "Respond to customer support emails." "Summarize this sales call and update Salesforce." "Review these expense reports and flag anomalies."

The agent has API credentials. It has access to your email, your CRM, your financial systems. And it interprets context to decide what action to take. You can't audit an AI agent by reading a script because there is no script. The decision logic is a trained model responding to real-time inputs.

That's the autonomy threshold: the point where machine identities stop executing predefined workflows and start making contextual decisions.

And once you cross that threshold, the distinction between "user" and "service account" collapses. An AI agent with API access to your financial systems is functionally indistinguishable from an employee—except it's not in your access review, it's not covered by your offboarding process, and it's probably not logging actions in a way your SIEM can parse.

Why Regulators Will Ask Before You're Ready

The SEC's 2024 cybersecurity disclosure rules require material incident reporting. The EU's Digital Operational Resilience Act (DORA) mandates ICT risk management, including identity and access controls.

Neither regulation explicitly mentions "AI agents" or "non-human identities." They don't have to.

Both frameworks require organizations to identify and manage access to critical systems. When the next breach happens because an exposed API key gave an attacker access to your payment processor, the regulatory question won't be "did you manage your human users?" It'll be "did you have a control framework for all credentials with access to material systems?"

And if your answer is "we didn't count those," you've just documented a control gap in your regulatory filing.

We're entering the window where early auditors start asking the question. Not because the regulations explicitly mandate it yet, but because the risk is material and the tooling exists. That's how new audit standards emerge—not through formal guidance updates, but through case-by-case auditor judgment that gradually becomes industry practice.

You have maybe 18 months before this shifts from "progressive auditor asks tough question" to "standard audit procedure expects documentation."

The One Question You Need to Ask Monday Morning

Pull your last access review. Open the spreadsheet. Count the rows that represent human users.

Now ask your infrastructure team: How many active credentials exist in this environment?

The gap between those two numbers is your unmanaged attack surface. And it's the number the auditor is going to circle.

If you don't have an answer, you're not alone. Most organizations don't. But that's changing fast. The tooling exists now—8Layers isn't the only vendor in this space, just the most recent signal that the market has moved. CyberArk, HashiCorp, and others have been building machine identity management for years.

The question isn't whether the tools are available. It's whether you understand where you are in the Audit Population Lag Cycle.

What to Do (Specifically)

If you're responsible for access governance, internal audit, or compliance:

1. Inventory non-human identities as a separate population. Don't bolt it onto your employee access review. It's a different control, different risk profile, different ownership model. Treat it like you treated SaaS management in 2014—a net-new control category that requires its own framework.

2. Define ownership for machine identities the way you define it for humans. Every service account, API key, and AI agent should have a technical owner and a business owner. If it doesn't, it's orphaned—and orphaned credentials are the ones that never get deprovisioned.

3. Add non-human identity to your next SOC 2 or ISO scope conversation. Ask your auditor explicitly: Does our user access review control cover machine and AI identities, or just employees? If the answer is "just employees," that's a scoping gap, not a control deficiency—but it needs to be on the remediation roadmap.

4. Test one use case. Pick one AI agent or service account with sensitive access. Map it to a business process. Identify the owner. Document the access. Run a mini access review on just that one identity. See where the process breaks. That's your blueprint for scaling.

You don't need to solve this in Q1. But you need to count the problem. Because the next external audit is going to ask, and "we're working on it" only works once.

The Uncomfortable Truth

We spent the last twenty years perfecting human identity governance. Joiners, movers, leavers. Role-based access control. Privileged access management. Certification workflows. We built entire frameworks around the assumption that identities are people.

And then we automated everything.

The machines didn't wait for the governance model to catch up. They never do. They multiplied quietly in the background while we certified spreadsheets that listed employees.

The Audit Population Lag Cycle always ends the same way: the organization that moves early defines the standard. The organization that waits adopts someone else's framework under audit pressure.

You've done this before. You adapted when cloud broke the perimeter. You adapted when SaaS exploded the application portfolio. You'll adapt to this.

But adaptation starts with counting. And right now, most organizations aren't counting.

So pull that access review. Count the rows. Ask the infrastructure team for the real number. And calculate the gap.

That gap is what you're going to explain to the auditor in 2026. Start explaining it to yourself now.