Threat model
Security
Greenlight’s threat model assumes the coding agent is helpful but not trusted, the citizen developer is well-intentioned but inexperienced, and the network is hostile by default. The design decisions across the platform follow from that frame.
Actors
| Actor | What they can do | What they cannot do |
|---|---|---|
| Citizen developer | Talk to their agent, watch their app run, see audit events for their app. | Run privileged operations on the cluster, edit org policy, reach apps they don’t own. |
| Coding agent | Call MCP tools as the bound user, open PRs, propose Knowledge edits, call the data broker. | Escalate beyond the bound user’s RBAC, bypass the policy check, write to Knowledge directly. |
| Admin / Org Owner | Manage integrations, edit policy (Org Owner only), override the policy check (with audit), kill or restore apps. | Read integration secret values, rewrite the audit log, mint a fake workload identity. |
| External attacker on the network | Reach the cluster’s public ingress. | Reach app pods directly, reach the control plane, mint workload credentials, exfil via app pods. |
| Compromised app pod | Run code in the namespace, call the data broker for granted integrations. | Reach other apps, reach upstreams without a granted integration, modify its own namespace policy. |
Trust boundaries
The platform has five trust boundaries that matter for an attack path discussion:
- The IdP boundary — between the customer’s user directory and Greenlight. Crossed by OIDC SSO today; SAML and SCIM are coming soon.
- The control plane boundary — between Greenlight’s services and everything else. Crossed only by authenticated API and MCP calls.
- The data broker boundary — between app pods and upstream systems. Crossed only by authorized, audited proxy calls.
- The cluster boundary — between app namespaces and the rest of the customer’s cloud. Crossed only through the ingress controller and the data broker.
- The customer boundary — between the customer’s cloud subscription and Shift. Greenlight never crosses this; the customer’s data, code, and end users stay in their cloud.
Specific scenarios
Compromised coding agent
A malicious or hijacked agent session can only do what the bound user can do. It cannot escalate, cannot impersonate, cannot reach an app it has no permission for, cannot bypass the policy check on the way to merge. The damage ceiling is “what the bound user could do directly,” and every action is in the audit log with actor_kind=agent.
Compromised app
App-level compromise — code execution inside a pod via an upstream vulnerability — is bounded by the namespace’s NetworkPolicy. The app cannot reach other apps, cannot exfil to the public internet, cannot mint a new workload identity. It can use the integrations it was granted, which is the same thing the legitimate app could do; revoking those integrations at the dashboard stops the bleeding immediately.
Malicious pull request
A PR that tries to slip a secret, a known-bad pattern, a deprecated base image, or a policy-violating dependency past the gate fails the policy check. The author cannot self-merge; the policy check is enforced server-side, not just as a status hint. An override is possible for an org admin and is fully audited.
Leaked integration credential
Integration credentials live in Key Vault, not on the control plane database or in app pods. A leak from the control plane does not produce a credential. A leak from an app pod does not produce a credential — the app never holds the upstream credential, only the broker does. Rotating the credential is one dashboard action.
Stolen end-user session
The audit log captures the user the agent or end user was acting as. Step-up authentication and session invalidation are the IdP’s responsibility and apply globally. There is no Greenlight-side session that survives an IdP-side revocation.
What Greenlight does not claim
Greenlight protects against the scenarios above. It does not claim to:
- Protect against a compromised IdP. If your identity provider is owned, your trust assumptions are broken globally.
- Protect against a malicious cloud-subscription admin. Anyone with org-owner on the cloud can read Key Vault, alter the control plane, and bypass any application-layer control.
- Protect against an insider with
org_ownerrights misusing those rights. The audit log makes the misuse visible; it cannot prevent it.
These are the same caveats any in-cloud platform inherits. Greenlight is a governance layer on top of them, not a replacement for them.