Stakari is in development and opening to pilots soon. Items marked Coming soon are planned, not available.

Stakari
Opening to pilots soon

Testing web apps, backend APIs, agentic systems, SaaS apps and workflows.

Describe a feature in plain English or upload your SRS. Stakari plans the tests and runs them across web, APIs, roles, workflows and AI agents. Reproduced bugs with evidence arrive in Slack and GitHub.

Request pilot accessSee how it works
Shop staging / FindingsIllustrative example

Finding

Refund above the order amount is accepted

Severity
High
Module
API
Status
Open

Verified: failed in 2 of 3 clean re-runs

Observed
POST /refunds returned 201 for an amount larger than the order.
Expected
The request should be rejected with a 4xx status.

Reproduce

curl -X POST "$BASE_URL/refunds" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"order_id":"$ORDER_ID","amount":150}'

Evidence: request and response pair, secrets redactedSent to Slack and GitHub

Where testing usually breaks down

Three gaps we built Stakari to close.

  • Manual passes are hard to repeat across roles and tenants.

    Stakari runs each role in its own browser context and checks results against the access matrix you confirmed.

  • AI-driven tests can pass or fail by chance.

    Stakari judges with deterministic checks first and re-runs failures in clean contexts before it reports them.

  • A bug report without steps costs developer time.

    Every finding says what happened, what was expected and how to reproduce it.

From a sentence to a bug you can fix

Stakari handles the planning, the running and the checking. You stay in control of what runs.

You approve the plan before anything runs

Ask for a test in plain English or upload your SRS. Stakari turns it into scenarios, each with a risk class, the roles involved and an expected outcome.

  • See the credit estimate as a range before you approve.
  • Remove or edit scenarios first. Nothing runs until you say so.
  • Destructive and adversarial scenarios need an extra confirmation.
Plan: refund flow in stagingIllustrative example
Plan: refund flow in staging
ScenarioRisk
Support agent refunds a delivered orderR1 creates data
Refund above the order amount is rejectedR1 creates data
Same refund submitted twiceR3 adversarial
Refund history is read-only for viewersR0 read-only

Estimated credits: 40 to 60

Risk classes: R0, R1, R3

R3 scenarios need confirmation

See who can reach what

You confirm an access matrix of roles and resources. Stakari checks every cell against the running app, including attempts to cross from one tenant into another.

  • Results appear as a role-by-resource matrix with mismatches highlighted.
  • Findings with one root cause are grouped and reported together.
  • Role tests use dedicated test accounts and synthetic data.
Access matrixIllustrative example
Access matrix
RoleRead invoiceRefundChange role
AdminAllowAllowAllow
MemberAllowDenyDeny
Tenant B memberAllowedDenyDeny

Tenant B member, Read invoice: Expected deny, observed allow

How it works

Five steps, from a request to a fixed bug.

How a request flows through Stakari

  1. 01DescribePlain English or your SRS, a Postman collection or an OpenAPI spec.
  2. 02PlanScenarios with risk classes and a credit estimate. You approve.
  3. 03RunnerLocal, CI or cloud. Policy is enforced on every request.
  4. 04ExecuteWebAPIAgentOne executor per target type. Roles and workflows build on them.
  5. 05VerifyDeterministic checks first. Failures re-run in clean contexts.
  6. 06FindingsEvidence and reproduction steps for every bug.
  7. 07DeliverDashboardSlackGitHubVerified findings go where your team works.

Retest: Re-runs only the scenarios behind a finding.

In development Being built now for the first pilots.Coming soon Planned. Not available yet.

  1. Describe or upload

    • Ask for a test in plain English, or upload an SRS or PRD.
    • Review the flows Stakari extracts, edit them, and confirm what is unclear before anything runs.

  2. Approve the plan

    • The plan lists each scenario with its risk class and a credit estimate shown as a range.
    • Nothing runs until you approve, and you can remove or edit scenarios first.

  3. Run it where it fits

    • Run on your machine, in dev or staging from CI, or in production safe mode.

  4. Read verified findings

    • Findings come with evidence and reproduction steps, in a plain-language view and a technical view.

  5. Retest after the fix

    • Retest a finding with one action. Stakari re-runs only the scenarios behind it.
    • Scenarios behind verified-fixed findings join your regression set automatically.Coming soon

