Who should remain accountable when AI recommends access roles?

Why This Matters for Security Teams

When AI recommends access roles, the technical recommendation may be fast, but the accountability question is not. Role assignment affects segregation of duties, auditability, regulatory exposure, and the blast radius of mistakes. The practical risk is not that AI is “wrong” in a narrow sense. It is that an organisation may treat a suggestion as an authority decision and lose the human ownership required for risk acceptance, exception handling, and policy enforcement. The OWASP Non-Human Identity Top 10 frames this as an identity governance problem, not a model output problem.

NHIMG research shows how quickly secrets and access assumptions can become operational risk: in The State of Secrets in AppSec, the average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities. That mismatch matters here because AI-assisted access decisions can amplify confidence faster than governance can catch up. In practice, many security teams encounter role creep only after a review cycle, an audit finding, or a privilege misuse incident, rather than through intentional design.

How It Works in Practice

The cleanest operating model is simple: AI can recommend, but identity governance must approve. That means the access model, policy thresholds, exception process, and final risk acceptance remain with the team that owns the control environment. AI is most useful as a decision support layer that ranks entitlements, flags anomalies, and summarises request context. It should not be the system of record for approval authority.

In practice, this works best when access decisions are tied to explicit policy rules and human-owned workflows. Current guidance suggests using AI to reduce manual review volume, then applying human judgment to the cases that carry business risk, compliance implications, or unclear context. Where possible, pair recommendations with evidence such as job function, resource sensitivity, prior access history, and expiration date. That makes the review explainable and auditable.

• Keep policy definitions in the IAM or GRC control plane, not in the model prompt.
• Use AI to suggest least-privilege roles, not to auto-grant standing access.
• Require a human approver for exceptions, high-risk roles, and privileged access.
• Log the recommendation, the approver, and the rationale in a tamper-evident audit trail.

For non-human identities, this is even more important because access is often machine-speed and short-lived. NHIMG’s Ultimate Guide to NHIs emphasises that governance must track who owns the identity, who approves access, and who can revoke it when conditions change. If an organisation uses AI to recommend access roles without a named human owner, accountability dissolves into the workflow. These controls tend to break down when access decisions are embedded into fast-moving automation pipelines because approval context disappears before reviewers can validate the risk.

Common Variations and Edge Cases

Tighter AI-assisted access review often increases review overhead, requiring organisations to balance speed against control strength. That tradeoff becomes more visible in environments with high change volume, shared service accounts, or delegated administration. In those cases, best practice is evolving rather than settled: some teams allow AI to pre-classify requests, while others restrict AI to post-hoc analysis only.

Edge cases also arise when the AI is embedded in an identity platform, ticketing system, or access request portal. The platform may present the recommendation as if it were the approved answer. That is an interface risk, not a governance exception. Human approvers still need the ability to override the model, reject a suggestion, and document why. For privileged roles, the bar should be even higher, with explicit business justification and time-bound access.

NHIMG’s 52 NHI Breaches Analysis is a useful reminder that access failures are usually process failures first and technology failures second. The right pattern is to let AI compress analysis, while keeping accountability anchored to the organisation that owns the access policy, the audit evidence, and the final risk decision.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams govern human, NHI, and AI-assisted access in one programme?
• Who is accountable when a non-human identity keeps unnecessary Azure access?
• How should security teams run access reviews for non-human identities?