// platform

From repository to report in one run_

Connect a repository, pick a workflow and a profile, run it in an isolated sandbox, read the report and the complete trace. From the app, the CLI or the API.

Talk to us See the bench

Read-only GitHub app · first run on us · no card

Midkernel run report: findings on the left, the run log on the right — // example run

// how it works

Connect, pick, run, read.

// 01 Connect

Install the read-only GitHub app on one repository or an organisation. The app has no write access.

The GitHub app requests read access to code and metadata for the repositories you choose. Nothing else. Organisations can install it once and select repositories later.

// example

$ midkernel connect acme/api

// 02 Pick

Choose a workflow from the registry and a profile — low, balanced or max. The price in credits is shown before you start.

Workflows show their bench row and sort by score as results land. Open one to read its manifest and instructions before you run it. Profiles set the models, depth and budget; the credit price updates as you change them.

// example

$ midkernel run acme/api --workflow asvs/auth-review --profile balanced

// 03 Run

The run executes in an isolated, single-use sandbox and streams its log. Close the tab; it keeps going.

Sandboxes are single-use and isolated. Network egress is limited to the model provider and package registries unless the workflow declares another host in its manifest — visible before you run. Resource class and timeout come from the profile.

// example

$ midkernel runs watch 8f3a2c

// 04 Read

Path, root cause, proof, severity with the reason, fix — and the trace behind each finding.

Reports are addressable: share a link with a colleague, export SARIF for your code-scanning tools, download every artifact the run produced.

// example

$ midkernel report 8f3a2c --format sarif

// profiles

Choose how hard it looks.

Profiles are starting points. Change the model, raise the depth, narrow the scope to a directory, cap the budget — the estimate updates before you launch, and the invoice matches it.

profile	models	depth	typical credits	use it for
`low`	fast	one pass	2–4	pull requests, triage
`balanced`	leading	standard, one verification pass	5–10	repository audits
`max`	strongest	deep, repeated passes, verification	12–25	releases, bounty targets

Typical credits for a mid-sized repository. The exact price is shown before every run.

// the report

A report you can argue with.

// example

CRITICALSQL injection via unsanitised q paramapi/search.ts:42

HIGHJWT accepted with alg=noneauth/verify.ts:18

MEDIUMRate limit bypass via X-Forwarded-Formw/limit.ts:7

pathfile, line, and the call chain that reaches it

root causewhy the code is wrong, not just where

proofa reproducing input or transaction when the workflow produces one

severitywith the reasoning, so you can disagree

fixa suggested change, never auto-applied

the full logevery tool call and model turn behind the finding

// artifacts

· run log (JSONL)
· report (Markdown, HTML, PDF)
· SARIF
· proof-of-concept files the workflow produced
· the pinned workflow source
· the exact profile that ran

// compare

Run two workflows on the same repository.

Every run is addressable. Start a second workflow, or the same one on max, against the same commit, and the report page shows both side by side: findings in common, findings unique to each, credits and time. This is the comparison the bench cannot do for you — on your code.

// cli and api

Everything the app does, the CLI does.

// example

$ npm i -g midkernel
$ midkernel login
$ midkernel run acme/api --workflow asvs/auth-review --profile max --wait
$ midkernel report 8f3a2c --format sarif > results.sarif

A CLI and a REST API are how hosted runs will plug into a pipeline. There is no npm package or API docs host for them yet. Runs, reports and artifacts are designed as plain JSON and files so a pipeline can gate on the result when that ships.

// limits

repository size	up to 2 GB
run time	up to 60 minutes on low and balanced, 120 on max
concurrency	2 runs at once on pay as you go, 5 on Pro, 10 on Team
retention	90 days, a year on Pro and Team, deletable sooner
languages	any; each workflow declares what it supports

Limits are shown before every run.

// later

// laterwatch — a workflow on every pull request · research — engagements with a private benchmark for your codebase

// faq

Do you store my code?

We don't keep a copy of your repository. Each run clones it into a fresh sandbox that is destroyed when the run ends. The report and the run log — which can include excerpts of files the workflow read — are kept for 90 days (a year on Pro and Team); you can delete them sooner. Details on the trust page.

Which models do you use?

Leading models from the major providers, chosen per profile and shown on every run. You can change the model before you start.

What does a run cost?

A whole number of credits, shown before you start. 1 credit is $1. Typical runs are a few credits on low and a dozen or two on max. See pricing.

Can I put it in CI?

Not yet. The platform is designed so a CLI and an API can start runs from any pipeline. Continuous runs on every pull request, with comments, are further out. Write to hello@midkernel.com if you want that workflow.

Does it need write access?

No. The GitHub app requests read access to code and metadata only. Continuous runs, when they ship, will comment on pull requests through a separate, optional permission.

Can I run it on a private repository?

Yes; that is the normal case. The sandbox sees the repository only for the duration of the run.

What if a run fails?

Runs that fail before analysis begins are not charged. Runs that stop early are charged for what ran and say so on the invoice.

Run one on your repo.

Talk to us See the bench

Read-only GitHub app · first run on us · no card