CX platforms process billions of unstructured interactions a year
Survey forms, review sites, social feeds, call center transcripts, all flowing into AI engines that trigger automated workflows touching payroll, CRM, and payment systems. No tool in a security operation center leader’s stack inspects what a CX platform’s AI engine is ingesting, and attackers figured this out. They poison the data feeding it, and the AI does the damage for them.
The Salesloft/Drift breach in August 2025 proved exactly this. Attackers compromised Salesloft’s GitHub environment, stole Drift chatbot OAuth tokens, and accessed Salesforce environments across 700+ organizations, including Cloudflare, Palo Alto Networks, and Zscaler. It then scanned stolen data for AWS keys, Snowflake tokens, and plaintext passwords. And no malware was deployed.
Six blind spots between the security stack and the AI engine
1. DLP cannot see unstructured sentiment data leaving through standard API calls
Most DLP policies classify structured personally identifiable information (PII): names, emails, and payment data. Open-text CX responses contain salary complaints, health disclosures, and executive criticism. None matches standard PII patterns. When a third-party AI tool pulls that data, the export looks like a routine API call. The DLP never fires.
2. Zombie API tokens from finished campaigns are still live
An example: Marketing ran a CX campaign six months ago, and the campaign ended. But the OAuth tokens connecting the CX platform to HRIS, CRM, and payment systems were never revoked. That means each one is a lateral movement path sitting open.
3. Public input channels have no bot mitigation before data reaches the AI engine
A web app firewall inspects HTTP payloads for a web application, but none of that coverage extends to a Trustpilot review, a Google Maps rating, or an open-text survey response that a CX platform ingests as legitimate input. Fraudulent sentiment flooding those channels is invisible to perimeter controls. VentureBeat asked security leaders and vendors whether anyone covers input channel integrity for public-facing data sources feeding CX AI engines; it turns out that the category does not exist yet.
4. Lateral movement from a compromised CX platform runs through approved API calls
“Adversaries aren’t breaking in, they’re logging in,” Daniel Bernard, chief business officer at CrowdStrike, told VentureBeat in an exclusive interview. “It’s a valid login. So from a third-party ISV perspective, you have a sign-in page, you have two-factor authentication. What else do you want from us?” The threat extends to human and non-human identities alike. Bernard described what follows: “All of a sudden, terabytes of data are being exported out. It’s non-standard usage. It’s going places where this user doesn’t go before.” A security information and event management (SIEM) system sees the authentication succeed. It does not see that behavioral shift. Without what Bernard called “software posture management” covering CX platforms, the lateral movement runs through connections that the security team already approved.
5. Non-technical users hold admin privileges nobody reviews
Marketing, HR, and customer success teams configure CX integrations because they need speed, but the SOC team may never see them. Security has to be an enabler, Keren says, or teams route around it. Any organization that cannot produce a current inventory of every CX platform integration and the admin credentials behind them has shadow admin exposure.
6. Open-text feedback hits the database before PII gets masked
Employee surveys capture complaints about managers by name, salary grievances, and health disclosures. Customer feedback is just as exposed: account details, purchase history, service disputes. None of this hits a structured PII classifier because it arrives as free text. If a breach exposes it, attackers get unmasked personal information alongside the lateral movement path.
Nobody owns this gap
These six failures share a root cause: SaaS security posture management has matured for Salesforce, ServiceNow, and other enterprise platforms. CX platforms never got the same treatment. Nobody monitors user activity, permissions, or configurations inside an experience management platform, and policy enforcement on AI workflows processing that data does not exist. When bot-driven input or anomalous data exports hit the CX application layer, nothing detects them.
Security teams are responding with what they have. Some are extending SSPM tools to cover CX platform configurations and permissions. API security gateways offer another path, inspecting token scopes and data flows between CX platforms and downstream systems. Identity-centric teams are applying CASB-style access controls to CX admin accounts.
None of those approaches deliver what CX-layer security actually requires: continuous monitoring of who is accessing experience data, real-time visibility into misconfigurations before they become lateral movement paths, and automated protection that enforces policy without waiting for a quarterly review cycle.
The blast radius security teams are not measuring
Most organizations have mapped the technical blast radius. “But not the business blast radius,” Keren said. When an AI engine triggers a compensation adjustment based on poisoned data, the damage is not a security incident. It is a wrong business decision executed at machine speed. That gap sits between the CISO, the CIO, and the business unit owner. Today no one owns it.
“When we use data to make business decisions, that data must be right,” Keren said.
Run the audit, and start with the zombie tokens. That is where Drift-scale breaches begin. Start with a 30-day validation window. The AI will not wait.
