TL;DR: AI adoption is already outpacing visibility, and the real governance gap is no longer who has access but whether each AI action should be allowed in context, according to Saviynt. Static identity controls cannot govern systems that interpret context, chain actions, and change behaviour at runtime.
NHIMG editorial — based on content published by Saviynt: The CISO Balancing Act: You Can’t Secure What You Refuse to Enable
Questions worth separating out
Q: How should security teams govern AI agents that can change actions at runtime?
A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path.
Q: Why do shadow AI tools create identity governance risk?
A: Shadow AI is risky because users often reach those tools through identities, browser sessions, or tokens that were never assessed for data handling or access scope.
Q: What breaks when organisations rely on periodic access reviews for AI systems?
A: Periodic access reviews break when the identity scope changes between review cycles.
Practitioner guidance
- Inventory every AI system as an identity Map copilots, agents, AI-enabled applications, and vendor-provided AI features into a single identity inventory with an owner, purpose, data scope, and approval path.
- Move approvals to the action layer Define which AI actions require contextual approval, which can proceed under policy, and which must be blocked based on data sensitivity, downstream systems, and business purpose.
- Attach lifecycle controls to short-lived AI identities Require creation, review, and retirement records for AI identities that may only exist for minutes or hours, and make offboarding part of the release process.
What's in the full article
Saviynt's full blog post covers the operational detail this post intentionally leaves for the source:
- Examples of how the vendor frames AI identity governance across visibility, runtime decision-making, and lifecycle control.
- Additional commentary on how CISOs can balance AI enablement with security oversight in active programmes.
- The article's broader product-adjacent perspective on continuous authorisation and identity as the control plane for AI.
- The source also includes links to related Saviynt materials on AI-driven identity security and AI agent governance.
👉 Read Saviynt's analysis of AI identity governance and shadow AI risk →
AI agents and shadow AI: what it means for IAM teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
AI identity governance is now an action problem, not an access problem. The article correctly separates identity possession from identity behaviour. A system that can chain actions across applications forces security teams to govern the act itself, not just the account behind it. That shifts the centre of gravity from entitlement reviews to runtime policy, and it means IAM programmes must decide whether they are governing access or governing execution.
A few things that frame the scale:
- AI identities must be governed from creation through retirement, even when they exist for only hours, minutes, or seconds, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who should be accountable for AI identity governance?
A: Accountability should sit with the team that owns the workflow and the team that owns identity controls, because AI access crosses both domains. Security, platform, and application owners each hold part of the lifecycle, but one business owner must remain responsible for the access decision and its removal.
👉 Read our full editorial: AI identity governance is shifting from access to action