Notifications
Clear all
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.
NHIMG editorial — based on content published by Novee: Case Study. Why UiPath’s CISO Swapped Point-in-Time Scans for Continuous Proof
By the numbers:
- UiPath said it delivered over 500 releases on its cloud platform last year.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes - and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when point-in-time testing is used for fast-changing SaaS platforms?
A: Point-in-time testing breaks down when the platform changes faster than the assessment cycle.
Q: Why do multi-tenant platforms need more than scanner output to prove security?
A: Scanner output shows possible weaknesses, but it does not prove whether an attacker can actually reach them in the live environment.
Q: How do you know if tenant isolation controls are working?
A: Look for evidence that attacker paths are being validated against the current runtime, not just against design intent.
Practitioner guidance
- Map real tenant boundaries to runtime control paths Trace where authorization, workflow logic, and service identities actually enforce separation in the live platform.
- Prioritise exploitability over finding volume Filter scanner output to issues that can be chained inside the current environment and deprioritise generic package noise that does not change tenant risk.
- Retest after every material release Attach retesting to deployment cadence so that changes to tenant isolation, authorization rules, or automation flows are validated before they become operational assumptions.
What's in the full article
Novee's full case study covers the operational detail this post intentionally leaves for the source:
- How the team mapped UiPath's multi-tenant architecture into a testing model that reflected real customer workflows.
- How proof of exploitability was presented to security and engineering teams as actionable attack paths rather than generic findings.
- How continuous retesting was aligned to release cadence so fixes could be validated inside the deployment cycle.
- How the platform's handling of authorization and access control was evaluated in the context of customer separation.
👉 Read Novee's case study on continuous proof for UiPath's tenant isolation →
Tenant isolation in AI-powered SaaS: are point-in-time scans enough?
Explore further
02/08/2026 12:51 pm
Continuous proof is becoming a governance requirement, not a testing preference. In fast-moving SaaS, security evidence decays quickly if it is tied to a quarterly cycle. The practical issue is whether an enterprise can show that tenant isolation still holds after hundreds of changes, not whether a scanner produced a clean report last month. For identity programmes, that means controls over authorization, service access, and workflow boundaries have to be validated as part of normal operations, not as an afterthought.
A question worth separating out:
Q: What should security teams do when automation starts acting like a first-class actor?
A: Treat service identities and workflow permissions as part of the access model, not as background infrastructure. Review what the automation can reach, what it can change, and how those privileges are retested after releases. If non-human actions can move data or cross boundaries, they need the same governance discipline as human access.
👉 Read our full editorial: Continuous proof for AI agent tenant isolation in multi-tenant SaaS
