Most CISOs and security pros have gone through an audit that was more like an archaeology dig than a review. A service account somewhere is still active, holding read access to a customer data warehouse, provisioned by someone who left the company years before anyone currently on the team was hired. Nobody remembers why it exists. Nobody's quite brave enough to delete it and see what breaks. More often than not, whoever finally investigates spends a week confirming the account is doing nothing at all, and has been doing nothing for years, quietly holding the keys to a room nobody's using anymore.
That's IAM in a nutshell for most enterprises. Not broken, exactly. Just accumulating, the way junk drawers accumulate, one reasonable decision at a time until nobody can explain the whole picture anymore.
Key takeaways:
- IAM tells you what permissions are assigned, not what sensitive data is actually reachable through those permissions, including indirectly, through multi-hop pipelines.
- Ghost agents (dormant AI agents left running after a project loses momentum) are a distinct risk category because nobody is actively monitoring them the way they would a human account.
- Roughly 97% of non-human identities carry excessive privileges, according to Entro Security's 2025 research, a pattern OWASP's Agentic Top 10 also flags as a root cause of agentic risk.
- Lineage-aware access mapping traces a full path from identity to entitlement to actual sensitive data, catching exposure that a hop-by-hop IAM review misses entirely.
- Quarterly access reviews can't keep pace with agents that get deployed and connected to new data sources on sprint timelines.
The permission list was never the point
Here's the thing IAM was actually built to do; answer the question "Does this identity have Read on this resource?" That's a genuinely useful question, and traditional access management has gotten quite good at answering it. But notice what it doesn't tell you. It doesn't tell you what's actually inside the thing being read. It doesn't tell you whether that S3 bucket contains cafeteria menus or customer social security numbers. IAM was built by people modeling permissions, not by people modeling sensitivity, and for a long time that was a totally reasonable division of labor, because a human being with Read access still had to go looking for something interesting before it became a problem.
An AI agent doesn't go looking. It's already there. Give a copilot or an autonomous agent the same Read permission a human employee has, and it will summarize, cross-reference, and surface everything reachable through that permission in about the time it takes you to read this sentence. The permission list hasn't changed. What changed is the speed and reach of the thing exercising it, and that's the part traditional IAM tooling was never asked to account for.
This is exactly the kind of "know what AI can actually reach" question that shows up across the broader AI data readiness conversation, and honestly, IAM is where it gets most concrete, because permissions are the literal mechanism agents inherit.
Ghost agents are the dormant backdoors nobody's watching
Take that same pattern and multiply it by every AI pilot project your organization has spun up in the last eighteen months. A data science team stands up an agent to automate a reporting task, connects it to three or four data sources to get the proof of concept working, the project quietly loses momentum around month two, and the agent never gets decommissioned. It's not doing anything malicious. It's just sitting there, still authenticated, still holding whatever access it was granted, waiting for someone (or something) to notice it exists.
I call these ghost agents, and they're a genuinely different risk category than an over-permissioned human account, for one simple reason. Nobody is checking their email, going on vacation, or getting a performance review that prompts an access recertification. A dormant service identity with live credentials is a backdoor that was never built with malicious intent, which somehow makes it worse, because nobody's actively defending it either.
According to Entro Security's 2025 research, 97% of non-human identities carry excessive privileges, and OWASP's Top 10 for Agentic Applications 2026 explicitly maps these over-privileged, invisible non-human identities as root causes underneath agentic risk categories like identity and privilege abuse. That's not a coincidence. It's the same underlying pattern showing up in every serious framework looking at this problem from a different angle.
What lineage actually adds to the picture
So if the permission list isn't enough, what is? The piece that's usually missing is lineage; the ability to trace a path from an identity, through the entitlements it holds, all the way to the actual sensitive data at the end of that path, in context.
Say you've got data flowing from Snowflake into Databricks for transformation, and from there into an S3 bucket that feeds a Bedrock knowledge base powering a customer-facing agent. A traditional IAM review looks at each hop independently: does this role have access to Snowflake?, yes; Does this role have access to Databricks?, yes; Does this role have access to S3?, yes. Three green checkmarks, all technically accurate, all missing the important question; Can this agent, at the end of that chain, ultimately reach a specific customer's financial records? Access follows data, not the other way around, and that's exactly the piece traditional entitlement reviews don't capture, because they were designed to check boxes at each hop rather than trace the whole path.
Lineage-aware access mapping connects entitlements, business context, and data sensitivity into one continuous picture, so instead of "this role can read this bucket," you get "this AI agent can currently reach unencrypted customer PII three hops upstream of where anyone thought to look." One of those statements is useful for a compliance checkbox. The other one is useful for reducing risk, and if you've ever sat through an access review that produced the first kind of statement and called it a day, you know exactly the gap I'm describing.
A quick myth-versus-reality gut check
The assumption | The reality |
|---|---|
"We know who has access because IAM says so." | IAM tells you what's assigned, not what's actually reachable through inherited or chained access. |
"If nobody's using an old service account, it's harmless." | Dormant, unreviewed credentials are exactly what ghost agents run on. Nobody's watching them precisely because nobody's using them. |
"Our AI agents only have the access we explicitly gave them." | Agents often inherit the full access footprint of the identity or service principal they run under, which is frequently broader than the task requires. |
"A quarterly access review catches this." | New agents get deployed and connected to data sources on sprint timelines, not quarterly ones. |
The math on this is genuinely stark: OWASP's 2026 research notes that a small fraction of machine identities, roughly one-hundredth of one percent by some estimates, end up controlling the majority of cloud resource access in a typical enterprise. That's not a rounding error. That's a structural imbalance that's been quietly building for years, and AI agents are the first thing forcing anyone to actually look at it.
Where to actually start
If you're reading this and thinking "great, now I'm worried, what do I do Monday morning," here's the honest answer. You don't fix this by buying a bigger IAM tool. IAM is doing its job. What you need sits on top of it, mapping every human and AI identity to the sensitive data it can actually reach, with the business context and lineage to tell the difference between "technically has access" and "represents real exposure." Start by finding your ghost agents. They're the cheapest win in the room, and they've been sitting there the whole time, waiting for someone to finally clean out the drawer.
If you want to see what that actually looks like against your own environment, rather than in the abstract, Sentra maps every identity, human and machine, to the sensitive data it can reach, lineage included, which tends to be an uncomfortable, but useful first conversation.
