Your segmentation policy says they're isolated. Prove it.

Prancer actively attacks across network, identity, cloud, firewall, ZTNA, SSE, and microsegmentation boundaries to determine whether protected systems are actually unreachable. Don't just review the policy — attack the boundary.

Segmentation is a policy. An attack is the test.

Enterprises use firewalls, microsegmentation, Zero Trust access, cloud policy, and identity controls to limit blast radius. Configuration does not prove isolation. Prancer starts from an authorized compromised asset and attempts to reach systems that policy says should be protected. The outcome is BLOCKED (the attack path stopped at the control) or REACHABLE (Prancer proved a path across the boundary).

Test the boundaries that define your blast radius

• Network segmentation — can a compromised system communicate with networks it should not reach?
• Microsegmentation — can workloads move laterally despite workload-level policy?
• Firewall policy — do deployed rules actually prevent the attack path?
• Zero Trust / ZTNA — can an attacker reach an application through an unintended identity or access path?
• SASE / SSE — do cloud-delivered security controls prevent prohibited access and movement?
• Cloud segmentation — can an attacker pivot between accounts, VPCs/VNETs, workloads, or protected services?
• Identity-based segmentation — can credentials or privilege changes create a path that network policy alone does not reveal?
• East-west movement — can an attacker move between workloads after initial compromise?
• IT / OT boundaries — can an attacker move from enterprise IT toward protected operational environments? Focus is reachability and attack-path validation.

Follow the attack path

Prancer follows the complete attack chain: initial exploit, credential, identity, lateral movement, segmentation boundary, protected asset. A scanner finds the vulnerability. Prancer proves whether it creates a path across the boundary.

Prove the defense

Control-blocked — denied connection, blocked protocol, rejected authentication, policy enforcement, unreachable protected asset. Reachable — successful connection, authenticated access, credential reuse, workload reached, protected service accessed, subsequent attack step executed.

Change the policy. Re-run the attack. Prove it closed.

Prancer makes segmentation validation repeatable. Attack, prove reachable, change policy, re-run, prove blocked — from assumed isolation to proven isolation. Rerun authorized attack paths after firewall changes, microsegmentation changes, application deployments, cloud changes, identity changes, Zero Trust policy changes, infrastructure migrations, or security incidents.

Use cases

Ransomware blast radius, crown-jewel protection, cloud isolation, Zero Trust validation, IT / OT separation, and post-change validation.

Evidence

If it isn't proven, it doesn't publish. Attack attempt → execution → target response → evidence → verdict: CONTROL-BLOCKED, REACHABLE, or UNREACHABLE.

Explore Prancer Product · SSE validation · Frontier attack validation · SwarmHack technology