ForgeLoopExplicit trust boundaries
Control what can run. Inspect what did.
Self-hosting gives you control, not immunity from risk. Treat repository content, agent output, and execution environments as separate trust boundaries.
Identity is not repository permission
GitHub sign-in establishes operator identity; organization membership determines roles. A GitHub App installation authorizes selected repositories. Runner enrollment grants a separate credential for runner operations. None of these steps substitutes for the others.
Keys stay with the runner
Desktop provider credentials use Windows DPAPI, macOS Keychain, or Linux Secret Service. Blank password fields do not mean saved keys disappeared. The desktop can check key storage without contacting a provider; actual model requests can send repository context to the selected provider.
Execution requires a trusted host
A runner can access source, local tools, and configured container capabilities. Git worktrees isolate checkout changes, not operating-system privileges. Docker daemon access is powerful: use dedicated hosts and narrow permissions, and review repository commands before enabling unattended execution.
Evidence still needs responsible handling
The control plane stores run metadata and evidence, rather than serving as a repository checkout. Artifacts, issue text, or logs may contain sensitive project information. Review retention, access, and redaction requirements for your deployment. No SOC 2, compliance certification, or universal security guarantee is claimed.
Report problems responsibly
Do not publish tokens, private repository contents, or exploitable vulnerability details in a public issue. Use the repository security reporting route if enabled, or establish a private channel with the maintainer before sharing sensitive details.
Ready for your first run?
Connect a repository, set up your runner, and start with a small change you can review.