Five modules, one report

Each module covers a kind of target. Findings from all of them land in the same place.

  • Web apps

    In development

    Drives your app in a real browser, one isolated session per role, and checks results at defined points.

    Example finding

    The submit button stays active after a failed request, so a second click sends a duplicate.

    Coming soon: Accessibility checks per page and mobile viewport emulation.

  • Backend APIs

    In development

    Reads a Postman collection or an OpenAPI document, then tests contracts, bad input, authentication, repeated requests and parallel requests.

    Example finding

    POST /refunds accepts an amount above the order total.

    Coming soon: HAR traffic as an input, and Postman scripts.

  • Multi-role and multi-tenant SaaS

    In development

    Checks every cell of the access matrix you confirm, and tries to cross from one tenant into another.

    Example finding

    A user in tenant B can read an invoice created in tenant A.

  • Workflows

    In development

    Chains UI actions, API calls and state checks, then checks the end state and that UI, API and stored values agree.

    Example finding

    An order shows as paid in the UI while no payment record exists.

    Coming soon: Webhook triggers.

  • AI agents

    In development

    Runs multi-turn attacks against an agent endpoint or chat widget, and checks for planted canary values and state changes.

    Example finding

    A canary value planted in tenant A appears in a reply to tenant B, reported with its success rate and full transcripts.

    Coming soon: MCP server and tool-description testing.

Why you can trust the findings

One wrong report costs more trust than a missed bug wins, so Stakari verifies before it reports.

EvidenceIllustrative example
  1. 1Log in as support agent
  2. 2Open order
  3. 3Submit refund above order amount
  4. 4Response: 201 CreatedFailed check
Request
POST /refunds
Response
201 Created

What a verdict means

Illustrative summary of the verdict rules

  • VerifiedA deterministic check failed and the failure reproduced in at least 2 of 3 runs.
  • FlakyThe results were inconsistent.
  • UnreproducedThe failure did not repeat.
  • Needs reviewOnly a model's judgment flagged it.

  • Deterministic checks first

    • Status codes, schemas, page content, invariants and canary values decide the result. A model's judgment is a secondary signal.
    • A model's judgment alone never produces a Verified finding.

  • Failures re-run in clean contexts

    • A failing scenario runs again in a fresh browser context or with fresh data before it is reported.

  • Steps you can follow

    • API findings include a curl command with secrets replaced by placeholders.
    • Web findings include ordered steps and the Playwright trace.

  • Evidence, with secrets removed

    • Web findings carry video, step screenshots, console output and network records. API findings carry full request and response pairs.
    • Secrets and tokens are redacted from stored evidence.

  • False positives are tracked

    • Mark a finding as a false positive with a reason. Stakari tracks the rate per module.
    • Suppression rules for repeat false positives.Coming soon
    • Suspected causes and fixes are labeled as hypotheses, not facts.

Safe by design

Safety rules are enforced where requests are sent, not only when tests are planned.

  • Ownership verification

    Before the first run from a Stakari-hosted runner, you prove you own the target with a DNS TXT record or a token served at a well-known path.

  • Environment policies

    Each environment has a policy and a host allowlist. The runner refuses anything outside them, including through redirects.

  • Read-only production safe mode

    In production, only read-only scenarios run by default. Allowing more takes an Admin and is recorded in the audit log.

  • Kill switches

    Stop a single run, a whole organization, or everything, and outgoing requests stop promptly.

  • Content under test is untrusted

    Pages, API responses and agent replies are treated as data. Instructions found in them cannot change the approved plan.

  • Destructive and adversarial scenarios need explicit confirmation when you approve the plan.
  • Every outbound request is written to an audit log.
  • Stakari warns you to use test accounts, not real user accounts.
  • Automatic detection of live payment keys and real personal data in test inputs.Coming soon

