Lineage-aware IAM is exposing ghost agents and hidden data reach

At a glance

What this is: This is an analysis of lineage-aware IAM, showing that permission checks alone miss the sensitive data reachable through chained access paths and dormant non-human identities.

Why it matters: IAM and identity teams need lineage, not just entitlements, because AI agents and stale service accounts can turn approved access into real exposure across data pipelines.

Context

Traditional IAM tells you whether an identity has access to a resource, but it does not show what sensitive data becomes reachable through chained permissions, multi-hop pipelines, or delegated non-human access. That gap matters more as AI agents inherit the same identities and permissions that human operators once used.

The problem is governance, not just tooling. Quarterly access reviews and hop-by-hop entitlement checks can miss dormant service accounts and ghost agents that remain authenticated long after their original purpose has faded. In a lineage-aware model, the control question shifts from assigned access to actual data reach.

Key questions

Q: What breaks when IAM only reviews permissions and not data reachability?

A: Teams can approve a role or service account while still missing the sensitive data it can reach through pipelines, inheritance, or downstream systems. That creates false confidence, because the entitlement looks legitimate even when the actual exposure is broader than the business use case. Reachability, not permission alone, is the governance boundary that matters.

Q: Why do dormant service accounts and ghost agents create governance risk?

A: Because they often remain authenticated long after the original business need has ended, and nobody is actively watching them. If their credentials and downstream access are still live, they can preserve exposure even when the project that created them no longer exists.

Q: How can security teams tell whether an identity review is actually meaningful?

A: A meaningful review proves what data the identity can reach, not just which roles or policies are attached to it. If the review cannot trace the end-to-end path from identity to sensitive dataset, it is only certifying permissions, not exposure.

Q: What is the difference between assigned access and actual data reach?

A: Assigned access is the permission recorded in IAM. Actual data reach is the sensitive information that becomes accessible once those permissions move through transformations, storage layers, and downstream applications, especially when an AI agent can exploit that reach instantly.

Technical breakdown

Why permission checks miss sensitive data reach

Traditional IAM is designed to answer whether an identity can read a resource, not whether the resource contains sensitive information or can be chained into broader exposure. That model works when a human still has to search, interpret, and act on what they can read. It breaks when an AI agent can immediately summarise, cross-reference, and surface everything reachable through the same permission set. The result is a structural blind spot: assigned access can look acceptable while the reachable data path is not. Lineage-aware access mapping closes that gap by tracing identity to entitlement to sensitive data in context.

Practical implication: map identities to reachable data paths, not just to assigned permissions.

How ghost agents become persistent exposure paths

Ghost agents are dormant AI or service identities that remain active after a pilot, workflow, or project loses momentum. They are different from ordinary stale accounts because nobody is checking their activity, reviewing their business purpose, or triggering offboarding when they stop mattering. If their credentials stay live, they keep whatever access they were granted, and in many environments that access is broader than the task ever required. The governance failure is not malicious use, but uncontrolled persistence of authenticated machine access. That makes them easy to overlook and hard to justify during audit.

Practical implication: inventory and retire dormant non-human identities before they become invisible standing access.

Why lineage-aware mapping changes the control model

Lineage-aware access mapping connects the full path from identity to entitlement to the sensitive data at the end of the chain. In practical terms, it can show that an AI agent reaches regulated customer records through Snowflake, Databricks, and S3 even when each hop looks acceptable in isolation. That is a different control model from classic recertification, which certifies each permission slice separately and misses the cumulative effect. The key shift is from checking whether access exists to proving where that access can land. Without lineage, compliance and risk reviews both understate exposure.

Practical implication: evaluate the end-to-end data path before treating any access review as complete.

Threat narrative

Attacker objective: The objective is to exploit unused but still-live non-human access to reach sensitive data paths that ordinary IAM reviews do not expose.

1. Entry occurs when a dormant service identity or AI agent remains authenticated after its original project or owner has disappeared from active oversight.
2. Credential or access exposure persists because the identity keeps inherited permissions across multiple systems and data stores.
3. Impact occurs when the identity can still reach sensitive data through chained pipelines, even though no one is actively monitoring the account.

Breaches seen in the wild

• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.
• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Permission inventories are not exposure inventories: IAM can verify entitlement assignment, but it cannot prove what sensitive data those entitlements ultimately reach. That distinction becomes decisive when access moves through warehouses, transformation layers, and downstream knowledge systems. The industry still treats hop-by-hop approval as if it were end-to-end safety, and that assumption is now out of date. Practitioners need to separate assigned access from reachable exposure.

Ghost agents are a lifecycle failure, not just a dormant-account problem: A non-human identity that stays live after the project ends is not harmless simply because nobody uses it daily. The real issue is that machine identities do not self-retire, self-justify, or trigger human-style review events. That leaves dormant access sitting outside normal recertification rhythm, which is exactly why it survives. Lifecycle governance for NHIs has to treat inactivity as a signal, not a reassurance.

Lineage-aware access mapping is the missing control plane: The article points to a more precise control model where identity, entitlement, business context, and data sensitivity are evaluated together. That is materially different from classic access reviews, which were built to certify lists rather than trace consequences. In a world of AI agents and multi-hop pipelines, the governance question is no longer who has access, but what data that access can actually reach. That is the practical standard teams now have to adopt.

Overprivilege becomes more dangerous when agents inherit it at machine speed: The same excessive privileges that were tolerable in a human-paced environment become far more consequential when an agent can enumerate and combine reachable data instantly. This is why agentic risk cannot be evaluated only as a variant of human IAM. The control failure sits at the point where inherited access meets broad data reach, and that is where practitioners should focus review and containment effort.

OWASP-NHI and agentic risk now overlap in the same governance gap: Overprivileged non-human identities are no longer only a machine-account hygiene issue. They are a structural exposure path for agentic systems that inherit broad privileges and then expand their reach through workflow and data connectivity. That makes lineage, offboarding, and entitlement scope inseparable from AI agent governance. Teams should treat agent access as a data-reach problem, not just an identity-record problem.

What this signals

Ghost agent governance is now a lifecycle problem: Organisations that treat dormant non-human identities as low priority will keep carrying hidden exposure across projects, data platforms, and AI pilots. The operational shift is to make offboarding and discovery continuous, because machine identities do not age out on their own.

Lineage, not recertification, is the control that reveals reach: Quarterly access reviews can still be useful for entitlement hygiene, but they do not explain what sensitive data an identity can reach through chained systems. Practitioners should therefore treat lineage-aware mapping as a separate governance layer, not a refinement of the existing review cycle.

For practitioners

• Map identity to reachable data Trace each human, service, and AI identity from authentication point to the sensitive datasets it can actually reach through chained systems and pipelines.
• Retire ghost agents promptly Find dormant non-human identities that remain authenticated after projects end, then remove credentials and downstream connections before they become silent standing access.
• Review multi-hop access paths Test the full Snowflake, transformation, and storage path rather than certifying each hop independently, because exposure often appears only when the chain is traced end to end.
• Separate reach from permission Treat a clean permission list as incomplete until you can show which regulated or customer data the identity can reach in practice, including indirect paths.

Key takeaways

• IAM can confirm permissions, but it does not show the sensitive data those permissions can reach across chained systems.
• Dormant non-human identities become hidden exposure paths when their credentials stay live after the original project has faded.
• Practitioners need lineage-aware access mapping to distinguish nominal access from real data reach and retire ghost agents before they accumulate.

Key terms

• Lineage-Aware Access Mapping: A governance method that traces an identity from its entitlement to the actual sensitive data it can reach through downstream systems. It moves beyond permission lists and shows the real exposure path, which is essential when service accounts and AI agents inherit access across multiple hops.
• Shadow Agent: An AI agent deployed without formal registration, identity governance, or security oversight, the agentic equivalent of shadow IT. Shadow agents are more dangerous than typical shadow NHIs because they actively take actions using their credentials.
• Data reach: The sensitive information an identity can actually access once direct and indirect permissions are followed through connected systems. It is a stronger governance measure than assigned access because it captures the practical result of entitlement chains, not just the policy record.
• Entitlement chain: The sequence of permissions an identity accumulates across systems, storage layers, and applications. Each step may look acceptable on its own, but together they can create a much broader exposure surface than any single review would reveal.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.