SPLX AI Alternatives After the Zscaler Acquisition

SPLX now presents one platform for AI asset discovery and automated red teaming. It also covers runtime protection and governance. Zscaler acquired the company in November 2025. A replacement decision should therefore start with the SPLX modules actually in use and the artifacts each module owns. Replacing a platform label with another platform label can strand attack datasets and runtime policies. It can also strand historical evidence.

TL;DR

• Treat the Zscaler acquisition as a contract and roadmap review trigger, not proof that SPLX capabilities or entitlements changed in a particular way.
• Create individual exit workstreams for discovery and Probe red teaming. Do the same for AI Runtime Protection and governance.
• Export assets and custom attack datasets; findings and policies; thresholds and blocked-event logs; ownership metadata before changing the production path.
• Replay the same attacks and runtime cases against each shortlisted alternative, including timeouts and bypass attempts.
• Keep SPLX and the replacement in a bounded dual run until finding lineage and enforcement behavior pass. Evidence retrieval must pass as well.

The acquisition changes the buying context

The dated SPLX acquisition announcement states that Zscaler acquired SPLX on November 3, 2025. It describes plans to combine SPLX capabilities with Zscaler's security platform across discovery and red teaming, plus runtime guardrails and governance. The current SPLX platform page also labels SPLX as part of Zscaler while presenting the existing lifecycle modules.

That evidence establishes ownership and stated direction. It does not establish a buyer's renewal price or migration schedule. Nor does it establish support entitlement or data location. It also does not establish a feature retirement date. Ask for those answers in writing against the exact order form. Preserve the current contract and service description. Also preserve the subprocessor list and retention terms, plus support commitments before negotiating a change.

I would put the four module names on separate pages of the procurement deck. The acquisition logo belongs in the corner, not over the architecture. A team using only Probe has a different exit from a team running production traffic through AI Runtime Protection.

The DeepInspect and Zscaler comparison covers their current control boundaries. This article focuses on leaving or narrowing SPLX without losing the artifacts already created.

Discovery requires a portable asset inventory

SPLX describes discovery of models and AI workflows, plus MCP servers and guardrails, assembled into an AI bill of materials. Before evaluating an alternative, export the asset records and define the source of truth for each one. Keep identifiers and names; owners and environments; model providers and endpoints; connected data and discovered relationships; risk labels and status; first-seen dates and last-seen dates.

Reconcile the export against cloud accounts and repositories. Also check gateway configurations and the inventory system that will remain after SPLX. A discovered item without an owner should become an exception ticket rather than disappearing during migration. Record which assets came from automated discovery and which were entered manually.

Test the candidate on the same bounded environment. Count assets by type, then investigate misses and duplicates. Discovery parity does not require identical labels, but it does require a documented disposition for each production model route and agent. Local tools and browser-only AI activity may need endpoint or browser controls because a backend gateway cannot discover what never crosses it.

Probe exit starts with attack corpus custody

The SPLX Probe page describes automated and continuous red teaming. It covers predefined probes and custom attacks, plus uploaded datasets, simulated user types, and multimodal tests. Those inputs become valuable internal property once a team has tuned them to its applications. Export them before relying on a replacement.

Preserve prompt text and expected result. Keep the risk category and target, plus persona and language. Preserve modality and run configuration, plus timestamp and finding status. Keep remediation notes and retest history. If SPLX generated an attack dynamically and only the result is visible, ask which underlying input can be exported and replayed, then record any gap in the migration plan.

Build a fixed replay pack from confirmed findings and clean controls. Run it against the same application build through Probe and the candidate. Compare attack delivery and response capture. Then compare finding classification and severity, plus evidence, deduplication, and retest behavior. The automated red teaming guide explains the test category, while this replay pack establishes migration parity.

My preference is to include a handful of embarrassing false positives. They show whether the replacement preserves analyst decisions or makes the team triage old noise again. A clean export should retain suppressions and accepted-risk rationale, along with their owners and expiry dates.

Runtime protection needs a traffic acceptance test

The AI Runtime Protection page describes input and output filtering for prompt injection and jailbreaks. It also covers data exposure and off-topic behavior. It describes configurable policies and thresholds, plus similarity scores and event details such as timestamps and trigger context. A replacement has to be tested on the exact production route where those decisions occur.

Inventory every integration that carries production traffic. Record endpoints and applications; environments and supported modalities; streaming behavior and authentication context; policy assignment and threshold; response action and bypass rules; failure posture. Export policy definitions and a representative set of allowed, flagged, and blocked events. Preserve transaction IDs that connect runtime events to application logs.

Replay an allowed request and several known blocked cases. Then force an inspection timeout, disconnect a dependency, send a streaming response, and omit expected identity metadata. Record whether traffic passes or blocks. Also record whether it retries or degrades. Repeat the test for input and output handling because their timing differs.

An alternative may be an application SDK or model gateway. It may instead be a WAF or endpoint control, or a dedicated HTTP proxy. Its placement determines which traffic it can cover. The Cloudflare Firewall for AI alternatives shows how WAF and outbound model routes differ. Require the shortlist to name its traffic boundary rather than claiming generic runtime protection.

Governance evidence needs independent retention

SPLX presents governance and compliance mapping alongside the technical modules. Export policies and control mappings; approvals and exceptions; owners and review dates; finding history and report inputs. Save rendered reports only as snapshots. The structured records underneath them are what allow a team to regenerate evidence and answer an auditor's follow-up.

Decide which system becomes the continuing record for risks and exceptions. A GRC platform may own control status while a red-team product owns findings. A runtime control may own request events. That split can be sound when stable identifiers connect the records. It is safer than forcing one replacement to imitate every SPLX screen.

Retention deserves a contract-level answer. Ask SPLX and the candidate about export format and API access. Ask about the deletion sequence and backups, plus legal holds and access after termination. Run the final export while support is active, verify counts and checksums, then test restoration in customer-controlled storage.

A staged module exit limits exposure

Start with the least coupled module. Discovery or offline red teaming usually moves before runtime enforcement because it sits outside the live request path. Migrate the asset inventory and fixed Probe replay pack first. Keep existing runtime policy active while the candidate is still being tested.

For runtime migration, use a bounded observe-only phase if both products support it. Mirror events without allowing two tools to rewrite the same request. Compare decisions by transaction ID, investigate differences, and approve thresholds after the review. Move enforcement for one low-risk route and watch errors and bypass signals before expanding deliberately.

Define rollback before cutover. Preserve the previous route and policy bundle. Keep credentials and dashboards until acceptance is signed. The exit is complete when evidence remains retrievable, the candidate blocks the agreed cases, allowed traffic stays within latency and error budgets, and every old module has a named owner or retirement record.

DeepInspect

DeepInspect fits one module boundary in this exit map: authenticated HTTP calls deliberately routed from users or agents to LLM endpoints. It evaluates identity and role with data classification and destination, using a versioned policy before forwarding allowed traffic. Each decision creates evidence outside the calling application's write path.

It leaves asset discovery and offline red teaming to products positioned on those surfaces. The same applies to browser activity and local execution, plus STDIO tool calls. That narrow boundary makes the acceptance test direct: send an identified request and change one policy attribute. Then retrieve the resulting decision record. Book a technical deep dive at deepinspect.ai.