Runs where your app runs, fits how you ship

The same runner works on a laptop, in CI, in the Stakari cloud and inside your network.

Use it where you work

  • Dashboard

    A setup wizard a non-technical person can finish, then plans, runs, findings and the evidence viewer.

  • CLI

    Log in, plan and run from the terminal, and fail the build above a severity you choose.

  • CI

    A GitHub Action triggers a run and waits for the result.

  • Slack

    Verified findings go to the channels you configure.

TerminalIllustrative example
stakari run --env staging --fail-on highPlan approved. Running 12 scenarios.1 verified finding (high): refund above the order amount is acceptedExit with findings above threshold.

The CLI takes --env, --module, --scenario, --fail-on and --json.

Where it runs

Local
Test a target on localhost. Results stay on your machine unless you choose to upload them.
Dev and staging
Run from CI or from the Stakari cloud, triggered by deploy events.
Customer network
A Docker image and a CLI run inside your network and only make outbound connections.
Production safe mode
The runner refuses any scenario your environment policy does not allow.

How it fits your workflow

GitHub pull request checks
A successful staging deploy triggers a run, and the result is posted back as a PR check.
GitHub Action and CLI
Fail the job when findings at or above a severity you choose exist.
Slack
Verified findings go to the channels you configure, and the thread updates when status changes.
Jira and Linear
Create and link issues, and update them when a finding's status changes.Coming soon

GitHub, Slack, Jira and Linear are named only to describe what Stakari connects to. They are not partners.

Credits, simply

Runs use credits. You see the estimate before you approve, and you set the limits.

  • Estimate first

    The plan shows estimated credits before approval. Approval reserves them, and the final charge settles when the run ends.

  • Hard cap in pilots

    Pilots run on a hard credit cap, and a run does not start if the balance is too low.

  • Refunds for platform failures

    Credits are refunded automatically when a run fails because of Stakari infrastructure.

  • Prepaid credits, later

    Later, you buy prepaid credit packs when you need more.Coming soon

Questions

Straight answers, including what is not ready.

Does Stakari touch production by default?

No. By default a production environment only allows read-only scenarios. Allowing more takes an Admin and is recorded in the audit log.

What data does Stakari store?

Only what the product needs: test results, evidence and configuration.

Credentials are encrypted at rest, never shown after entry, and never sent to a language model.

Secrets and tokens are redacted from evidence. Use test accounts and synthetic data, not real customer data.

You can delete your project data and evidence.

Is my data used to train models?

No. Stakari does not use customer data to train or fine-tune models.

What is available today, and what is coming soon?

Stakari is in development and opening to pilots soon. Items marked In development are what the product is being built to do, and details may change as we learn from the first pilots. Nothing is generally available yet.

Items marked Coming soon are planned and not available. They include Jira and Linear issues, accessibility checks, webhook triggers and suppression rules.Coming soon

Do I need to write test scripts?

No. Describe what to test in plain English, or upload an SRS or PRD, and approve the plan Stakari proposes.

Will I get false alarms?

Failures are re-run in clean contexts before they are reported, and by default only Verified findings go to Slack. Some wrong reports are still possible. Mark them as false positives and Stakari tracks the rate.

What happens if a run fails because of a Stakari problem?

The credits are refunded automatically.

Who is behind Stakari

Stakari is being built by one founder.

Ndifoin Hilary, FounderBamenda, Cameroon

Find out what broke before your users do

Stakari is in development and opening to pilots soon. Tell us what you want to test and we will get in touch about a place in the first pilots.

Request pilot accessSign in
  • Set up with a staging URL and test accounts. No test scripts to write.
  • You approve the plan and see a credit estimate before anything runs.
  • Pilots run on a hard credit cap.

Coming soon

Stakari is in development and opening to pilots soon. Sign-in will open here once the app is live. To try it first, request pilot access.

Request pilot access