Who should retain responsibility when AI assists access certification?

Why Human Ownership Must Stay With Access Certification

AI can make access certification faster, but speed does not remove accountability. Human reviewers still need to own high-risk decisions because they can weigh business context, exception history, and downstream impact in a way automation cannot. That matters most for privileged accounts, service identities, and entitlements tied to production systems. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG research on Ultimate Guide to NHIs — Key Challenges and Risks both point to the same issue: machine identities fail when ownership becomes vague.

The practical question is not whether AI should assist, but whether a named person can explain and defend each approval. If the answer is no, the review process has drifted into automation without governance. That weakens auditability, especially when access decisions affect non-human identities, API credentials, or other secrets that can be reused far beyond the original business case. In practice, many security teams discover that accountability gaps are already embedded in access review workflows only after a privileged entitlement has been over-approved.

How Human Review and AI Assistance Should Be Split

Current guidance suggests a division of labour: AI should surface anomalies, duplicate memberships, stale entitlements, and risky privilege combinations, while humans should approve, reject, or require mitigation for material changes. This is especially important when reviewing NHI access, because workload identities, service accounts, and automation tokens often behave differently from employee accounts. The Ultimate Guide to NHIs is useful here because it frames these identities as operational assets that still require governance, not just credentials to be inventoried.

• Use AI to cluster similar entitlements, flag unusual privilege growth, and highlight dormant access.
• Require a human reviewer to confirm business justification for privileged, sensitive, or production-linked access.
• Record the approver, rationale, evidence used, and any compensating controls for each exception.
• Keep review outcomes tied to the actual identity type, including NHIs, bots, agents, and secrets-backed integrations.

For implementation, align the process to OWASP Non-Human Identity Top 10 and treat AI output as decision support, not decision authority. Where possible, connect certification to authoritative sources such as IAM, PAM, CMDB, and secrets inventory so reviewers can verify what the entitlement actually does. That is especially important when the same service identity is reused across environments or when ownership records are incomplete. These controls tend to break down when access data is fragmented across multiple directories and ticketing systems because reviewers cannot reliably tell which entitlement is current, necessary, or already replaced.

Where This Guidance Gets Harder to Apply

Tighter review controls often increase operational overhead, requiring organisations to balance review quality against time, staffing, and change velocity. The tradeoff is sharper in environments with many machine identities, temporary workloads, and frequent deployments, because the access graph changes faster than manual certification cycles. In those cases, best practice is evolving toward risk-based review: AI handles low-risk, repetitive attestations, while humans focus on privileged roles, sensitive secrets, and anything tied to production impact. NHIMG’s analysis of 52 NHI Breaches Analysis shows why that focus matters, and the DeepSeek breach reinforces how exposed credentials and weak governance can turn routine access into broad exposure.

There is no universal standard for this yet, but the safest pattern is consistent: AI proposes, humans decide, and the organisation keeps an evidence trail that survives audit and incident review. That approach matters even more when access certification intersects with autonomous agents, shared service accounts, or secrets that can be copied and reused outside the intended workflow.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams stop employees from bypassing governed AI access?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?