Security

• Each job runs in its own virtual machine, cloned fresh and destroyed when the job ends. Nothing carries over.
• The runner inside runs as a standard user and cannot see the host’s files or keychain.
• Runner registrations are single-use and never stored. GitHub tokens are cached for under an hour and never written to a database.
• VM images are checked against their manifest before use.

On public repositories, pull requests from forks and jobs started by issues, comments, discussions and other events anyone on GitHub can cause run on GitHub-hosted runners, never on your machines. The routing expression sends a job to your machines only for events a collaborator causes: a push, a schedule, a manual run, the merge queue, a release or a pull request from the repository's own branches. As a second line of defence, the control plane checks the event that started each job's run before any machine takes it, and refuses any other, whatever the workflow says.

Every machine is either trusted or burst. Dedicated machines an admin connects can be trusted; laptops that join a team pool start as burst. Before a job is handed out, we check its workflow. Jobs that use secrets, a deployment environment or a cloud login run only on trusted machines.

We are explicit about why. Apple’s virtualisation does not encrypt a virtual machine’s memory, so an administrator on a host could in principle inspect a running job. Keeping secrets on trusted machines is the answer.

A job’s virtual machine reaches the internet and nothing else around it: not your home or office network, not the host’s own services, not cloud metadata addresses. Teams can also limit jobs to an allowlist of sites.

Coding agents can set Buildhound up, but they cannot add someone’s laptop to a pool, trust a machine with secrets or turn off network isolation. Those take a person, on the machine or in the dashboard. Every command is read-only until you confirm a change.

The owner of a machine always sees which repository and job are running on it. Every job records where it ran: the machine, its trust level, the image and the software versions. Teams get an audit log of machines, trust and policy changes.

The audit flags risky workflow patterns, with a fix for each: pull request workflows that run untrusted code with secrets nearby, tokens with more permission than needed, actions not pinned to an exact version, AI agents that anyone can trigger with write access, and long-lived cloud keys where a short-lived login would do.

Email [security contact email]. We acknowledge reports within 2 business days and keep you updated until the issue is fixed. Please give us a reasonable time to fix an issue before disclosing it.