Why do AI access recommendations fail when identity data is poor?

Why This Matters for Security Teams

Identity-driven access recommendations are only as reliable as the data underneath them. When HR attributes, job codes, app ownership, service account inventories, or usage telemetry are stale, the recommendation engine does not just become less accurate. It can reinforce the wrong access baseline and hide toxic combinations that never should have been accepted in the first place. That is why poor identity hygiene is not a data quality nuisance, but an access control failure.

This issue shows up often in environments that use recommendations to accelerate access reviews, role mining, or least-privilege cleanup. The model may correctly identify patterns from incomplete evidence, then confidently normalize those patterns across the enterprise. NHI Management Group has documented how identity weaknesses and exposed secrets create real-world attack paths in Top 10 NHI Issues and in the broader Ultimate Guide to NHIs. The same principle applies to human and non-human identity data alike: bad source records produce bad access decisions. As OWASP notes in the OWASP Non-Human Identity Top 10, identity exposure and governance gaps quickly become security exposure.

In practice, many security teams discover the bad recommendation only after access creep has already spread across production systems.

How It Works in Practice

Access recommendation engines usually combine identity attributes, entitlements, peer group membership, and activity history to infer what a user or workload should have. If any of those inputs are stale, the output becomes biased toward whatever is easiest to observe. A user who changed teams but never had their HR record updated may be mapped to the old role. A service account with missing owner metadata may be grouped with a broader technical cohort and granted access that was only appropriate for one system. In both cases, the recommender is not “wrong” by its own logic. It is faithfully reproducing a broken identity graph.

The practical fix is to treat identity data quality as a control plane issue, not a reporting issue. That means:

• Synchronise HR, IAM, PAM, and application ownership data so role and entitlement decisions share a current source of truth.
• Separate human, workload, and service identities so recommendation logic does not blend distinct risk profiles.
• Validate recommendations against actual authorisation requirements instead of historical usage alone.
• Flag stale accounts, orphaned entitlements, and missing lineage as blockers for automated approval.

Where workload identities are involved, cryptographic proof matters more than inferred trust. Standards such as SPIFFE help establish workload identity that can be verified at runtime, rather than guessed from naming conventions or ticket history. That aligns with the broader warning in 52 NHI Breaches Analysis: when identity records drift from operational reality, attackers exploit the gap faster than governance teams can reconcile it. These controls tend to break down in large hybrid environments because attribute sync latency and shadow IT create multiple competing versions of identity truth.

Common Variations and Edge Cases

Tighter recommendation controls often increase operational overhead, requiring organisations to balance automation speed against data stewardship and review burden. That tradeoff becomes visible in environments where entitlements are inherited through nested groups, contractor status changes frequently, or application owners are not consistently assigned. In those cases, recommendation engines may still be useful, but current guidance suggests they should be treated as decision support, not an approval authority.

There is no universal standard for how much identity data must be complete before recommendations are trusted. Best practice is evolving toward risk-based thresholds: high-risk systems require more complete identity lineage, stronger approval gates, and more frequent recertification. For non-human identities, the bar is often higher because secrets, tokens, and API keys can be reused automatically once misclassified. The State of Secrets in AppSec research shows how fragmented secrets practices undermine control, which is exactly the kind of downstream weakness poor identity data can hide. For teams building governance around this problem, the OWASP Non-Human Identity Top 10 remains a useful reference point for where identity-driven assumptions fail.

In practice, recommendation systems break down fastest when organisations merge stale HR data, inherited permissions, and unmanaged service accounts into one shared model.

Related resources from NHI Mgmt Group

• Why do local AI agents complicate identity and access management?
• When is it crucial to implement least-privilege access for AI agents?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?