AI adoption is outpacing security controls in enterprise environments

At a glance

What this is: This is a WitnessAI analysis of how enterprise AI adoption is accelerating faster than security oversight, with shadow AI, prompt injection, and data exposure emerging as the central governance gaps.

Why it matters: IAM and security teams need to treat AI usage as a governed identity-and-access problem because unmanaged AI tools can reach internal data, expose sensitive content, and bypass the approval paths current controls assume.

By the numbers:

• WitnessAI spoke with more than 200 organisations across various industries about AI adoption and security controls.

Context

AI adoption here means business users, developers, and customer-facing teams bringing AI tools into workflows faster than security can classify, approve, and govern them. The governance problem is not the model itself, but the control gap that appears when usage starts outside established review paths and then reaches sensitive data.

WitnessAI describes a market shift from zero-tolerance AI bans toward active demand for AI-enabled productivity, customer service, and development workflows. That change matters because shadow AI turns access governance into a discovery problem: security teams cannot enforce policy against tools they do not know exist.

The article’s central message is that enterprise AI adoption is now being driven by business pressure, not security readiness. That is atypical for mature governance programmes, where controls normally precede scale; here, scale is arriving first.

Key questions

Q: How should security teams govern shadow AI without blocking business productivity?

A: Start by identifying the identities and credentials behind AI use, then classify each one by data sensitivity, connected systems, and business purpose. Governance works best when organisations control the access path rather than banning the tool outright. That means inventory, approval, monitoring, and revocation all need to follow the same identity path.

Q: Why do sanctioned AI assistants create data exposure risk in collaboration platforms?

A: Sanctioned AI assistants inherit the permissions of the repositories they query, so any over-shared file or loosely governed workspace can become visible through the assistant interface. When access groups are too broad, AI can surface material that users were never meant to find through normal navigation. The control issue is least privilege, not model quality.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: What should organisations do when AI adoption outpaces governance?

A: Slow the rollout of new use cases until the identity model is clear, the permissions are bounded, and the lifecycle process is in place. Security leaders should fund AI only where it supports existing cybersecurity objectives and where access can be monitored, rotated, and removed on time.

Technical breakdown

Shadow AI discovery and control surfaces

Shadow AI is the use of AI tools without security team approval or inventory. In practice, that includes sanctioned platforms used in unsanctioned ways and completely unmanaged tools embedded in business workflows. The technical issue is discovery: if a tool can reach documents, chat systems, or code repositories before the security team knows it exists, then access reviews, policy enforcement, and risk classification all start too late. This is especially important for AI assistants that connect to OneDrive, Outlook, Dropbox, SharePoint, or Confluence, because the data surface expands as soon as the tool is connected.

Practical implication: discover AI tools and their connected data sources before you attempt policy enforcement.

Prompt injection and retrieval-based data exposure

Chatbots and AI assistants that retrieve internal data create a new attack path. Prompt injection occurs when an attacker manipulates the model’s instructions or context so it reveals information, follows unsafe actions, or ignores intended guardrails. The risk is amplified when the system is allowed to query sensitive repositories, because the model can combine broad retrieval access with weak output control. That turns the assistant into a data access layer with unpredictable behaviour, especially if the organisation assumes the model will only answer benign questions.

Practical implication: treat retrieval-enabled AI as an access path that needs explicit data filtering and output controls.

Intent-based guardrails for enterprise AI workflows

Intent-based guardrails are controls that evaluate what a user or AI workflow is trying to do, not just which application is being used. In enterprise AI, this matters because the same model can support customer service, code generation, internal search, or data analysis, each with different risk boundaries. Security teams need guardrails that distinguish approved assistance from data exfiltration, policy bypass, or accidental disclosure. Where the article references PCI DSS, the point is that sensitive values such as card data must be blocked or anonymised when AI touches regulated workflows.

Practical implication: enforce intent-aware policy at the point where AI interacts with sensitive business data.

Threat narrative

Attacker objective: The attacker aims to extract sensitive internal information or trigger unsafe AI behaviour that discloses data the organisation expected to remain protected.

