Research Briefing
Shadow AI and the New Problem of Delegated Authority
From invisible AI usage to autonomous enterprise action
Executive summary
- Shadow AI starts as an unmanaged adoption problem, but agentic systems turn it into a question of delegated authority.
- Conventional Shadow AI needs visibility into tools, accounts, data movement and retention.
- Agentic Shadow AI also needs identity governance, least privilege, action telemetry, approval gates and rapid deprovisioning.
- Security vendors describe the problem through their existing control planes, so buyers need an integrated evidence model.
Contents
Generative AI has entered enterprise environments faster than most organizations have been able to define policies, deploy controls or establish clear ownership. Employees use public assistants to summarize documents, rewrite messages, analyse spreadsheets and generate code. Development teams connect models through APIs and notebooks. Software-as-a-Service platforms activate embedded AI functions inside applications that already contain sensitive corporate information.
Much of this activity begins with a legitimate productivity objective. A support agent wants to draft a clearer customer response. A developer wants help interpreting a stack trace. A finance professional wants to summarize a long report. A legal team wants to compare contract clauses.
The risk emerges when these actions occur outside the organization’s visibility, approved architecture and control framework.
This is the domain of Shadow AI.
Shadow AI includes the use of artificial intelligence systems, models, assistants and embedded capabilities without adequate organizational awareness, governance or protection. It extends the familiar Shadow IT problem into an environment where data may be processed by external models, prompts may become operational instructions and software agents may receive delegated authority over enterprise systems.
The security objective should focus on making AI usage visible, governed and protected. Organizations need approved alternatives, practical controls and response procedures that preserve legitimate productivity while reducing unmanaged exposure.
The evolution from Shadow IT to Shadow AI
Shadow IT traditionally refers to applications, cloud storage, messaging platforms and file-sharing services adopted without formal approval. Its central problem is familiar. Employees move business information into systems that security teams cannot adequately assess, monitor or control.
Shadow AI inherits this visibility problem and introduces new disclosure pathways.
Employees can copy confidential information into a public chatbot. Developers can send proprietary code, credentials or production logs to an external coding assistant. Business users can upload financial packs, contracts, customer records or strategic documents to personal AI accounts. Embedded AI functions can retrieve content from repositories with excessive permissions. Local models may store prompts, responses, embeddings and traces outside standard retention and monitoring systems.
Agentic AI creates a further transition.
An AI agent can receive credentials, connect to SaaS platforms, invoke tools, call APIs, maintain persistent memory and execute actions. It may send messages, update tickets, modify records, move files, launch workflows or interact with external systems.
The security question therefore changes.
For conventional Shadow AI, the primary concern is what data is being sent to an AI service. For agentic systems, the organization must also determine what the AI can access, what authority has been delegated to it and what actions it can execute.
The first problem is largely associated with visibility and data flow. The second introduces identity, permissions and delegated authority.
This distinction is critical because an autonomous agent behaves as a new enterprise actor. It may operate continuously, use permissions inherited from a human sponsor and retain access after the original business requirement has disappeared. Traditional controls remain relevant, although they must be extended to non-human identities and machine-initiated actions.
The main enterprise patterns behind Shadow AI
Shadow AI does not appear through one single channel. Several enterprise patterns produce different disclosure mechanisms and require different evidence.
Personal generative AI services
The most visible pattern involves employees using personal or public generative AI accounts. Information is entered through copied prompts or uploaded files.
The exposed content may include customer tickets, personal information, financial data, human resources documents, contracts, meeting transcripts, internal strategy notes or security logs. The user may see the action as a temporary interaction, while the organization may have limited knowledge of how the provider stores, logs, processes or reuses the information.
The disclosure is frequently accidental and driven by convenience.
AI embedded inside approved SaaS platforms
An approved SaaS product may introduce a copilot, assistant or agent after the original security review. This creates a more subtle form of Shadow AI because the application itself is sanctioned.
The AI capability can retrieve content from repositories, messages, documents and collaboration platforms that the user is technically allowed to access. Excessive permissions and over-shared repositories become more significant once an AI system can search and synthesize them at scale.
The problem may originate in the underlying access model rather than the AI interface.
Developer assistants, APIs and notebooks
Software engineering introduces another set of risks. Developers may share source code, stack traces, architecture details, API keys, database records or production logs with an assistant or external model API.
A coding interaction can therefore reveal intellectual property and infrastructure information while creating immediate credential exposure. Any key or token included in an external prompt should be treated as potentially compromised and rotated accordingly.
Local and open-source models
Running a model locally can reduce some third-party exposure, although it does not automatically establish governance.
Prompts, outputs, embeddings, model files, traces and interaction logs may be stored outside approved monitoring, backup and retention controls. Local installations may also bypass software inventory, vulnerability management or endpoint policy.
The location of the model changes the disclosure channel. It does not remove the need for governance.
Agentic AI requires identity governance
An AI agent should be treated as an enterprise principal.
That principle has direct consequences. Every agent needs an identifiable owner, a documented purpose, a defined operating environment and a human sponsor accountable for its use. Its credentials, tokens, connectors and permissions must be connected to a specific workflow rather than granted as broad standing access.
The lifecycle should follow four main governance stages.
Provisioning and registration
Before an agent becomes operational, the organization should register its identity, owner, business purpose, environment and associated service principal. The approved workflow and expected data domains should be documented.
Tool access should be explicit. OAuth grants, APIs and connectors should correspond to the tasks the agent is expected to perform.
Sensitive actions such as sending messages, exporting information, changing records or triggering workflows should have predefined guardrails and approval requirements.
Entitlement review
The agent’s sponsor, business purpose and review schedule should be attested in the same way as other identities.
Reviews should include OAuth grants, API keys, permission sets, connected repositories, data domains and persistent memory. This is particularly important when an agent’s capabilities evolve after deployment or when new connectors are added.
Least privilege and behavioural control
Generic enterprise bots with broad access create significant accountability and containment problems. Agents should be bound to a defined task and use the narrowest possible permissions.
Persistent memory should never become an indirect source of standing access. The organization should understand what information is retained, where it is stored and how it influences future actions.
Behavioural controls are also required. Low-confidence decisions, sensitive data classes and high-impact actions should trigger human approval. Repeated overreach should lead to reduced scopes or suspension.
Deprovisioning
Agent access should end when the workflow is retired, the owner leaves, the project closes or the business purpose expires.
Tokens, connectors, permissions and memory must be revoked or deleted. Organizations also need a rapid containment mechanism capable of suspending an agent, disabling its workflow and preserving relevant evidence.
An agent becomes governable when the organization can answer three questions with evidence.
Who owns it?
What is it allowed to access?
What actions has it performed?
Two risk domains require two control models
Traditional Shadow AI and agentic Shadow AI share a common origin in unmanaged AI adoption, although their main security problems differ.
Shadow AI as a visibility and data-flow problem
The primary question is what data is being sent to which AI service.
Representative cases include employees using personal generative AI accounts, developers sending code or logs to assistants and approved SaaS platforms introducing AI capabilities without adequate review.
The core controls are relatively mature.
Organizations can use AI application discovery, personal-versus-enterprise account detection, DLP, content classification, browser controls, upload restrictions, endpoint telemetry and approved enterprise AI environments.
The usual response involves warning the user, blocking the interaction, redacting sensitive information or redirecting the activity to an approved tenant.
Agentic Shadow AI as an identity and authority problem
The primary question is what the agent can access, decide and execute.
Representative cases include agents connected to SaaS applications, copilots retrieving content from over-permissioned repositories and abandoned workflows that retain active tokens after their business purpose ends.
The corresponding controls include inventories of non-human identities, OAuth and token lifecycle management, least privilege, entitlement review, approval gates, action logging, kill switches and deprovisioning.
The response may require suspending the agent, revoking tokens, reducing scopes or requiring human approval before sensitive actions.
Current security platforms provide substantial coverage for the data-flow domain. Responsibility for agent authority remains more fragmented. Identity teams, SaaS security teams, application owners, cloud security teams and security operations may each control part of the problem.
A central governance model is therefore necessary to prevent gaps between those domains.
Use cases should be connected to evidence and response
A use case becomes operationally meaningful when the organization defines what happened, what evidence must be collected and what response should follow.
Customer support
A support employee pastes a customer ticket containing personal data into a personal AI account to draft a response.
Useful evidence includes browser copy-and-paste telemetry, file-upload activity, personal account indicators, PII classification and device posture.
The preferred response combines coaching and redirection to an approved drafting workflow. Customer context should remain within the CRM or another governed enterprise system.
Software engineering
A developer shares source code, production logs, stack traces or credentials with an assistant, API or notebook.
Evidence should include source-code fingerprints, token patterns, repository paths, developer identity and the destination service.
Sensitive uploads may need to be blocked. Any exposed secrets should be rotated. The security process should assume that an externalized key may have been logged or retained.
Finance and legal
A user uploads a contract, acquisition document or financial pack for summarization or redrafting.
Sensitivity labels, document fingerprints, deal vocabulary, file ownership and the external tenant are relevant evidence.
The organization may quarantine the upload, notify the owner and involve privacy or legal teams when the potential exposure warrants escalation.
Enterprise copilots and embedded SaaS AI
An approved AI assistant retrieves content that users can technically access but should not see broadly.
The required evidence includes query logs, retrieval context, source paths, repository permissions, inherited access and sensitivity labels.
The durable remediation is a correction of the permissions layer. A sanctioned AI environment still depends on clean access governance.
Agents connected to SaaS platforms
An agent reads files, sends email, updates tickets or posts content through delegated credentials.
Investigation requires the agent identity, owner, OAuth grant, connector records, tool calls, send or update events and egress targets.
Containment may include pausing the agent, revoking the token and requiring approval for write or send operations.
Abandoned workflows
An automated workflow remains active after the associated project, owner or business requirement has ended.
Investigators should examine its last execution, token age, scopes, ownership, triggers, service-principal activity and unused grants.
Stale tokens should be revoked and orphaned workflows disabled. Periodic lifecycle attestations and automatic expiration can reduce recurrence.
The quality of response depends on the evidence captured at the moment of exposure. A generic alert stating that an AI service was used will rarely be sufficient. Security teams need information about the user or agent, account type, data classification, device, destination, action and downstream impact.
A scalable governance operating model
Large enterprises and managed service providers need an operating model that combines central guardrails with local execution.
Central teams should define mandatory principles, risk tiers, ownership requirements and data-handling rules. Business units, regions and tenants can then apply those baselines according to their approved tools, local obligations and risk appetite.
Eight components form a practical operating model.
First, the organization needs central governance with defined ownership and local overlays.
Second, it needs an approved AI catalogue that identifies sanctioned tools, enterprise tenants, suitable use cases, onboarding processes and prohibited activities.
Third, the data classification model should map public, internal, confidential and regulated information to permitted AI destinations and actions.
Fourth, exceptions should move through a formal workflow involving the data owner, security and relevant privacy or legal stakeholders. Approval should have a defined expiration date.
Fifth, metrics should track discovery events, coaching, blocks, sensitive uploads, exceptions and remediation age.
Sixth, multi-tenant organizations need policy versioning, inherited baselines and controlled local overrides.
Seventh, high-confidence events should be sent to the SOC or XDR layer with data-class, account, identity and agent-action context.
Eighth, incidents, exceptions and false positives should feed continuous policy improvement.
The goal is a practical route to approved AI use. Employees who encounter only prohibition will often find less visible alternatives. Governance is more effective when approved capabilities are easy to discover and fit the actual workflow.
Detection and response as one evidence-driven loop
Shadow AI detection should connect directly to triage, containment and control improvement.
Relevant telemetry is distributed across several layers.
Network and SSE platforms can identify AI categories, uploads and personal-login indicators. Browsers and endpoint agents can observe copy-and-paste activity, extensions, file uploads and local applications. SaaS and Microsoft 365 environments provide usage logs, labels, audit records and OAuth grants. Data security tools add classification, fingerprints and credential detection. Identity platforms contribute user, group, device, sign-in and token-scope context. AI runtimes can provide prompts, model calls, tool invocations, traces and memory activity.
These sources should be correlated around a limited set of triage questions.
What data was shared?
Which user or agent performed the action?
Which account, device and tool were involved?
Was the information stored, logged, indexed or used for training?
What action did the AI perform?
Did the event create downstream exposure?
The response workflow can then proceed through five stages.
Classification establishes the data type, sensitivity, tool, account, intent and exposure pathway.
Containment blocks the session, quarantines the upload, revokes a token or suspends an agent.
Assessment determines whether information was stored, trained on, shared, indexed, logged or transferred to additional parties.
Remediation may involve deletion, recall, credential rotation, permission reduction and notification of the relevant owner.
Improvement updates policies, DLP rules, approved tools, coaching and exception processes.
Automation should depend on severity and confidence.
A low-severity event involving an approved tool and non-sensitive information may require only logging and user guidance.
An unapproved service receiving internal information may trigger a warning, block, redirection or ticket.
PII, proprietary code or credentials justify stronger containment, secret rotation and specialist review.
Regulated data, mass uploads or apparent exfiltration should enter the formal incident-response process.
How security vendors frame Shadow AI
The security market does not define Shadow AI from a neutral position. Vendors tend to describe it through the control plane they already own.
This does not invalidate their capabilities. It does mean buyers should separate the underlying risk from each vendor’s commercial framing.
Netskope
Netskope approaches Shadow AI primarily as a SaaS usage and sensitive-data-flow problem.
Its natural strengths include AI application discovery, differentiation between personal and corporate accounts, prompt and file inspection, contextual DLP and enforcement actions such as allowing, blocking, redacting or coaching.
This model is especially relevant for public generative AI services and employee-driven disclosure. Its extension toward private and agentic AI continues to emphasize visibility, connectors and data governance.
Broader agent lifecycle and authority controls will usually require integration with identity and runtime systems.
Zscaler
Zscaler places the inline access path at the centre of its approach.
The platform’s value comes from observing and controlling interactions as users, applications and workloads connect to AI services. This supports identity-aware access, prompt inspection, upload and download controls and real-time enforcement.
Its agentic proposition extends this logic toward AI assets, services, workloads and agent traffic.
The model is strongest where relevant activity traverses the enforcement layer. SaaS-side actions, local execution and persistent delegated permissions may require other sources of telemetry.
Palo Alto Networks
Palo Alto Networks uses a broader AI attack-surface and lifecycle framing.
Its approach can connect employee access, AI applications, models, agents, plugins, cloud workloads, infrastructure and runtime behaviour across several product families.
The advantage is breadth. It allows organizations to view Shadow AI as part of a larger AI-security architecture extending from development to production and security operations.
The interpretation requires careful scoping. A very broad definition can cause Shadow AI to absorb almost every form of AI security risk.
Microsoft
Microsoft frames the issue through workplace data, identity, device management, permissions and compliance.
Its enterprise position spans documents, email, collaboration, endpoints, cloud identity and AI assistants. This creates a strong foundation for usage discovery, sensitivity controls, audit, permission governance and agent identities.
The approach is particularly compelling in Microsoft-centric environments because the platform can combine data context, user identity, device posture and copilot activity.
Its preferred solution naturally encourages organizations to maintain AI activity within Microsoft’s enterprise ecosystem.
CrowdStrike
CrowdStrike is less directly aligned with conventional prompt-level Shadow AI, where the dominant concern is legitimate user interaction with public AI applications.
Its relevance increases when AI systems execute processes, use credentials, invoke scripts, access cloud resources or operate as autonomous identities.
Endpoint, identity and cloud telemetry can reveal agent behaviour and support containment when autonomous activity becomes risky.
These strengths complement browser, CASB and DLP controls rather than replacing them.
No single vendor currently provides complete control across both risk domains. The practical gap lies in integration.
Organizations need to correlate data-flow visibility, account context, non-human identities, OAuth scopes, runtime actions and incident-response capabilities. XDR can support this correlation and containment, especially across endpoint, identity, cloud and SaaS telemetry. It functions best as part of the response architecture rather than as the primary Shadow AI control.
Final perspective
Shadow AI begins as an adoption and visibility issue. It becomes a data-security problem when users or applications send sensitive information to unmanaged AI services. It becomes an identity and authority problem when agents gain credentials, persistent access and the ability to act.
Organizations already possess many of the required capabilities. CASB, SSE, DLP, browser controls, data classification, IAM, PAM, SaaS security, endpoint monitoring, XDR and incident response all have a role.
The challenge is to connect them around the behaviour of AI systems.
Conventional Shadow AI requires visibility into applications, accounts and data movement.
Agentic Shadow AI requires registered identities, accountable ownership, narrow scopes, approval gates, action telemetry, rapid containment and reliable deprovisioning.
A mature programme should make safe AI adoption easier than unmanaged adoption. It should offer approved tools, clear data rules, observable workflows and proportionate response.
The central principle is straightforward.