What happens to your code during a run
From the moment you press run to the moment the sandbox is destroyed: where your repository goes, who can see it, and what is left afterwards.
The question every security engineer asks before connecting a repository is not "what will you find?" It is "where does my code go?" This post answers it in order, from the button to the report. The trust page states the same facts as a list; this is the narrative.
Before the run
You install the GitHub app on one repository or an organisation. The app asks for read access to code and metadata and nothing else. It has no write access, and there is no path in the product that would use it — pull request comments, when continuous runs ship, will be a separate permission you can decline.
You choose a workflow and a profile. Before anything starts, the app shows you the workflow's pinned commit, the tools and scope from its manifest, any extra network hosts it declared, the model the profile will use, and the price in credits. Nothing runs that you did not see on that screen.
During the run
Pressing run creates a sandbox: an isolated, single-use environment that exists for this run only. The repository is cloned into it at the commit you chose. The workflow's files are copied in at their pinned commit. The model is reached through Midkernel's commercial API accounts; we do not opt in to any provider training programme, and the model sees your code only as part of this run.
Inside the sandbox the agent can do exactly what the manifest allows: read the files in scope, search them, run tests if the workflow declared that tool, make HTTP requests to the code it is auditing. Network egress is limited to the model provider and package registries unless the manifest declared another host — and you saw that host before you started.
Every tool call and model turn is written to the run log as it happens. You can watch the log stream in the app or from the CLI, and you can close the tab; the run does not need you.
After the run
When the workflow finishes — or hits the profile's time limit — the report is written, the artifacts are collected, and the sandbox is destroyed. Not paused, not archived: destroyed. The repository clone goes with it.
What persists is what you can see in the app: the report, the artifacts the workflow produced (proof-of-concept files, SARIF, the pinned workflow source, the exact profile that ran), and the run log. The log is worth being precise about, because it is the one place where excerpts of your code can remain: when the agent read a file, the relevant lines are in the trace, because the trace is how you check the finding. All of it is kept for 90 days on pay as you go and a year on Pro and Team, and all of it can be deleted sooner — per run, or by deleting the project.
Reports are visible to the members of your workspace. Midkernel staff open a customer's run only for a support request you filed, and that access is recorded.
What we do not have yet
There is no SOC 2 or ISO 27001 report today. What exists instead is this account and the trust page it summarises. A self-hosted runner and a public status page are not live yet. When a compliance report exists, it will be linked from the trust page, and this post will get an update line at the top.
If any sentence here is not true of what you observe, security@midkernel.com reaches people who will fix it, and we acknowledge within two business days.