SPLX, a Zscaler Company

Name: SPLX, a Zscaler Company
Brand: SPLX, a Zscaler Company
Rating: 5 (1 reviews)

AI Native

The end-to-end platform to test, protect, and govern AI at enterprise scale

Est 2023|Valuation $40.6M|Raised $7M|5 Ref Customers

LinkedIn 7K|Web traffic 8K|FTEs 21|HQ New York, New York, US

Published Oct 12, 2026

01Common complaints

- If you require broad, independently validated market proof - Public independent review volume is limited, which may be insufficient for highly risk-averse procurement processes. - If your primary need is ML pipeline and model supply-chain security - If the dominant AI risk is model artifact provenance, training pipeline integrity, and CI/CD model scanning, evaluate vendors focused explicitly on ML-native controls. - If credits-based testing economics are unacceptable - Organizations that prefer fixed-cost, unlimited testing models should consider alternatives or seek contract terms that match their testing needs. - If you require fully public security documentation without a vendor engagement - Some audit reports and security evidence require requesting access from the vendor; if procurement requires publicly posted audit reports and architecture documents without an NDA or sales process, this may be a constraint. - If post-acquisition continuity is a critical factor - Buyers with multi-year stability requirements should validate roadmap commitments, support models, and product packaging as the product is integrated into the acquirer's portfolio. - Current limitations acknowledged by the vendor - The vendor acknowledges that large-scale red teaming can generate high volumes of findings and provides features intended to prioritize results; prospective buyers should validate triage effectiveness during evaluation. - Features on the roadmap (not yet available) - No detailed public roadmap with committed dates was identified in the reviewed sources; buyers should request roadmap details and migration plans during procurement. - Scale limitations - Public documentation did not provide clear service limits for maximum log throughput, maximum number of apps/agents supported, or latency impact under peak load; buyers should validate these operational limits. - Security or compliance gaps - While ISO 27001 and SOC 2 references appear at a high level, the precise scope (e.g., SOC 2 Type II vs Type I), report access, and subprocessor coverage require validation via the vendor’s security documentation. - API limitations or integration constraints - Publicly accessible excerpts did not include full API rate limits or integration breadth details; buyers should include API and integration validation in a POC.

02Why they buy

- Claimed differentiators (evidence-weighted) - Publicly visible differentiators include an emphasis on automated continuous red teaming, an AI asset/AI-BOM concept, runtime inspection capabilities, governance mapping, and a public workflow scanner intended to assist discovery of agentic workflows. - Independent validation of these differentiators is limited in public review sources; prospective buyers should validate claims in a proof of concept and with vendor references. - Areas where competitors may have advantages - Vendors with longer operating histories and larger independent review footprints may provide more referenceable customer evidence. - Open-source guardrail frameworks and libraries can be more transparent and customizable for engineering-heavy organizations, but they shift operational burden to the buyer.

03Field reports

- Important context on review availability - SPLX appears to be earlier-stage relative to more established security vendors; publicly accessible independent review volume is very limited. - Industry review platforms - Public listings show a very limited number of reviewer entries on industry review sites. One listed reviewer (identified as a CISO) provided positive feedback on leadership and technical expertise; the extremely small sample size limits the ability to draw broader conclusions from the review dataset. - Community signals - Public community discussion largely references the Agentic Radar open-source project rather than enterprise deployments. - Example community commentary describes Agentic Radar as an open-source CLI tool for agentic AI workflow analysis; these posts are primarily awareness/discussion items from developers rather than structured buyer feedback about enterprise procurement, support, uptime, or large-scale deployments. - Review platform coverage gaps - No substantive SPLX product listings or review pages were located on several major review platforms during the search (e.g., TrustRadius, G2), and Hacker News discussion specific to SPLX was not clearly identified in the search results used for this report. - Why customers evaluated the product (evidence) - The vendor emphasizes automated, continuous AI red teaming with test probes and an attack database, packaging for asset management plus red teaming and governance, and an open-source workflow scanner to facilitate discovery and adoption. - Why some customers may leave or not purchase (evidence gaps) - Publicly available information did not surface credible churn narratives. Common reasons to prefer alternatives in this category generally include integration breadth, specific compliance evidence, product maturity, and fit to ML supply-chain security needs. - Specific vendor-reported outcomes (with caveats) - Vendor case study material reports outcomes such as a substantial reduction in reported testing effort for a customer; these figures are vendor-published and lack independent verification in publicly available materials from this research. - Deal-breakers and reasons customers didn’t purchase - Not explicitly documented in public sources for SPLX; typical category deal-breakers include insufficient integrations, unclear data handling, incomplete compliance documentation, and lack of robust production runtime controls.

