BLOG ARTICLE • 24 JULY 2026 • SUGGESTED READING TIME: 9–11 MINUTES
Why DLP, EDR, SSE and CNAPP are necessary—but no longer sufficient
| Executive view: AI now creates three simultaneous security needs: protecting AI systems, defending against AI-enabled attacks, and using AI to strengthen security operations. The market is responding with AI Security Posture Management, DSPM for AI, AI runtime security, agent security and integrated AI security platforms. |
Three different AI security problems
Artificial intelligence is changing cybersecurity in three different ways simultaneously. Attackers are using AI to improve reconnaissance, social engineering, malware development and vulnerability exploitation. Employees are transferring organisational information into public and enterprise AI services. Meanwhile, companies are deploying AI applications and autonomous agents that can retrieve data, call APIs, use credentials and take actions in business systems.
- Security for AI: protecting models, agents, AI applications, training pipelines and retrieval systems.
- Security from AI-enabled attacks: defending the organisation against adversaries that use AI.
- AI for security: using AI to improve detection, investigation and response.
Traditional DLP, EDR, secure web gateways, application security and cloud-security tools remain essential. However, none independently covers the complete AI attack surface. This gap is driving the emergence of the enterprise AI security platform.
The evidence: adoption is moving faster than governance
Recent industry and research findings consistently point to a widening control gap:
- Stanford’s AI Index reported organisational AI adoption reaching 88% in 2025 and documented AI-related incidents increasing from 233 in 2024 to 362 in 2025—about 55%.
- IBM’s 2025 Cost of a Data Breach research reported that, among organisations with an AI-related security incident, 97% lacked appropriate AI access controls; 63% of surveyed organisations lacked AI-governance policies designed to manage AI use or shadow AI.
- Netskope reported that approximately 90% of organisations used dedicated generative-AI applications, while 72% of enterprise GenAI usage was classified as shadow IT in its observed environment.
- Zscaler reported almost 3.2 million potential data-policy violations involving ChatGPT and Microsoft Copilot in its 2025 Data@Risk findings.
These figures should not be read as universal measurements for every enterprise; several come from vendor telemetry. They are nevertheless useful indicators of the speed and scale at which AI-related data and access risks are appearing.
Shadow AI is becoming the new shadow IT
For many organisations, the first visible AI-security problem is not a malicious model. It is an employee copying sensitive data into an unapproved AI service or using a personal AI account outside corporate policy.
This is why AI security first appeared inside familiar categories such as DLP, CASB, secure web gateway and security service edge. These products already sit between users, applications and data. But controlling uploads to a public chatbot addresses only one layer of the risk.
Why conventional DLP is necessary—but insufficient
Traditional DLP can inspect prompts, pasted text and uploaded files, identify sensitive information, and block or coach users. It is therefore a critical foundation for AI security.
- Discover sensitive data included in prompts or uploaded documents.
- Apply policy based on data classification, labels and user identity.
- Control access to public or unsanctioned AI services.
- Detect oversharing to copilots and enterprise AI applications.
However, DLP generally cannot determine whether a model has been poisoned, whether a RAG knowledge base has been manipulated, whether an application is vulnerable to prompt injection, or whether an autonomous agent has excessive privileges and unsafe tool access.
Key distinction: DLP protects information entering and leaving an AI system. It does not fully secure the AI system itself.
Why EDR cannot become the entire AI-security platform
EDR and XDR monitor processes, scripts, memory, files, credentials and endpoint behaviour. They remain essential for detecting malware and attacker activity—even when AI helped create or adapt the attack.
But EDR typically observes the machine, not the complete semantic chain of an AI interaction. AI runtime security must also observe the prompt, model response, retrieved context, agent identity, tool call and resulting business action.
- An indirect prompt hidden in a document may manipulate an agent without triggering a traditional endpoint alert.
- An agent may use valid credentials to perform an unsafe but technically legitimate transaction.
- A model may disclose restricted information without creating a malicious process or file.
- A poisoned RAG source may influence a decision while the infrastructure appears healthy.
How Gartner and the wider market are defining the category
Gartner brought these requirements together under AI Trust, Risk and Security Management (AI TRiSM), combining governance, trust, model risk, compliance, monitoring and security. It has also identified AI security platforms as an emerging strategic category that centralises visibility and controls across third-party AI services and custom-built AI applications.
The market has not yet settled on a single taxonomy. The strongest categories currently visible are shown below.
| Category | Primary purpose | Typical controls |
| AI TRiSM | Broad governance, trust, risk and security framework | Governance, model risk, compliance, testing, monitoring and enforcement |
| AI Security Platform | Unified protection for enterprise AI usage and applications | Discovery, posture, data security, runtime controls and response |
| AI-SPM | Security posture management for the AI stack | Model inventory, configuration, packages, identities and exposure |
| DSPM for AI | Protect data accessed or processed by AI | Classification, oversharing analysis, AI-aware DLP and access governance |
| AI Runtime Security | Protect live AI interactions and actions | Prompt injection defence, response inspection, tool-call controls and guardrails |
| Agent Security | Control autonomous agents and non-human identities | Least privilege, memory integrity, approvals, action limits and kill switches |
| AI Red Teaming | Adversarial testing of AI systems | Jailbreak, prompt injection, RAG poisoning and model abuse testing |
How current security vendors are categorising AI security
1. DLP and data-security vendors: DSPM for AI
Microsoft Purview, Netskope, Zscaler and similar vendors are extending data-security controls to AI prompts, uploaded content, sensitive-data exposure, shadow AI and oversharing. Common labels include DSPM for AI, GenAI data protection, AI-aware DLP and data security for copilots.
2. Endpoint and cloud-security vendors: AI-SPM
Vendors such as CrowdStrike are positioning AI discovery, model inventory, posture assessment, data protection and cloud/model security as connected capabilities. AI-SPM extends posture management to AI services, models, packages, pipelines, identities and exposed artefacts.
3. Network and platform-security vendors: end-to-end AI protection
Cisco uses the AI Defense label for end-to-end controls spanning AI access, application validation and runtime protection. Palo Alto Networks positions Prisma AIRS as an AI security platform combining posture management, model security, red teaming and runtime protection.
4. SIEM, XDR and SOC vendors: AI for security operations
Security-operations vendors are heavily focused on AI-assisted investigation, prioritisation, detection engineering and response. This is AI for cybersecurity rather than complete security for AI, although the two areas will increasingly integrate.
What existing controls can—and cannot—do
| Existing control | Still valuable for | Key limitation in AI environments |
| DLP / DSPM | Protect sensitive information in prompts, files and outputs | Cannot fully secure model behaviour, agent logic or RAG integrity |
| EDR / XDR | Detect malicious processes, scripts, credentials and endpoint behaviour | May not understand prompt manipulation or unsafe autonomous actions |
| SSE / CASB / SWG | Discover and control public AI usage | May have limited visibility into internally built AI applications |
| CNAPP / CSPM | Protect cloud infrastructure hosting AI | Does not independently secure prompts, models and agent decisions |
| AppSec | Find code, API and software vulnerabilities | Nondeterministic AI behaviour needs specialised testing |
| IAM / PAM | Govern identities and privileged access | Agent delegation and machine autonomy require additional controls |
| SIEM / SOAR | Correlate events and orchestrate response | Needs AI-specific telemetry and playbooks |
A practical enterprise AI-security architecture
Discover: Maintain an inventory of AI services, applications, models, agents, data sources, plugins, APIs, identities and users.
Assess: Evaluate data exposure, permissions, model provenance, vulnerabilities, prompt-injection exposure and regulatory obligations.
Protect: Apply AI-aware DLP, access control, model validation, prompt and response inspection, agent permissions and runtime guardrails.
Monitor: Observe AI-user interactions, retrieval activity, tool calls, model behaviour, identity use and agent actions.
Respond: Integrate AI events with SIEM, XDR, SOC and incident-response processes. Block prompts, revoke agent identities, prevent tool calls or isolate workloads when required.
Conclusion: AI security is a new control plane
AI security is not merely a new DLP rule, an EDR signature or another web category. DLP will protect data, EDR will detect malicious execution, SSE will control employee access, CNAPP will protect infrastructure, IAM will govern identities, and SIEM/XDR will correlate incidents.
But enterprises also need controls that understand the AI system itself: its model, context, retrieved information, prompts, outputs, tools, memory, decisions and actions.
Discover every AI asset. Assess its risk. Protect its data and operation. Monitor its behaviour. Respond when it acts outside policy.
References and verification sources
- Stanford HAI, AI Index Report 2026 — https://hai.stanford.edu/ai-index/2026-ai-index-report
- IBM, Cost of a Data Breach Report 2025 — https://www.ibm.com/reports/data-breach
- Netskope, Cloud and Threat Report: Generative AI 2025 — https://www.netskope.com/resources/cloud-and-threat-reports/cloud-and-threat-report-generative-ai-2025
- Zscaler, Data@Risk Report 2025 — https://www.zscaler.com/learn/data-risk-report-2025-enterprise-data-security
- Microsoft Security Blog, Microsoft Purview and generative AI security — https://www.microsoft.com/en-us/security/blog/2025/01/27/fast-track-generative-ai-security-with-microsoft-purview/
- CrowdStrike, AI Security Posture Management — https://www.crowdstrike.com/en-us/platform/cloud-security/ai-spm/
- Cisco, AI Defense — https://www.cisco.com/site/us/en/products/security/ai-defense/index.html
- Palo Alto Networks, AI Runtime Security / Prisma AIRS — https://docs.paloaltonetworks.com/ai-runtime-security
- Gartner, AI TRiSM and AI Security Platform research — https://www.gartner.com/en/information-technology/glossary/ai-trism
- MITRE ATLAS — https://atlas.mitre.org/
- NIST AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework