Topic starter
02/08/2026 11:39 am
TL;DR: UiPath’s CISO describes how continuous validation replaced point-in-time scanning to keep pace with more than 500 cloud releases a year and to test whether tenant isolation, authorization, and business logic remain reachable under real attacker techniques, according to Novee. The case shows why exploitability proof matters more than vulnerability volume when agentic automation and multi-tenant SaaS change faster than audit cycles.
Editorial analysis by NHI Mgmt Group, based on content published by Novee: “Case Study: Why UiPath’s CISO Swapped Point-in-Time Scans for Continuous Proof”.
Key questions
Q: What breaks when point-in-time scans are used to prove tenant isolation in SaaS?
A: They miss changes that happen between assessments, so isolation and authorization can drift without being re-tested.
Q: Why does continuous validation matter more when SaaS platforms use AI agents and heavy automation?
A: Because automation changes execution speed and path variability faster than periodic reviews can track.
Q: What are the signs that tenant isolation testing is failing?
A: Look for requests that succeed when the same action is replayed under a different tenant, especially if object IDs can be enumerated or modified.
Practitioner guidance
- Adopt continuous exploitability validation Use continuous proof to test whether tenant isolation, authorization, and business logic remain reachable after each platform change, rather than waiting for scheduled assessments.
- Map tenant-scoped attack paths Model how a real attacker would move through customer workflows, shared services, and access control decisions inside the SaaS product, then test those paths directly.
- Prioritise reachable findings over scanner noise Triage issues by whether they can be chained and reached in the live environment, not by whether they appear in generic dependency or package reports.
Bottom line: Point-in-time scanning is too blunt for multi-tenant SaaS environments that change continuously and must prove customer isolation under real attacker techniques.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:51 pm
Continuous proof is becoming the only honest control for fast-changing multi-tenant SaaS: periodic scans cannot keep pace with hundreds of releases, especially when workflow logic and tenant separation are part of the security boundary. The control question is no longer whether a vulnerability exists in theory, but whether a real attacker path is still reachable after each change. That makes exploitability validation a governance function, not a one-off security test.
A question worth separating out:
A: Treat the finding as a customer-exposure issue, not a theoretical code defect. Contain the reachable path, retest the fix in the same tenant context, and update the control model so the next release cannot reintroduce the same isolation failure. The goal is to preserve trust in customer separation, not just reduce vulnerability count.
👉 Read our full editorial: Continuous proof for AI agent tenant isolation in multi-tenant SaaS