Governance & policy
Concept
Governance in Greenlight is a small, well-known set of levers. Every action that affects what an app can do routes through one of them, and every use of those levers writes an audit event. There are no side channels.
The roles
Section titled “The roles”Greenlight has three roles — Builder, Admin, and Org Owner — mapped from groups in the customer’s identity provider, plus per-app ownership for the Builders who create apps. The role definitions, group-mapping workflow, and agent/workload identity model live on one page: Identity, SSO & RBAC.
The governance-relevant summary: Admins and Org Owners hold the operational levers below (kill switch, override, integration grants) and manage the policy bundle; changing the role mappings themselves stays with Org Owners.
Policy bundles
Section titled “Policy bundles”The active policy set for an organization is the shipped default bundle — deterministic manifest and repo checks plus the scanner-backed secret and CVE checks — with each org’s tuning stored as rows in org_policies and evaluated by OPA at the policy check on every pull request. There is no separate rule set to enable and no rules for you to write: the checks are the ones listed here, and what you control is how each behaves.
From Settings → Policies in the dashboard, an Admin or Org Owner tunes any shipped check: block or warn, enable or disable, and edit the values a check compares against — the approved base-image allowlist (with a one-click recommended starter list), workload compute caps, and allowed resource kinds. Every check tunes the same way, secrets included — a detected secret is always reported on the run, and the organization decides whether it blocks. Where a check starts depends on whether the party it blocks can act on it. Checks that report findings in your code start in warn, so a first deploy is never held by whatever history a repository arrived with; promote them to block when you’re ready. Checks that validate an app’s manifest — that it parses, and that it only requests integrations you registered — start in block, because the fix is in the change itself and there is no useful “warn and deploy anyway” for a malformed or over-permissioned app. A check that reads Greenlight’s own generated deployment starts in warn whatever it reads, since only Greenlight could have broken it. The same page is where you require the scanners your organization already runs — name the check CodeQL or Snyk posts and the app that posts it, or paste steps Greenlight will run in every app pipeline — and Greenlight requires the check at merge and relays its findings to the coding agent. It also lists the apps whose latest gated run failed, and which checks decided it. Every change is audited and effective for the next run. See Manage policies.
Agents can read the active policy set at any time via the getPolicies MCP tool. This is why agents are usually able to write code that passes the check on the first try — they know the rules before they generate.
The kill switch
Section titled “The kill switch”Any IT admin can stop any active or degraded app immediately. A single dashboard action scales the pod to zero, revokes the workload proxy key, and moves the app to Paused (suspended on the API). The audit log captures the actor, the app, the reason, and the time.
Paused apps can be restored. The restore action is also audited and brings the app back with its data, secrets, and repo intact. See Kill switch & restore.
Override audit
Section titled “Override audit”Some checks have to be overridable in emergencies — a critical fix that touches a deprecated dependency, a hotfix that needs a one-time secret. Greenlight allows Admins and Org Owners to override the policy check on a per-PR basis, but every override emits an audit event capturing the actor, the failed checks they overrode, and the reason they typed in.
There is no silent override and no permanent waiver. Override frequency surfaces in the audit dashboard so IT can see when a policy is being routinely bypassed and decide whether the policy needs to change.