The scenario
Your team ships a new order history page next week. Staging runs athttps://staging.shop.example.com. The payments and admin areas belong to another team and must stay out of the test. You have two test accounts, one in each tenant, and you want proof for every issue, not a list of guesses.
Prerequisites
- A staging deployment you’re authorized to test, and access to its DNS records to verify the domain.
- Workspace admin rights, or an admin who can verify the domain for you.
- Two test accounts in the app, in different tenants.
- A Git provider connection with the app’s repository, if you want CloudThinker to draft the fix.
Walkthrough
1
Register the app and verify the domain
Click Cyber in the sidebar, then Register an App (or New app if you already have apps). Enter an App name, the Application URL, and Web application under What to test. Under Target ownership, click Create DNS proof, add the TXT record at your DNS provider, and click Check again.What you should see: Target ownership shows Verified.
2
Add both test users
On Access, click Add test user twice. Give each a clear Identity label and Tenant, for example
customer-a in Tenant A and customer-b in Tenant B. With two users, Cyber can test whether one can reach the other’s data.3
Pick Safe and save without running
On Start, check Coverage status and click Show limited checks to see what this run can’t test. Under Testing intensity, select Safe, which sends only read requests. Click Run later, because setup has no scope step.
4
Set the scope
In the app header, click Settings, then Manage scope under Scope:
Click Save scope. A path that matches both lists is excluded.What you should see: Scope saved, and the Scope summary counts your rules instead of reading Full target.
5
Run the pentest
Click Run pentest in the app header, check that Safe is selected, and click Run Safe pentest. The run can take up to three hours and uses credits. You can leave the page and check the app’s Runs tab later.What you should see: a run marked Running, with a live timeline of what Cyber is testing.
6
Read the proof
When the run shows Success, open the Findings tab. Confirmed lists attacks that reproduced. Open one, for example
customer-b reading customer-a’s order through /api/orders/{id}. Under API evidence, you see the exact request and response that prove it, with secrets redacted.To ask about a lead under Needs verification, open its ⋯ menu and choose Chat with finding:7
Fix and retest
On the confirmed finding, click I’m working on this, then Create PR with agent. In the chat that opens, say what you want:Every change an agent makes goes through your workspace’s Approvals first. On the default Auto · Rules + AI · Ask me mode, AI judgment can let a safe change run without asking — and an Allow Rule can too, once CloudThinker turns on Rule enforcement for your workspace. Choose Manual to approve every change yourself.Review and test the pull request, merge it, and deploy to staging. Then click Ready for retest and run the pentest again.What you should see: if the proof no longer works, the finding moves to Verified fixed. If it still works, the finding stays open.
What made this work
- Ownership came first. Cyber tests only a domain you’ve proved you control. See Run a pentest.
- Scope kept other teams safe. Include and exclude paths kept payments and admin out of the run.
- Two identities found the real bug. A cross-tenant leak only shows when Cyber can sign in as two customers.
- Every finding came with proof. The request and response let you replay the attack yourself. See Triage findings.
- A retest closed the loop. The next run, not a checkbox, moved the finding to Verified fixed.
Next steps
Run a pentest
More access options, intensities, and recurring schedules.
Triage findings
Work through proof, fixes, dismissals, and retests.