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
Greenlight has three roles, mapped from groups in the customer’s identity provider.
| Role | What they can do |
|---|---|
| Builder | The default role for everyone with Greenlight access. Builders create apps; the user who creates an app automatically owns it and can add co-owners. Owners and co-owners manage their app’s environment variables, request integrations, edit app-scope Knowledge, and ask to pause or resume their own app. |
| Admin | Manage integrations and credentials, edit org-scope Knowledge, review agent proposals, view the audit log, kill or restore any app, and override the policy check (with audit). The day-to-day IT role. |
| Org Owner | Everything an Admin can do, plus: edit the policy bundle, install or upgrade Greenlight, change IdP group mappings, and add or remove other Admins and Org Owners. There are usually one or two. |
App ownership is not a role. It’s a per-app attribute: the user who creates the app owns it; that user can promote co-owners on the app’s detail page. Builders never need to be granted anything extra to manage the apps they create.
Roles are additive and inherited from IdP group membership. A user mapped into both Builders and Admins groups gets the union of both. See Users, groups, RBAC for the IdP mapping flow.
Policy bundles
Policy is structured data, not free-form scripts. The active policy bundle for an organization lives as rows in org_policies and is evaluated by OPA at the policy check on every pull request.
Common policy categories: approved base images, allowed dependencies, container resource ceilings, required headers, secret-scanning sensitivity, license rules. Adding a policy is a row insert from the dashboard; the change becomes effective for the next PR.
Agents can read the active policy set at any time via the greenlight.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
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
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.