Tenant isolation verification.
Accounts in two tenants, cross-access attempted across every resource type, the assessment every multi-tenant product should run continuously.
Industries · SaaS
Your security review is now part of your sales cycle
Every enterprise deal arrives with a questionnaire, a SOC 2 request and someone technical asking when you last tested. Meanwhile you ship on Tuesday and again on Thursday, and the last pentest describes a product that has since changed twice.
Test on your cadence. Answer with evidence.
01
Industry overview
SaaS has a security problem that is also a revenue problem, and the two are the same conversation.
Multi-tenancy means every customer's data lives in the same system, separated by application logic rather than by physical boundaries. That is an efficient architecture and a concentrated risk: a single authorisation failure does not expose one account, it potentially exposes all of them. Tenant isolation is the one thing that cannot break. At the same time, the sales motion has changed.
Enterprise buyers now run technical due diligence as standard. A questionnaire, a SOC 2 Type II request, evidence of penetration testing, sometimes a call with the prospect's security team. For a growing SaaS company, security has moved from a cost centre to a gate on the pipeline.
And the engineering cadence makes both harder. Continuous deployment means the application that was assessed in March is not the application running in June. A point-in-time report ages in weeks.
02
Security challenges
- R01
Tenant isolation is a single point of catastrophic failure.
Cross-tenant access is the finding that ends companies rather than embarrassing them. It is also structurally hard to test, because it requires holding sessions in two tenants simultaneously and attempting to cross, something single-session scanning cannot do at all.
- R02
Authorisation complexity grows with the product.
Roles, permissions, workspaces, projects, shared resources, guest access, API tokens with their own scopes. Every feature adds a permission interaction, and the interactions are where authorisation fails.
- R03
The API is a primary interface.
Customers integrate directly. Partners build on it. The mobile app uses it. Object-level authorisation across that surface is the dominant risk class, and endpoints that no UI calls are the least likely to have been reviewed.
- R04
Deployment velocity outruns assessment.
Weekly or daily releases against annual or quarterly testing.
- R05
Security questionnaires arrive without warning.
A prospect asks for evidence, and the answer determines whether the deal progresses this quarter.
- R06
Small teams carrying enterprise expectations.
A ten-person engineering organisation is asked to demonstrate the security posture of a company ten times its size.
03
How AIPTx helps
- Stage 1
Tenant isolation tested by crossing it.
Configure accounts in separate tenants and the agent attempts cross-access. Sessions are maintained across the run, roles are cross-tested against each other, and the finding you want to know about (one tenant reaching another's data) surfaces because both sessions are held at once and compared.
This is the single most important capability on this page. A scanner holding one session cannot find it, which is why it survives in production far longer than it should.
- Stage 2
Authorisation across the whole permission model.
Web Application SecurityConfigure users at each privilege level (owner, admin, member, guest, service token) and the agent cross-tests. IDOR and horizontal and vertical privilege escalation are covered as an access control class, and access control is one of the seven vulnerability classes with 35+ active tests behind it.
- Stage 3
The API tested from the contract.
API SecuritySupply an OpenAPI or Swagger specification and every declared endpoint, method and parameter is tested, including the ones no interface calls. GraphQL is supported with schema introspection, gRPC with proto files.
- Stage 4
Testing that runs where you already work.
Continuous Security ValidationQuick Scans run 15–30 minutes on pull requests through GitHub Actions, GitLab CI or Jenkins, with the option to fail a build on a severity threshold. SARIF puts findings in the editor and the pull request. Jira and Linear receive tickets; Slack and Teams carry alerts.
- Stage 5
Evidence you can send to a prospect.
Reports export as PDF, HTML, JSON, CSV and SARIF, with control mapping for SOC 2, ISO 27001, GDPR, PCI DSS, NIST and CIS, an executive summary, technical detail and trend comparison against previous assessments.
- Stage 6
Fixes verified.
Retest re-runs the specific exploit. The finding moves to fixed when the attack stops working, with retest history attached, which is exactly the artefact a diligence process wants to see.
04Features & Solutions
Relevant features and solutions
Multi-tenant and multi-role authenticated testing: cross-account and cross-tenant access attempted rather than assumed.
Two tenants are held at once and each is pointed at the other's data. Isolation that holds in the query layer and leaks through a reporting endpoint is only visible from that comparison.
Access control coverage: IDOR, horizontal and vertical privilege escalation, 35+ active tests.
Horizontal covers one user reaching a peer's records; vertical covers a member reaching an owner's function. Both are attempted against the roles you configure rather than read off the permission matrix.
Full authentication support: bearer, basic, cookie, custom headers, OAuth2/OIDC authorisation code flow, scripted login with token extraction, session maintenance and re-authentication.
Sessions are maintained and re-established as they expire, so a long assessment does not quietly become an unauthenticated one halfway through.
Session and JWT security: fixation with regeneration verification, timeout validation, algorithm_none, weak secrets, expired tokens, missing claims.
In most SaaS architectures the token is the tenant boundary, which makes a weak secret or an unchecked claim a multi-tenant problem rather than a session one.
API testing: REST via OpenAPI or Swagger, GraphQL with introspection, gRPC with proto files.
Spec-driven, so every declared endpoint is exercised, including the ones no front-end calls and nobody remembers shipping.
CI/CD integration: GitHub Actions, GitLab CI, Jenkins, with severity-threshold gating.
A Quick Scan fits inside a pull request, and the threshold decides what fails the build rather than what gets filed for a sprint that keeps moving.
Developer-native delivery: SARIF into the editor and pull request; Jira and Linear for the backlog.
The finding arrives where the fix happens. A vulnerability that has to be copied out of a PDF is a vulnerability that waits.
Business logic testing: Standard mode; race conditions and multi-step chains in Deep mode.
Trial extensions, seat counts, plan downgrades and usage limits are all enforced in application logic, which is exactly the class no signature matches.
SOC 2 control mapping, plus ISO 27001, GDPR, PCI DSS, NIST and CIS, with gap analysis.
The evidence an enterprise deal asks for, produced by testing you were running anyway rather than assembled in the week the questionnaire arrives.
Retest and status lifecycle: open, fixed, accepted, false_positive, attributed and timestamped.
A finding closes when the exploit stops working, and the record of who accepted what, and when, is still there for the audit that asks about it two quarters later.
05
Benefits
- The catastrophic finding gets tested for.
- Tenant isolation, tested by attempting to cross it, on every assessment rather than once a year.
- Security stops gating the sales cycle.
- A current report with control mapping and retest history answers the questionnaire in an afternoon instead of a fortnight.
- Testing matches your release rate.
- Findings arrive in the pull request while the developer still has the context, which is also when the fix is cheapest.
- A small team performs like a larger one.
- Validation removes triage; the engineering time goes to fixing rather than investigating.
- Evidence accumulates.
- Trend comparison across assessments turns a series of reports into a demonstrable trajectory, which is what a diligence process is actually assessing.
- SOC 2 evidence generated per run.
- Rather than assembled in the weeks before an audit window.
06
Use cases
Enterprise security questionnaire.
A prospect asks for evidence of testing. Run a Standard assessment, export the report, attach the control mapping.
SOC 2 audit preparation.
Deep assessment with control mapping and retest history for the evidence pack.
Pull request gating.
Quick Scan on every PR, build fails on critical, everything else becomes a ticket.
New permission model rollout.
Roles or sharing rules changed, verifying the new model holds across every combination.
Public API launch.
Spec-driven assessment of every declared endpoint before customers start building on it.
FAQs
Can you actually test tenant isolation?
Yes, and it is the reason multi-account configuration exists. Set up accounts in separate tenants, and the agent attempts cross-access while holding both sessions. Cross-tenant findings only surface when a tool can compare what two identities reach. A single-session scanner is structurally incapable of finding them.
How does this fit continuous deployment?
Quick Scans run 15–30 minutes and are built for a pull-request gate. Standard assessments run against release candidates, Deep runs before an audit or a major release. Findings arrive as SARIF in the pull request and as tickets in Jira or Linear.
Will the report satisfy an enterprise security review?
Reports include an executive summary, technical detail, remediation guidance with code examples, control mapping for SOC 2, ISO 27001, GDPR, PCI DSS, NIST and CIS, and trend comparison against previous assessments, in PDF, HTML, JSON, CSV and SARIF.
Does it help with SOC 2?
Findings map to SOC 2 controls with control assessment and gap analysis in reports, and retest history evidences remediation. That supports a SOC 2 programme, the certification itself involves organisational controls well beyond application testing.
Do we need an OpenAPI spec?
It improves coverage significantly, because a spec declares endpoints no interface calls and those are the least-tested part of most APIs. Without one, testing works from the base URL and endpoints discovered in traffic and client bundles.
Can we test before every release without slowing down?
Yes. That is what the Quick tier is for. It covers the OWASP Top 10, exposed services, known CVEs and misconfiguration, and explicitly does not attempt business logic or chain testing, because that needs session state and time. Depth goes on release candidates instead.
How do you handle API tokens and service accounts?
As authentication types. Bearer tokens and custom header schemes are supported, and tokens can be configured as separate identities with their own roles, which means a token's effective scope can be tested rather than trusted.
How do you keep real customer data out of a test?
By testing with accounts you provision for it. The agent works as the identities you supply, creates its own records where it can, and prefers proving access by reading a single object over modifying anything. Where a cross-tenant check does reach another tenant's data, that is the finding, and the returned values are redacted in the report rather than stored.
The engine behind it
Test the thing that would end the company
Tenant isolation, authorisation and API coverage, on your release cadence, with evidence you can forward to a prospect.
Runs in CI · No credit card required
Security testing for other sectors
Same engine, different threat model, different auditor. Each page covers the systems, regulations and attack paths that sector actually lives with.
Financial Services
Payment flows, lending decisions, account servicing, open banking APIs — the logic that handles money is the logic attackers study hardest. It is also the logic no signature database describes.
ExploreHealthcare
Patient portals, scheduling systems, clinical APIs, payer integrations: all of it holds data that carries a lifetime of consequence if it leaks, and much of it runs on systems that cannot be taken offline for a test.
ExploreGovernment
Benefits portals, licensing systems, tax filing, records access — services that must be open to everyone by design, running on estates that were often built decades apart and connected later.
ExploreManufacturing
Almost nobody breaks into a plant by attacking a controller. They arrive through a corporate account, a supplier portal, an ERP integration or an exposed remote access service, and then walk into a network that was designed for reliability, not for containment.
ExploreRetail
The vulnerabilities that cost retailers money are rarely exotic. A discount that stacks when it should not. A price accepted from the client. A gift card balance that survives a concurrent request. A loyalty account reachable from another customer's session.
ExploreTelecom
A single authorisation flaw in a subscriber portal is not one exposed account. At operator scale it is a data set — and the same flaw in a provisioning API is an operational one.
ExploreEducation
A department stood up a project site in 2019. A research group runs its own server. A faculty subdomain points at infrastructure that was decommissioned two years ago. None of it went through central IT, and all of it is reachable.
ExploreLegal
Clients do not retain a firm because of its document management system. They retain it on the assumption that what they share stays privileged — and increasingly they audit that assumption before instructing.
Explore