AI governance needs identity-first controls, not shadow decisions

At a glance

What this is: This session argues that AI governance fails when shadow decisions happen outside identity controls, and that verification of user, device, and context must come first.

Why it matters: For IAM, IGA, PAM, and NHI teams, the lesson is that AI access cannot be governed as a separate exception path, because the same control plane must decide who or what can reach data and prompts.

Context

AI governance fails when users can make business decisions or expose data in tools that sit outside identity controls. In practice, that means the organisation loses visibility over who acted, from which device, under which policy, and with what data.

JumpCloud frames the problem as “shadow decisions”, which is broader than shadow IT because the risk is not only unapproved software. The governance gap appears when agentic or conversational AI can influence outcomes before IAM, device trust, or data controls have a chance to intervene.

For regulated environments, that gap becomes a compliance issue as well as a security issue. The article’s core point is that identity-first control is the foundation for safe AI adoption, not an add-on after deployment.

Key questions

Q: How should security teams govern AI models that can call tools and access data?

A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization. The critical shift is to treat every tool call, data read, and update path as a privileged action that can be logged, revalidated, and revoked. Without that discipline, model risk becomes identity risk.

Q: Why is shadow AI harder to manage than ordinary shadow IT?

A: Shadow AI is harder because the tools can process sensitive content as part of normal use, which creates both data exposure and compliance risk. Traditional SaaS oversight often tracks application presence, but AI governance must also account for how data is entered, stored, and audited.

Q: What breaks when AI prompts are outside the identity control plane?

A: When prompts sit outside the identity control plane, governance loses the ability to confirm who requested access, from which device, and under what conditions. The result is untraceable data handling, weak accountability, and a growing gap between policy and actual AI use.

Q: Should organisations prioritise identity controls or SOC automation first for AI threats?

A: Prioritise the control that closes the fastest path to misuse in your environment. If AI attacks are landing through identity abuse, improve authentication, privilege restriction, and session containment first, then use SOC automation to speed triage and response. The two work best together, but identity containment usually comes first.

Technical breakdown

Why shadow decisions break identity governance

Shadow decisions occur when a user or workflow uses AI to process, summarise, or act on sensitive information outside the organisation’s approved identity and access path. The control failure is not the model alone. It is the loss of policy enforcement at the moment data is selected, transformed, or disclosed. Traditional IAM assumes the system can see the actor, the device, and the request before access is granted. AI tools blur that sequence by creating an interaction space where the decision may be made before governance is aware of it.

Practical implication: treat AI prompts and AI-assisted actions as governed access events, not informal productivity work.

Identity-first access control for AI tools

Identity-first control means access decisions are made using verified user identity, device posture, and contextual policy before the AI service can be used. In this model, the AI tool is not trusted on its own. It inherits trust only through the same control plane used for SaaS and internal systems. That matters because regulated data exposure is often a context problem, not just an application problem. If the organisation cannot confirm who is asking, from what device, and under which policy, then the AI session should not be treated as safe by default.

Practical implication: align AI access with the same conditional access and device trust rules used for other high-value business systems.

Zero Trust as the operating model for AI adoption

Zero Trust Architecture assumes no implicit trust based on network location or application category. Applied to AI, that means every request to an AI tool must be authenticated, authorised, and continuously evaluated against device and data context. The article shows why this is operationally useful: a central identity layer can prevent unmanaged access while still allowing innovation. For AI governance, the key shift is from blocking tools to governing sessions, data paths, and context consistently across the environment.

Practical implication: use Zero Trust policy to govern AI sessions the same way you govern cloud, SaaS, and privileged access.

Threat narrative

Attacker objective: The objective is to exploit unchecked AI-mediated decision paths to expose sensitive data or influence business outcomes without governance visibility.

1. Entry occurs when a user reaches an AI tool or agent from an unmanaged or insufficiently verified context, bypassing the normal identity control plane.
2. Credential or context abuse follows when the session is allowed to process sensitive information without confirmed user identity, device trust, or policy enforcement.
3. Impact emerges as the AI system becomes a black box for data handling and decision influence, creating compliance exposure and untraceable business risk.

Breaches seen in the wild

• Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
• Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow decisions are the real governance failure, not shadow IT alone: the article correctly separates unapproved tools from ungoverned decisions made inside approved AI systems. That distinction matters because the second problem is harder to see and easier to normalise. IAM teams should treat any AI workflow that can read, reshape, or recommend actions on sensitive data as a policy-bound identity event, not a convenience layer.

Identity-first AI governance collapses the assumption that model access is separate from business access: this article shows that the control plane must sit in front of the prompt, not behind the output. Once an AI session can touch regulated data without verified user identity and device posture, the organisation has already lost the governance decision. Practitioners should stop treating AI as a special case and fold it into the same access model that governs SaaS, internal applications, and privileged workflows.

Zero Trust is the only practical way to make AI usable in regulated environments: Tamara’s example shows that innovation and control are not opposites when verification is centralised. The broader field lesson is that AI governance fails when teams rely on policy statements instead of enforceable access conditions. Identity-driven enforcement is what turns AI from an unmanaged variable into a governable business capability.

Identity context, not model capability, is the primary control variable: the article’s strongest insight is that the security question changes from what the AI can do to who is allowed to use it, from which device, and under what business conditions. That is a familiar IAM pattern applied to a new interface. The practical conclusion is that AI governance should inherit identity controls by default rather than inventing a parallel approval process.

Managed AI use creates a measurable governance dividend: the article links identity control to operational confidence, which is the right framing for practitioners. Once access is consistent and visible, GRC and IT teams can adopt AI without creating a separate exception process for every use case. The lesson for the market is that AI governance will converge with identity governance, not replace it.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Shadow decisions will become the more common governance gap as AI adoption spreads: organisations can block unsanctioned apps and still miss risky behaviour inside approved AI tools. The practical response is to move control closer to the prompt, where identity, device state, and policy can still be enforced.

Identity context must become part of AI risk scoring: if the actor, device, and data classification are not known at the moment of access, the AI session should be treated as ungoverned. That is the control boundary IAM teams need to define before AI use scales.

Zero Trust for AI is not a separate discipline: it is the same access model applied to a new interaction pattern. The organisations that will scale AI safely are the ones that make identity controls the default entry point for AI tools, not the after-the-fact review layer.

For practitioners

• Define AI access as a governed identity event Classify prompts, agent sessions, and AI-assisted data handling as access that must pass through the same identity policies used for business systems.
• Bind AI usage to verified user and device context Require authenticated user identity, managed-device posture, and policy evaluation before access to approved AI tools is granted.
• Centralise AI access decisions in one control plane Use a single directory or policy layer so AI tools do not create separate approval paths, exceptions, or unmanaged shadow access.
• Separate experimental AI use from regulated data access Allow experimentation only in environments where sensitive business data is excluded or tightly filtered, then expand access through policy.
• Instrument AI sessions for auditability Log who accessed which AI tool, from which device, against which data classification, so governance can review AI use as an identity record.

Key takeaways

• AI governance breaks when approved tools can still make unreviewed decisions on sensitive data outside identity control.
• The strongest control boundary is the one that verifies user identity, device trust, and policy before an AI prompt can access business information.
• IAM teams should treat AI sessions as governed access events and fold them into existing Zero Trust and conditional access models.

Key terms

• Shadow Decision: A shadow decision is an action taken through an AI tool that affects business data or workflow without passing through normal identity governance. The risk is not only unapproved software, but unreviewed decision-making that bypasses the controls teams rely on for accountability and traceability.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.
• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.