Security
Where your code runs, and who can touch it.
Bowse runs other people’s code for a living — your test suites and your agents’ experiments. The design starts from that: separate kernels, narrow access, and credentials that expire quickly.
- MicroVM isolation
- Workspace-scoped access
- Short-lived credentials
Workload isolation
A kernel per workload, not a namespace per workload.
Every CI job and every agent machine boots as its own KVM microVM with its own guest kernel. Containers on a shared kernel are not the boundary between customers.
- CI machines serve one job and are destroyed afterwards.
- Agent machines can run with outbound network disabled.
- Root inside a machine grants nothing on the host.
Bowse host
CI job
ci-job 48121
wiped on exit
Agent machine
ada
disk kept on stop
Agent machine
lin
outbound network off
GitHub integration
You pick the repositories. We ask for what runners need.
Bowse CI connects through a GitHub App. You choose which repositories it can see, and it only requests the permissions required to register runners and report setup problems:
| Permission | Access | Why |
|---|---|---|
| Metadata | Read | List the repositories you selected so you can choose which ones use Bowse. |
| Actions | Read | See queued workflow jobs and their status so a runner can be started for each one. |
| Administration | Read & write | Register and remove just-in-time runners on repositories owned by a personal account. |
| Self-hosted runners (organization) | Read & write | Register and remove just-in-time runners and runner groups for an organization. |
| Checks | Read & write | Post a setup check that explains why a runner couldn’t start — for example, an unlinked workspace. |
No access to repository contents beyond what your own workflow checks out with its own token.
Access control
Everything belongs to one workspace.
Machines, caches, API keys, and the GitHub installation each belong to a single workspace. Roles separate people who can look from people who can run or remove things. MCP clients sign in with OAuth and receive only the scopes you approve.
Credentials
Issued just in time, for one job.
Runner registrations are minted when a job is queued and accept exactly one job. GitHub tokens we hold are encrypted at rest, and anything a running machine is handed expires quickly and covers only its own job.
Data lifecycle
Each kind of data has its own clock.
| Resource | Lifecycle |
|---|---|
| CI machine and its disk | Destroyed when the job’s cleanup finishes. |
| Runner registration token | Single job; invalid once that job is assigned. |
| Dependency and Docker layer cache | Kept per workspace and repository; entries expire after a period with no restores. |
| Agent machine disk | Kept across stop and start; deleted with the machine. |
| Account and billing records | Per the Privacy Policy. |
Disclosure
Found something? Tell us first.
Email support@bowse.dev with “Security” in the subject. Include steps to reproduce and any proof-of-concept. Please give us reasonable time to fix an issue before going public. Bowse Inc. doesn’t claim SOC 2 or ISO 27001 certification; we answer security questionnaires directly.
Questions from your security team?
Send them over. We’d rather answer a questionnaire early than surprise you later.