# AI pentesting for SaaS: multi-tenant testing with evidence

Source: https://aipentestservices.com/ai-pentesting-for-saas/
Publisher: Excession Labs (aipentestservices.com)
Last updated: 2026-11-09

AI pentesting for SaaS: what the lab's agents test in a multi-tenant product, how the two-tenant method proves cross-tenant findings, and what you receive.

> **Short answer:** AI pentesting for SaaS means the lab's AI agents test a multi-tenant product role by role and tenant by tenant. They cover tenants, roles, invitations, billing, exports, admin paths and releases. A cross-tenant finding counts only when it is read back from a second tenant's session. Excession Labs checks the evidence and writes the report.

AI pentesting for SaaS is a scoped test of a multi-tenant product, run by the lab's AI testing agents under rules that Excession Labs sets. The agents work through each role and each tenant in parallel. Excession Labs checks the evidence for each finding and writes the report.

A SaaS product serves many customers from one system, so the worst bug is one customer reaching another customer's data. A scanner with one login rarely finds that. The test needs several accounts, in several tenants, compared against each other.

## What does AI-assisted testing cover in a multi-tenant SaaS?

It covers the places where a tenant boundary or a role rule can fail. We scope the areas below with you. The first column is what the agents check, and the second is the method.

| Area | What the agents check | Method |
|---|---|---|
| Tenants | Can tenant A read or change tenant B's records by changing an identifier? | Replay A's requests with B's IDs, and the reverse |
| Roles | Can a member call admin functions? Can a viewer write? | Same request, one session per role |
| Invitations and membership | Can an invite be reused, redirected or accepted into the wrong tenant? | Create invites in each tenant and cross the tokens |
| Billing and entitlements | Can a lower plan reach a paid feature by calling the API directly? | Compare UI limits with API behavior |
| Exports and files | Does an export or download resolve a record by ID alone? | Request another tenant's report ID, read back the file |
| Admin and support paths | Can an ordinary user reach internal routes or flags? | Differential comparison of anonymous and signed-in callers |
| Integrations | Do API keys, webhooks and OAuth apps stay inside their tenant? | Use one tenant's key against the other tenant |
| Releases | Did the last release open a new path? | Scope the delta, then retest earlier findings |

The categories follow public guidance. The [OWASP Multi Tenant Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) describes tenant isolation as a design requirement. [API1:2023](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) covers object-level access, and [API5:2023](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/) covers function-level access. OWASP's [privilege escalation test](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation) is the manual version of the role checks.

## How does the two-tenant method prove a cross-tenant finding?

It proves the effect by reading the record back from the other tenant's session. You create two tenants with at least two roles each. The agents create test objects in each tenant, then replay in-scope requests from tenant A with tenant B's identifiers, once for every role.

A "success" response is not proof. A write counts when the changed record shows up through another session. A read counts when the response holds rows that belong to the other tenant.

Controls run next to each exploit request: a nonexistent identifier, a wrong record type, another account's token, and an anonymous call. If a control shows the first result was misleading, we downgrade or drop the finding. Controls that held are listed in the report, so a later fix does not break a protection that works.

> **Sample check:** This is a demonstration. It uses a fictional app, Harbor Notes Teams, and no real customer system was tested.
> 
> Tenant `t_acme` has an admin and a member. Tenant `t_globex` has the same. The agent asks for an export with a report ID that belongs to `t_globex`, using the acme member's session.
> 
> ```http
> POST /api/exports HTTP/1.1
> Host: app.example.com
> Cookie: session=
> Content-Type: application/json
> 
> {"report_id":"rpt_55120"}
> ```
> 
> The control, report `rpt_00000`, returns 404. If the export of `rpt_55120` returns `202` and the downloaded file holds `t_globex` rows, the finding is Observed, read back with the acme session. If the file is empty or the request is refused, the control held and the report lists it that way.
For the full test matrix, see the guide on [multi-tenant isolation testing](https://penetrationtestservices.com/guides/multi-tenant-isolation-testing/) and the [tenant isolation testing](https://penetrationtestservices.com/tenant-isolation-testing/) page on penetrationtestservices.com, which is also run by Excession Labs.

## What does the AI part do, and what does a person do?

The agents split the engagement into tasks and run them in parallel, one set per role in scope. Each tool they use is set to run on its own, wait for approval, or stay blocked. An agent may report a finding only if it links to evidence: the requests, the responses and the controls.

Excession Labs agrees the scope with you in writing, checks the evidence for each finding, and writes the report. The agents do not decide what is a finding. The [how it works](/how-it-works/) page lists the nine steps, and the [safety page](/safety/) covers the limits.

The agents do not find everything. Business-logic flaws that depend on how your customers use the product are the weakest area, and the page on [where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/) lists others. Say in the scoping call which flows carry the most money or data, so the scope puts effort there.

## What do you receive?

You receive a written report in HTML, PDF and Markdown, plus proof-of-concept scripts. It has these parts:

1. Project details: scope, assets and the severity scale (Critical, High, Medium, Low, each defined)
2. Executive summary with priority actions
3. Findings at a glance
4. One section per finding: description, impact, verified results, reproduction and remediation
5. Controls that held
6. Remediation plan
7. Limitations and open questions
8. Evidence index, with saved requests and responses

Findings carry an evidence label. "Observed" means we reproduced it. "Browser-observed" means we showed it in a real browser. Inferred paths are labeled separately, and open questions stay out of confirmed impact. The [example assessment](/example-assessment/) shows the layout with a labeled demonstration.

We can retest fixed findings. Whether a retest is part of a quote is agreed during scoping.

## How do you start?

Start with a short call, then a written scope and proposal. We test only with written authorization from the system owner. Prices are quoted after scoping, and we publish no price list. The [pricing page](/pricing/) lists what changes a quote.

Before the call, collect these:

- the environment to test, staging or production
- two tenants for the test, with at least two roles in each
- the role matrix and the features behind each plan
- a list of what changed since the last test, if you ship often (see [per-release testing](/per-release-testing/))
- how you will pass test credentials to us

The [authenticated web app testing](/authenticated-web-app-testing/) page covers accounts, sessions and MFA in more detail. If you want a small first test, [apply for a pilot](/pilot/). Pilot places are limited and reviewed by hand.

## Questions

### Do I need two tenants for the test?

Yes, for a multi-tenant product. Create two tenants for the test, with at least two roles in each. Without a second tenant, a cross-tenant read cannot be proven, and the report would have to label that path as inferred.

### Can the agents test with our real customer data?

No. Tests use test-owned accounts and records that are marked as test data. Staging with data that is not real is the usual choice. If production is in scope, the written scope says so and tighter limits apply.

### Is this the same as a SaaS compliance pentest?

The testing method is the same, but the report is not an attestation. Ask your auditor or customer what they need. We do not claim that any auditor will accept a report.

### What if we ship every week?

Scope the areas that changed. The per-release page explains how a scope delta works. We do not promise continuous or scheduled testing.

## Sources

- [OWASP Multi Tenant Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html)
- [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/)
- [OWASP API Security Top 10 2023: API5 Broken Function Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/)
- [OWASP Web Security Testing Guide v4.2: Testing for Privilege Escalation](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation)