What Writ governs and the entity hierarchy

Objective

State what Writ governs, why it is a control plane and not a PDP on the request path, and place a policy in the entity hierarchy of tenant, org, system, and app.

Concept

Writ is the branded control plane over OPA, Enterprise OPA, and Cedar-compatible PDPs. Governing means managing the lifecycle of the policies those engines run: authoring and versioning them, signing them into bundles, promoting them from dev through staging to prod, and keeping decision logs you can replay. Writ does not evaluate a request. When a real request arrives, the PDP (OPA or Enterprise OPA) is what returns allow or deny. Writ governs the policy; the PDP decides; the PEP enforces. Keep that boundary straight: Writ is not on the request path, so a Writ outage does not stop the PDP from deciding on cached, already-deployed bundles.

To manage policy at scale, Writ organizes everything into an entity hierarchy with four levels:

tenant
  org
    system
      app

• Tenant is the top boundary, your isolated slice of the control plane. Nothing crosses a tenant edge.
• Org is a grouping inside a tenant, typically a business unit or team that owns policy.
• System is a deployable domain inside an org, for example a payments platform or a data lake.
• App is the concrete service or workload the policy is attached to.

Text version of the diagram: a tenant contains one or more orgs; each org contains one or more systems; each system contains one or more apps. Scope flows downward, and isolation is enforced at every edge.

Why the hierarchy matters: it is how Writ scopes who may author and promote a given policy, and it is the natural shape of the isolation your policies should enforce at runtime. A policy attached at the app level inherits the org and tenant it lives under, and a well-written policy refuses to let a subject in one tenant or org act on a resource in another. The lab in this course is exactly that kind of policy: a first governed policy that enforces isolation at all four levels of the hierarchy, tenant, org, system, and app, before it ever checks a role.

This hierarchy is a Writ governance construct, not a Rego language feature. In the policy itself you model the boundary with ordinary Rego by comparing the subject's tenant, org, system, and app to the resource's. Writ decides which bundle ships where; the policy inside the bundle decides who may act on what.

Hands-on lab

Open ../lab/policy.rego and read the input shape at the top. The subject and the resource each carry all four hierarchy levels: tenant, org, system, and app. Those fields are how this policy honors the entity hierarchy at decision time. Isolation is a nested chain checked before any role: same_tenant requires a matching tenant, same_org also requires a matching org, same_system also a matching system, and same_app also a matching app. Each rule attaches at one level, so scope narrows as you descend: admins act tenant-wide, publishers within an org, operators within a system, and members only within an app.

Run the suite from the cloned university-labs repo:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/getting-started-writ-control-plane -v

Before running it, predict the decision for an admin whose tenant differs from the resource's tenant. The role is privileged, but the tenant boundary is checked first, so the answer is deny. That is the entity hierarchy doing its job in one line: no action crosses a tenant edge, regardless of role.

Check for understanding

1. Does Writ evaluate a request and return allow or deny? If not, which component does?
2. List the four levels of the Writ entity hierarchy from the widest boundary to the narrowest.
3. In the lab policy, why is a same-tenant check evaluated before the subject's role is considered?