For teams shipping authenticated applications, APIs and multi-tenant services. We scope the workflows and trust boundaries that matter to your product.
GET /ws_A/members403 ForbiddenGET /ws_A/settlements403 ForbiddenGET /ws_A/invoices200 OK
ZF-0163-01Critical
Workspace B can read Workspace A invoices
Token
Workspace B, member
Request
GET /ws_A/invoices
Response
200 OK
Human-verifiedAI-found ZF‑0163‑01 2026‑09‑28
Same application. Separate authority.
Illustration: two workspaces share one application, separated by a tenant boundary. Requests made with Workspace B's member token try to reach Workspace A. Two are refused with 403. One, GET /ws_A/invoices, returns 200 OK with Workspace A's invoices; a researcher records it as finding ZF-0163-01, Critical, human-verified.
ReportCover and question1/11
Start with a change. Ask the right question.
Three illustrative scenarios. They explain the work; they are not customer findings or promised outcomes.
01Multi-tenant SaaS
New workspace. Same isolation promise.
Do the agreed roles and workflows keep each customer's data separate?
Situation
You are introducing shared workspaces, invitations or a new tenant model.
Focus
Selected tenant boundaries, role transitions and API authorisation, using designated test accounts.
Output
Findings tied to roles, affected workflows and demonstrated impact, not endpoint counts.
Illustrative request
# Workspace B token, Workspace A resource
GET /v1/workspaces/ws_A/invoices HTTP/1.1
Authorization: Bearer ██████████████
HTTP/1.1 200 OK
02Identity and permissions
More permissions. Clearer boundaries.
Does the application enforce the authority intended for each account state and role?
Situation
You are changing account recovery, team administration or privileged access.
Focus
Registration, session, recovery and permission-change flows, including the API operations behind them.
Output
Reproduction context and access assumptions that show engineering exactly which boundary failed.
Illustrative request
# Member promotes self to admin
PATCH /v1/members/me {"role":"admin"}
HTTP/1.1 200 OK
{"role": "admin"}
03Releases and integrations
A new connection. A new set of assumptions.
Are identity, state and permission assumptions consistent across the workflow?
Situation
You are launching a sensitive workflow or connecting another service.
Focus
Selected state transitions and integration boundaries, within the operations explicitly authorised.
Output
Evidence and limits explained against the release decision your team has to make.
Illustrative request
# Two approvals sent at the same moment
POST /v2/refunds/RFD-20417/approve
1 200 OK {"status": "paid"}
2 200 OK {"status": "paid"}
Know what is included. Agree the rest in writing.
Applications & APIs
Candidate scopeNamed URLs, APIs, versions and selected workflows.
Confirm before testingOwnership or testing authorisation; third-party exclusions.
Accounts & roles
Candidate scopeDedicated accounts for the relevant users and tenants.
Confirm before testingAvailable roles, test data and permitted account actions.
Environment
Candidate scopeAgreed staging or another designated environment.
Confirm before testingProduction checks need explicit agreement on actions and limits.
Operational limits
Candidate scopeDefined testing windows and an escalation contact.
Confirm before testingDisruptive checks and destructive operations are never assumed.
Delivery & retest
Candidate scopeScope summary and human-verified findings.
Confirm before testingTiming, report requirements, retest scope and terms.
Coverage depends on the agreed scope and access. Untested or excluded areas are named; they are never treated as evidence that a system is secure.
Research can be autonomous. Delivery has an owner.
01
Investigate
Agents explore within scope and collect observations.
AI-supported
ZF-0147-02
Severity
Critical
Class
CWE-639
CVSS 3.1
9.6
Merchants can read each other's settlements
Impact With a single API key, the settlements and IBANs of 1,284 merchants could be read.
Evidence
GET /v2/merchants/MRC-58213/settlements HTTP/1.1
Host: api-staging.northwind-pay.example
Authorization: Bearer ██████████████████
Critical
02
Verify and approve
A researcher reproduces it and judges impact and uncertainty.
Review desk
Human-verifiedAI-found ZF‑0163‑01 2026‑09‑28
03
Deliver
Findings, fixes and the limits of the work are explained.
Your team
Open questionInsufficient evidence stays an open question, never a confirmed finding.
Built for prioritisation. Ready for engineering.
LeadershipScope, material findings and business context.
EngineeringAffected components, reproduction and remediation.
Follow-upCoverage limits and retest results, where agreed.
01
Context and affected scope
Environment, component, roles and preconditions.
02
Supporting evidence
Expected versus observed behaviour, with the request and response.
03
Impact and uncertainty
Demonstrated consequences and the limits of the work.
04
Remediation and retest
Guidance for the fix and its follow-up status.
Controlled research resources.
Agents use designated resources for approved scenarios. They never get unrestricted access to your systems.
01
Owned DNS records
Records on our own domains support agreed validation scenarios.
02
Designated test servers
Assigned servers host controlled test components inside the engagement boundary.
03
Test identities
Dedicated email accounts drive registration, verification and sign-in flows you agreed to.
Straight answers
What do you need from our team?
A short product description, the assets and workflows in scope, the roles involved, a test environment and a target date. Never send credentials in a first message.
Can you work against production?
Only where your written scope allows it, for agreed checks with agreed limits. Staging is preferred.
Do you test GraphQL and gRPC?
Yes, where they are in scope. We agree the operations and the roles to exercise before anything runs.
Bring your scope. Let's plan the Countermind.
Thirty minutes with a Zaaf researcher. You bring one scope; we show you what a Countermind would look at first.