greenroom

Security model

The boundaries Greenroom operates inside, and why they hold.

Greenroom walks pre-production builds with an autonomous agent, so the security model is conservative by construction. These are the boundaries, each enforced by mechanism rather than promise.

Your repository is read-only

The GitHub App requests read access to contents, metadata, and pull requests, and write access to check runs so it can post the handoff as a GitHub Check. It cannot push, cannot comment on your pull requests, cannot open branches, and cannot modify anything in your repository. There is no configuration that grants Greenroom write access to code.

Your build runs without our credentials

The reusable CI workflow runs your prepare script before the Greenroom runner. Keep production secrets out of this job. The runner exchanges the job's GitHub OIDC identity for a short-lived, run-bound token; model-provider credentials stay in Greenroom's control plane.

PRs cannot rewrite their own policy

The environment manifest and state contract are read from the PR's base revision. A pull request that edits the allowlist, the oracles, or the isolation attestation still runs under the policy that was reviewed and merged before it existed. Policy changes take effect only after they merge through your normal review.

The walk is contained

  • Web: the browser enforces the host allowlist in-line. A request to an unlisted host is contained, service workers are blocked, WebSockets are filtered by the same allowlist, and a violation ends the walk with the reason recorded.
  • iOS: containment is your attestation, not in-line interception. With sandboxed_backend, you configure and verify the simulator build and all its SDKs against isolated services. A test API URL alone does not prevent analytics, purchases or other SDKs from reaching production. With external_proxy, a proxy or firewall you run on the CI host denies everything outside the allowlist. Greenroom does not intercept or record simulator network traffic.
  • The manifest attests the environment is isolated (isolated: true is the only accepted value) and rejects any host appearing as both allowed and production.
  • Purchases and account creation are refused by the driver unless a goal explicitly grants them, and sandboxPurchases declares whether purchase flows hit a sandbox.

Runs fail closed

Anything the run cannot verify, reach, or complete becomes an explicit blocked or inconclusive outcome with the cause recorded. Infrastructure failure is never reported as app health, and a goal is never silently dropped from a handoff.

Evidence over trust

Every claim in a handoff links to captured evidence, and run provenance records the exact SHAs, policy hashes, and model routes involved. You never have to take a verdict on faith; the proof ships with the report.

Evidence and personal data

Read data handling and pilot support for provider recipients, screenshot privacy, retention, report access and support boundaries.

For sign-in walls, read testing authenticated apps. Runner OIDC does not authenticate the user inside your app.

On this page