Notifications
Clear all
Topic starter
03/06/2026 2:24 pm
TL;DR: AI is now influencing access decisions inside identity governance tools and also operating as a high-privilege non-human identity across business systems, creating audit, ownership, and control gaps, according to SafePaaS. The decisive issue is not model sophistication but whether identity programmes can explain, constrain, and evidence what AI is allowed to do before it becomes an unmanaged operator.
NHIMG editorial — based on content published by SafePaaS: AI governance and identity control plane patterns
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern AI systems that can both recommend and execute access decisions?
A: Security teams should separate advisory AI from execution AI in policy, then map each AI system to a named owner, scope, and approval path.
Q: Why do AI assistants create extra risk inside identity governance programs?
A: AI assistants can shape reviewer behaviour, prioritise approvals, and normalise excessive entitlements if they are trained on weak historical baselines.
Q: What breaks when an AI identity has production-level privileges but no clear owner?
A: Ownership gaps break incident response, offboarding, and accountability.
Practitioner guidance
- Inventory AI systems as identities List every AI system that can recommend, approve, route, execute, or modify production state.
- Separate recommend from act permissions Define where AI may suggest decisions and where it may execute them, then enforce that boundary in workflows, runbooks, and access policy.
- Fold AI accounts into access reviews Include privileged AI identities in recertification, offboarding, and exception handling.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- How the SafePaaS federated governance model maps policy across IAM, IGA, PAM, and GRC for AI identities.
- Practical examples of where AI is allowed to recommend versus where it is allowed to execute inside enterprise workflows.
- The CISO and CIO checklist used to assess AI ownership, scope, and audit evidence.
- Related guidance for Oracle ERP, SaaS, and shadow AI controls that implementation teams can use after the strategy stage.
👉 Read SafePaaS's analysis of AI identity governance and access control →
AI as identity and inside IGA: what IAM teams need to know?
Explore further
03/06/2026 2:32 pm
AI governance has become an identity governance problem, not a separate AI programme. The article correctly shows that AI can influence access decisions inside IGA and also act as a privileged identity across business systems. That is not a side issue for IAM teams, because ownership, entitlement scope, and evidence requirements all sit inside the identity domain. The implication is that AI risk cannot be managed as a detached policy discussion.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly non-human identity inventories fall behind reality.
A question worth separating out:
Q: How do organisations know whether AI is truly under governance control?
A: They should be able to show where AI is recommend-only, where it can act, who owns each AI identity, what evidence is logged, and how access is revoked. If those answers live in different tools or are informal knowledge, the programme does not yet have defensible control over AI.
👉 Read our full editorial: AI identity governance is becoming the control plane for operations
