TL;DR: Most organisations are using AI or preparing to adopt it, while 94% of IT leaders worry about unchecked integrations and compliance gaps, according to JumpCloud. The real issue is not AI enthusiasm but whether governance, identity controls, and monitoring can keep shadow AI and over-permissioned machine access from expanding the attack surface.
NHIMG editorial — based on content published by JumpCloud: AI governance policies every IT team requires
By the numbers:
- 94% say they’re concerned about unchecked integrations and compliance gaps that could leave their organizations exposed.
- Only 23% of IT teams actively manage these machine identities today, leaving a major gap in security.
- 94% of IT leaders worry about vulnerabilities introduced by AI.
Questions worth separating out
Q: How should security teams govern AI integrations before they reach production?
A: Security teams should require formal approval, security validation, and owner assignment before any AI integration is allowed to connect to internal systems.
Q: Why do AI tools create new IAM risks even when users trust the application?
A: AI tools create IAM risks because they often authenticate through service accounts, API keys, and tokens that can be over-permissioned or forgotten after deployment.
Q: What do security teams get wrong about shadow AI?
A: Teams often treat shadow AI as a discovery problem when it is also an access governance problem.
Practitioner guidance
- Create an approval workflow for every AI integration Require named ownership, security review, data-flow validation, and logging before any AI tool connects to production systems.
- Inventory all machine identities used by AI tools Map service accounts, API keys, and tokens to the AI systems that use them, then confirm each identity has minimum permissions and a documented owner.
- Rotate AI-related credentials on a lifecycle basis Set a rotation schedule for API keys and other secrets tied to AI tools, and revoke access immediately when integrations are retired or re-scoped.
What's in the full article
JumpCloud's full article covers the operational detail this post intentionally leaves for the source:
- The five-policy framework for AI governance, including approval, IAM, data governance, monitoring, and change management.
- Specific examples of the checks IT teams should require before AI integrations are approved for production use.
- Operational detail on how to document AI tools, their data sources, and their approval records for audit readiness.
- The article's broader IT Trends report context for teams comparing adoption patterns and governance priorities.
👉 Read JumpCloud's article on AI governance policies for IT teams →
AI governance policies and the identity controls teams are missing?
Explore further
AI governance is now an identity governance problem, not a side project. The article describes AI controls as policy, but the operational reality is access management, credential lifecycle, and auditability. Once AI tools connect to systems and data, they create non-human identities that must be governed with the same rigor as any other machine account. The implication is that IAM and security teams should own the control plane, not just advise on usage.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do you know if AI governance is actually working?
A: AI governance is working when every integration has a documented owner, every machine identity has a clear purpose, and every change is visible in logs and review records. If teams cannot explain who approved access or what credentials the AI is using, governance is incomplete.
👉 Read our full editorial: AI governance policies now define identity risk in enterprise IT