1. Entry begins when employees or developers adopt sanctioned or shadow AI tools and connect them to internal data sources without the security team’s full visibility.
2. Credential or access scope is then expanded as the AI system is granted retrieval permissions over documents, chat systems, code repositories, or ticketing data.
3. Escalation occurs when prompt injection, oversharing, or weak guardrails cause the system to reveal protected content or process sensitive information outside intended boundaries.
4. Impact is exposure of customer data, intellectual property, credentials, or regulated information through an AI workflow the organisation believed was safely controlled.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.

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

NHI Mgmt Group analysis

Shadow AI is now a governance discovery problem, not just an acceptable-use issue: when business units adopt AI faster than the security team can inventory it, the first failure is visibility. Policy does not govern what it cannot see, and that makes unmanaged AI a lifecycle and access problem as much as a technology problem. Practitioners need to treat discovery as the entry point to AI governance.

Access review assumptions break when AI tools become data intermediaries: many IAM and governance programmes assume users request access directly to systems. AI assistants now sit between the user and the data, which means the relevant control is not only who can log in, but what the assistant can retrieve, summarise, and expose. That changes the governance unit from an account to an interaction path, and that is a material shift for identity teams.

Intent-based guardrails are the right named concept for this risk class: the article shows that the security question is not whether AI is allowed, but whether its use can be constrained to approved intent. Without that layer, the same tool can support productivity and data leakage in the same session. Practitioners should therefore frame AI governance around use intent, connected data, and output handling, not around blanket approval or prohibition.

AI governance committees matter only when they control scope, not optics: the article points to cross-functional oversight, but governance bodies become useful only if they can identify projects, classify risk, and block unreviewed data access. Otherwise they become a reporting layer over uncontrolled adoption. The practitioner takeaway is to align committee authority with actual control points across data, application, and identity governance.

Identity teams need to stop treating AI as a consumer of policy and start treating it as a policy boundary: AI adoption changes how entitlements are consumed, not just how they are requested. That means the strongest control posture comes from governing the AI interaction path itself, including connected repositories, prompt handling, and sensitive-data suppression. The programme implication is clear: AI belongs in identity governance because it changes the trust boundary, not because it is merely another application.

From our research library:

• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Risk Board Briefing

What this signals

AI adoption is now a trust-boundary issue: when business teams can connect AI assistants to internal systems faster than security can inventory them, the control model shifts from approval to discovery. That means identity and access teams need to govern the AI interaction path, not just the underlying account.

Intent-based guardrails will separate productive AI use from uncontrolled exposure: policies that only say yes or no are too coarse for systems that can retrieve, summarise, and disclose data in the same session. The practical challenge is to control what the AI is allowed to do with sensitive content, not only whether it can be used.

Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey: that gap is a warning that adoption pressure is outpacing governance maturity. Security leaders should expect the same pattern to repeat across copilots, chatbots, and other AI-enabled business workflows.

For practitioners

• Discover shadow AI before enforcing policy Inventory sanctioned and unsanctioned AI tools, then map which repositories, chat systems, and code assets they can reach.
• Classify AI use by business intent Separate customer support, developer assistance, and internal search into different policy scopes so one control set does not overfit all use cases.
• Restrict data exposure at retrieval time Block or anonymise regulated values before AI systems can retrieve or display them, including customer records and payment data.
• Embed AI review in governance workflows Require security and business owners to approve AI projects before they connect to production data or operational systems.

Key takeaways

• AI adoption is moving into production faster than many security teams can see or govern it, which turns shadow AI into an access and oversight problem.
• The most exposed workflows are the ones that connect AI directly to internal repositories, because retrieval and summarisation can surface sensitive data without obvious user intent.
• Security programmes need discovery, intent-based policy, and data-loss controls at the AI interaction layer if they want to enable adoption without widening the attack surface.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Intent-Based Guardrails: Intent-based guardrails are controls that constrain AI agent actions according to approved business purpose, not just technical permission. They help prevent agents from taking actions that are valid syntactically but wrong operationally, such as accessing data outside task scope or performing unintended system actions.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.

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.