Identity & access
Security
Greenlight authenticates human users through the customer’s identity provider. Current installs use OIDC SSO with Entra ID, Okta, or Google Workspace; SAML and SCIM provisioning are coming soon. Every Greenlight role is mapped from customer-managed group membership, and every workload identity is minted by the cluster’s own identity service.
If a user is disabled in the IdP, access ends when their Greenlight session expires or is revoked. SCIM-based immediate deprovisioning is coming soon.
Single sign-on
Greenlight supports OpenID Connect today, with Entra ID, Okta, and Google Workspace as the supported IdPs. SAML 2.0 support for IdPs that require it is coming soon.
Greenlight does not store a password, a recovery secret, or a second-factor configuration for any user. The IdP is the only authority on whether a session can begin. MFA, conditional access, and step-up flows are the IdP’s responsibility and apply without any Greenlight-specific configuration.
SCIM provisioning
SCIM 2.0 is coming soon. Today, IT manages Greenlight users and group-to-role mappings in the dashboard.
Groups are still the unit of role grant. The IdP remains the system of record, but Greenlight does not yet consume SCIM provisioning events.
RBAC
Greenlight has three roles: Builder (the default), Admin, and Org Owner. App ownership is a per-app attribute, not a role — Builders who create apps automatically own them and can add co-owners. The full role definitions are in Governance & policy.
From an access-control angle:
- A user with no mapped role has no Greenlight access at all.
- The
org_ownerrole is the only role that can edit the policy bundle, change IdP group mappings, or add other Org Owners. - The
adminrole can manage integrations, edit org Knowledge, review proposals, override the policy check (audited), and kill or restore any app. - The
builderrole can create apps, manage the apps they own, and request integrations for those apps.
Roles are evaluated at every API call and every MCP tool invocation. There is no caching window that would let a removed role keep working.
Workload identity
Workload identity is the credential apps use when they call the data broker. It is minted by the cluster’s identity provider per pod, signed by the cloud’s own KMS, rotated automatically, and never persisted to the Greenlight control plane.
When the broker authenticates an inbound request, it verifies the workload identity against the cluster identity provider, looks up which Greenlight app that workload belongs to, and uses that mapping to find the right upstream credentials. No part of this chain is a static service-account JSON the app would read at startup.
Agent identity
A coding agent that talks to Greenlight is authenticated as a specific user. The agent acquires this binding the same way a human user does — through the IdP’s standard OAuth device or authorization flow. There is no separate “agent user” account. Every agent session is bound to a real person.
This is what makes the audit trail useful. When the audit log records actor_kind=agent, it also records actor_user_id — the human the agent was acting for. The agent cannot escalate beyond what that human can do.