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 lives as rows in org_policies and is evaluated by OPA at the policy check on every pull request. Rules come from three places: the default bundle every org is seeded with, a catalog of curated templates and compliance packs you enable and configure, and custom rules an admin authors for org-specific policy.
Common policy categories: approved base images, allowed dependencies, container resource ceilings, required headers, secret-scanning sensitivity, license rules. From Settings → Policies in the dashboard, an Admin or Org Owner tunes any rule (block or warn, enable or disable, edit its configuration), enables a catalog template or pack, or writes a custom rule. Most policy is no-code — pick a template and fill in its fields. For anything the catalog doesn’t cover, the custom-rule editor lets you author a rule in OPA’s Rego language against Greenlight’s evidence schema, with a dry-run preview that shows what the rule would allow or block before it goes live; new custom rules start in warn mode so they can’t break deploys until you promote them to block. Every change is compiled, validated, audited, and effective for the next PR. 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 suspended. The audit log captures the actor, the app, the reason, and the time.
Suspended 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.