TL;DR: Unauthorized AI use is outpacing enterprise governance, with 75% of knowledge workers using AI at work, 78% bringing their own tools, and organizations averaging 223 AI data policy violations a month, according to Cymulate-cited industry research. The issue is no longer AI adoption itself but unmanaged access, data flow, and control validation across identities, applications, and agents.
NHIMG editorial — based on content published by Cymulate: Combating Rogue AI: A CISO's Guide to Detecting, Governing and Securing Unauthorized AI
By the numbers:
- 75% of knowledge workers now use AI at work.
- 78% of AI users bring their own AI tools rather than using approved enterprise solutions.
- Organizations now experience an average of 223 AI data policy violations every month.
Questions worth separating out
Q: How should security teams govern AI use in developer tooling?
A: Security teams should govern AI use as a data and access problem, not only a productivity feature.
Q: Why do AI agents create new risk in non-human identity management?
A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts.
Q: What breaks when third-party AI use is invisible to the security team?
A: When third-party AI use is invisible, organisations lose control over where sensitive data is processed, retained, and exposed.
Practitioner guidance
- Discover and classify all AI-connected access paths Inventory personal AI tools, browser extensions, coding assistants, agents, and SaaS AI features that touch enterprise data or authenticate to internal systems.
- Review AI permissions against least-privilege expectations Compare each AI-connected permission set to the minimum access needed for the use case, then remove broad or persistent access where task-scoped delegation is possible.
- Add AI workflows to data protection controls Extend DLP, classification, and monitoring to approved and unapproved AI tools so sensitive data leaving the environment is visible and enforceable.
What's in the full article
Cymulate's full blog covers the operational detail this post intentionally leaves for the source:
- The phased roadmap for moving from AI discovery to governance, technical controls, and operationalised risk management
- The exposure validation workflow used to test prompt injection, DLP, and AI attack-path coverage
- The control validation approach for identities, applications, and data touched by AI tools and agents
- The board-level reporting model for showing whether AI controls still work as deployments change
👉 Read Cymulate's analysis of rogue AI governance, controls, and exposure validation →
Rogue AI governance gaps: what security teams need to change?
Explore further
Rogue AI is an identity governance problem before it is an AI tooling problem. The article correctly frames unauthorized AI as a control gap, not a feature debate. Once AI systems are granted OAuth access, API keys, or workflow permissions, they become governed identities in practice even if the organisation never classified them that way. That means IAM, PAM, and access review disciplines must treat AI-linked permissions as first-class assets, not side effects of adoption.
A question worth separating out:
Q: Who is accountable when rogue AI accesses regulated data or enterprise systems?
A: Accountability should sit with the teams that approve the use case, grant the permissions, and own the data or application being accessed. Security can set the control model, but legal, compliance, IT, and business owners all need defined decision rights and revocation authority.
👉 Read our full editorial: Rogue AI is exposing identity and data controls across the enterprise