Case Studies

- Infobip (vendor case study; limited public detail) - Vendor case study materials state a large reduction in security testing effort for a named customer and faster deployment of AI applications. - Critical evaluation - Reported reductions are presented without a publicly visible methodology (baseline definition, measurement window, scope of testing). Prospective customers should request before/after workflows, definitions of effort, and evidence that risk coverage and incident rates were not adversely affected as a result of process changes. - Industry partner references (vendor materials) - Vendor materials include supportive statements attributed to industry partners and consultants; these indicate engagement but do not independently verify production deployment outcomes or measured security improvements.

04Best fit

- Company sizes (practical estimate) - Mid-market to enterprise organizations with established security engineering or AppSec and AI platform teams; practical employee-size range: mid-sized through very large organizations. - Very small teams may find enterprise tooling overhead and credits-based testing harder to justify. - Industries and verticals where adoption is likely - Telecommunications and IT services (vendor case example cited) - Professional services and consulting (vendor partner statements exist but should be treated as vendor-sourced) - Regulated industries such as financial services could be potential adopters, but named production references in these sectors were not identified in the public sources reviewed. - Roles and personas - Decision makers: CISO / Head of Security Engineering; Head of AI Platform / AI Engineering; Governance, Risk & Compliance leadership - End users: AI security engineers, red teamers, AppSec teams integrating tests into CI/CD, and AI product owners responsible for assistants/agents - Pain points the product addresses - Visibility into AI-related risk across prompts, agents, and tool calls - Automated and repeatable red teaming to reduce reliance on fully manual testing - Runtime controls against prompt injection, jailbreaks, and data leakage where this capability is required - Qualification criteria (good fit) - Multiple AI applications or agents in production or near-production - Requirement for continuous or automated security testing rather than ad-hoc assessments - Central governance requirements such as AI inventory, policy mapping, and audit readiness - Deal disqualifiers (poor fit) - Teams that only require basic content moderation and can rely on existing cloud controls - Organizations that require extensive public independent proof points and many mature references - Organizations with strict, specific data residency or sovereignty requirements that cannot be validated through the vendor’s documented hosting options - Representative customer example - The vendor cites an Infobip case study describing reduced testing effort; this is vendor-published and should be validated directly with the vendor and references.

05The pitch

What the product does (core value proposition in objective terms)

- SPLX is described by the vendor as a platform to test, protect, and govern AI systems across development and deployment phases, with modules for AI asset discovery and management, automated AI red teaming, runtime protection (guardrails), governance/compliance mapping, and remediation workflows. The vendor also provides related open-source tooling focused on agent workflow analysis. - An adjacent open-source project, Agentic Radar, is intended as a static-analysis style scanner for agentic workflows to visualize agent workflows, surface attack patterns and tool-level vulnerabilities, and provide hardening recommendations. The project is available in a public code repository.

Target market and market positioning

- SPLX is marketed primarily at enterprise security and AI governance stakeholders (CISOs, security teams, and AI program owners) seeking centralized visibility and controls across multiple AI applications, agents, and models. - Market category framing (based on public listings) - Industry review listings categorize the SPLX product under automated/continuous red teaming for conversational AI. - Third-party vendor communications describe SPLX as extending AI security posture management and lifecycle security capabilities (discovery, governance, red teaming, runtime controls).

Get a comprehensive analysis of SPLX, a Zscaler Company including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →