Skip to main content

The whole pipeline: four products, one decision

Objective​

Trace a single authorization decision through the full AI Security Fabric and name, at each stage, what Zift, Writ, the PDP, and Herald contribute, and what each is not.

Concept​

You have met the four products one at a time. The capstone is seeing them as one pipeline that produces and enforces a single decision. The organizing idea is the operating model you learned in foundations: Define, Enforce, Audit. Each product owns a stretch of it.

  code  ──Zift──▶  policy.rego ──Writ──▶ signed bundle ──▶ PDP ──▶ allow/deny
 (assess)          (in Git)     (govern)   (promote)     (OPA/EOPA) (enforce)
                                                            ▲
                                                         Herald
                                                       (MCP query,
                                                     federated context)
                                                            │
                                              decision log + mask ──▶ replay
                                                          (audit)

Text version of the diagram: Zift assesses application code and extracts the embedded authorization into a policy.rego in Git. Writ governs that file, building and signing a bundle and promoting it across environments. The PDP (OPA or Enterprise OPA) pulls the bundle and enforces the decision at the PEP. Herald exposes the same authorization query over MCP and federates the context that fills input. Every decision is logged, sensitive fields are masked, and Writ replay re-runs recorded inputs against a candidate policy. Verdict (coming soon) would add a human approval step at enforcement.

What each product is, and is not​

  • Zift (assess) scans code, finds authorization embedded in handlers and middleware, and zift extract turns it into Rego. It reports an externalization percentage. Zift is a scanner and extractor; it does not make runtime decisions.
  • Writ (govern) is the control plane. It versions, signs, promotes, and audits policy bundles, scoped by the entity hierarchy (tenant, org, system, app). Writ is not a PDP and is not on the request path. Do not call the whole platform "the control plane"; that name is Writ specifically.
  • The PDP is OPA or Enterprise OPA. It evaluates the policy and returns the decision at the PEP. This is the only component on the request path in the list.
  • Herald (evaluate) is the authorization MCP server. It exposes the authorization query to callers (including AI agents) and federates the context from systems of record into input. Herald fronts the query; the PDP still makes the decision. Herald is not the PDP and is not Writ.
  • Verdict (defend) is the agentic firewall, coming soon. It adds human-in-the-loop approval as an enforcement obligation. Describe it as future, never as shipping behavior.

The four together are the AI Security Fabric across four domains (applications, infrastructure, data, AI workloads).

One decision, one artifact​

The thing that makes the pipeline concrete is that all four products operate on one artifact: the policy.rego in this course's lab. Zift produced it. Writ signs and promotes it. The PDP evaluates it. Herald fronts the query that evaluates it. The policy itself is plain Rego and has no idea any of these products exist, which is exactly the point: the fabric governs how a policy ships and is queried, not how it decides.

Hands-on lab​

Open ../lab/policy.rego and read the header comment before writing any rules. It narrates, in order, how each product touches this one file. Notice that role_permissions is annotated as the map Zift extracted from a requireRole(...) middleware, and input.context is annotated as the field Herald federates. You will implement the three allow rules across this and the next two lessons; for now, just run the suite to see the starting point and confirm which tests are already green:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/capstone-four-product-fabric -v

Starter state: FAIL: 3/11. The three failing tests are the allow paths you will author. The deny tests and the masking tests already pass, because the default-deny policy and the completed mask.rego are already correct.

Check for understanding​

  1. A colleague says "we send the request to Writ and it returns allow or deny." Correct them: which component actually returns the decision on the request path, and what does Writ do instead?
  2. Which product produced the policy.rego, and which product fronts the query that evaluates it? Name what each of those two is not.
  3. The lab suite starts at FAIL: 3/11 with the mask tests already green. What does that tell you about which parts of the fabric are "wired" for you versus which part you still have to assemble?