See who can reach what
You confirm an access matrix. Stakari checks every cell against the running app and tries to cross from one tenant into another.
What it tests
- Define test roles and at least two tenants for isolation tests.
- Build an expected access matrix of resource and action by role, and confirm it before it is used.
- Run each confirmed matrix cell at the API level and compare actual access to expected.
- Try to read, list, update, search, export and delete a tenant A resource as a tenant B user.
- Test privilege escalation, such as a user changing their own role or tenant.
- Show results as a role-by-resource matrix, with findings grouped by root cause.
How a run goes
- Step 1
Define roles and tenants
Add test roles with credentials and at least two tenants.
- Step 2
Confirm the matrix
Review the expected access matrix before it is used as an oracle.
- Step 3
Read the mismatches
The role-by-resource matrix highlights where access did not match.
Coming soon
- UI access checks per role: navigation and visible controls, including where the UI hides a control the API still allows.
Explore the other modules
- Web app testingDrive your app in a real browser, one isolated session per role.
- API testingPostman or OpenAPI: contracts, bad input, auth, idempotency, concurrency.
- Workflow testingChain UI, API and state checks, then check everything agrees.
- AI agent testingMulti-turn attacks with canary and state oracles.