Skip to main content

What Writ is: policy sources, signed bundles, and the entity hierarchy

Objective​

Describe what Writ is and is not, and explain how a policy in Git becomes a signed bundle scoped by the entity hierarchy of tenant, org, system, and app.

Concept​

Writ is the control plane for authorization in the AI Security Fabric. Its job is to govern policy: version it, sign it, promote it across environments, and keep an audit trail. Writ governs OPA, Enterprise OPA, and Cedar-compatible PDPs.

Start with the boundary, because it is the one thing people get wrong. Writ is not a PDP and is not on the request path. When a real request arrives, the PEP asks a PDP (OPA or Enterprise OPA), and that PDP returns allow or deny. Writ never sees that request. What Writ controls is which policy the PDP is running and how that policy got there. Decide at the edge; govern from the center.

Policy sources: Git is the source of truth​

Policy lives in Git. A .rego file like the one in this course's lab is authored, reviewed, and merged through normal pull requests. Writ treats the Git repository as the source of truth for policy. There is no separate console where policy is hand-edited into production behind the team's back; the change goes through the same review your code does.

Signed bundles, auto-built from Git​

When policy merges, Writ auto-builds it into a bundle: the standard OPA bundle format, a versioned package of policy (and any bundled data) that a PDP can pull and load. Writ signs the bundle. The signature is what lets a PDP verify that the bundle it loaded is exactly the reviewed, promoted artifact and was not tampered with in transit or at rest. Signing plus Git provenance is the chain of custody: reviewed in Git, built and signed by Writ, verified by the PDP before it loads.

The entity hierarchy scopes everything​

Writ organizes the world as a four-level hierarchy:

tenant -> org -> system -> app

Text version: a tenant contains one or more orgs; an org contains one or more systems; a system contains one or more apps. A bundle, a promotion, and a decision log are all scoped somewhere on this tree. That is how a single control plane serves a large organization without one team's promotion touching another team's app: the scope of a change is an entity in the hierarchy, not "everything everywhere."

flowchart TD
  T[tenant] --> O[org]
  O --> S[system]
  S --> A[app]
  G[Git policy repo] -->|merge| W[Writ: build + sign bundle]
  W -->|scoped by entity| A
  A -->|PDP pulls + verifies| PDP[OPA / Enterprise OPA]

Text version of the diagram: policy merges in Git; Writ builds and signs a bundle; the bundle is scoped to an entity in the tenant/org/system/app tree; the PDP for that app pulls the bundle, verifies the signature, and loads it. Writ is not in the request path that follows.

Hands-on lab​

Open ../lab/policy.rego. This is exactly the kind of artifact Writ governs: a default-deny document-access policy, authored in Git, that a PDP evaluates. It ships as a starter: the allow rules are stubbed out under a TODO(learner) block, so the suite starts red. Your job is to author those rules.

Run the suite to see the starting point:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/govern-with-writ -v

Starter state: FAIL: 3/6. The three allow tests fail because the policy denies everything until you implement the rules.

Now implement the TODO(learner) in policy.rego: incremental allow if { ... } rules that OR together on top of default allow := false so that admins may perform any action, editors may read or write within their own org, and viewers may read within their own org. Re-run opa test until it reports PASS: 6/6. Keep iterating until the suite is green. Full instructions are in ../lab/README.md.

As you work, keep the boundary in mind. opa test here is playing the role of the PDP: it loads the policy and evaluates decisions. Writ, in production, would be the thing that took this file from Git, built and signed it into a bundle, and scoped that bundle to one app in the hierarchy. Writ would not evaluate any of these decisions itself. Note that the policy has no idea Writ exists: it is plain Rego, which is the point. Writ governs how the policy ships, not how it decides.

Check for understanding​

  1. A teammate says "we route production requests through Writ for the decision." Correct them: what actually returns allow or deny on the request path, and what does Writ do instead?
  2. Where does policy come from in a Writ workflow, and what two things together form the chain of custody from author to PDP?
  3. Name the four levels of the entity hierarchy in order, and explain why scoping a promotion to one app matters in a large tenant.