skip to content
// trust

What happens to your code_

Limited beta · read-only GitHub access

// access

Read-only, scoped.

The GitHub app requests read access to code and metadata for the repositories you select. No write access, and no organisation-wide access unless you choose it.

// sandbox

One sandbox per run.

Your repository is cloned only inside an isolated, single-use sandbox, using a short-lived read token minted for that run; the sandbox ends with the run. What persists is the report, the artifacts and the run log — which can include excerpts of files the workflow read.

// retention

90 days, or less if you say so.

Reports, logs and artifacts are kept for 90 days per our privacy policy and deleted on request, or when you delete the project.

// models

Commercial APIs. Paid Scans include a Service-improvement license.

During a Scan, model traffic goes through OpenRouter; Midkernel records model/version on the run. Midkernel's policy is not to opt its OpenRouter usage into provider training programmes (that does not control downstream providers). For Scans paid with purchased credit packs, the Terms grant Midkernel a license to use Customer Content and Service data (reports, logs, artifacts, metadata) to improve and develop the Service (routing, ranking, evaluation, related models or systems). That is a rights/purpose grant; Midkernel does not currently operate a dedicated training pipeline. Third parties in the path (GitHub, AWS/compute, OpenRouter, model providers) may retain data under their own policies; Midkernel does not control that.

// provenance

Runs record what ran.

Each run records its workflow, profile, and the model and version that ran, and the report stays attached to the run's full trace. Pinning the complete input set — repository commit, workflow commit, sandbox image — is being finished across the platform and will be stated here when it is.

// network

Egress limits, being verified.

Sandboxes are designed to reach only what a run needs — the model provider and package registries. We are verifying the enforced egress rules before stating them as a control; until then, treat this as design intent, not a verified guarantee.

// people

Who can see what.

Reports are visible to the members of your workspace. Midkernel staff open a customer's run only for a support request you filed, and the access is recorded.

// who runs what
compute
AWS — isolated per-run sandboxes
hosting
Vercel
database
managed Postgres
models
commercial model providers, routed per profile
email
Resend
payments
native USDC on Base; direct deposits verified on-chain
analytics
Vercel Web Analytics (cookieless)
scheduling
Cal.com

The legal list of subprocessors lives in the privacy policy and DPA.

// disclosure

Found something in Midkernel?

security@midkernel.com · disclosures are read promptly and fixes are published in the changelog.

// what we don't have yet

No SOC 2 or ISO 27001 report yet, and no independently verified egress or staff-access audit. What we do instead: this page, honest about what is and is not in place, and the trace kept on every run. When a compliance report exists it will be linked here.

// faq
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.

Can I run Midkernel in my own cloud?

No hosted private-cloud option. A self-hosted runner is how the platform is designed to run anywhere you like; that repository is not public yet.

Run one on your repo.

Limited beta · read-only GitHub access