Where Zift, Writ, Herald, and Verdict fit

Objective

Map each of the four EnforceAuth products to the Define, Enforce, Audit model, and state what each one does without confusing their roles.

Concept

The AI Security Fabric is four products. Each one owns a different part of the authorization lifecycle. None of them replaces the PDP: OPA or Enterprise OPA is still the engine that returns the decision.

• Zift — assess. An open-source scanner that finds authorization logic already embedded in your code and extracts it into Rego (for OPA) or Cedar. It runs a structural pass and an optional --deep pass, and it reports an "externalization percentage": how much of your scattered, hard-coded authorization has been pulled out into real, reviewable policy. Zift is where you find what to Define.
• Writ — govern. The branded control plane over OPA, Enterprise OPA, and Cedar-compatible PDPs. Writ ships signed policy bundles from Git, promotes them dev to staging to prod, and keeps decision logs with replay. It organizes entities as tenant to org to system to app. Writ is not a PDP and is not on the request path; it governs the policies the PDP runs. Writ is the home of Define (versioned authoring) and Audit (decision logs, replay).
• Herald — evaluate. The authorization MCP server. It lets an AI agent or an MCP client ask for an authorization decision through the Model Context Protocol, so agentic systems can check "may I do this" before acting. Herald sits at Enforce for AI workloads.
• Verdict — defend (coming soon). The planned agentic firewall with human-in-the-loop. When it ships, it will defend against actions an agent should not take on its own, escalating to a human when needed. Verdict maps to Enforce and defense for the AI-workload domain.

Put together against the operating model:

Product	Verb	One-line role
Zift	assess	Find embedded authz in code, extract it to Rego or Cedar.
Writ	govern	Control plane: sign, promote, and audit policy bundles.
Herald	evaluate	Authorization MCP server for agents to ask for decisions.
Verdict	defend	Agentic firewall with human-in-the-loop (coming soon).

Two boundaries to keep straight. First, only Writ is "the control plane"; do not call the whole platform that. Second, the PDP on the request path is OPA or Enterprise OPA, not any of these four. Writ governs the policy, the PDP decides, the PEP enforces.

Hands-on lab

The policy.rego in this course is the kind of artifact this whole lifecycle revolves around. Trace it through the products:

• Zift could have produced a first draft of this policy by extracting a hard-coded if role == "admin" check out of application code.
• Writ would version it, sign it into a bundle, and promote it from staging to prod, keeping a decision log every time it is evaluated.
• OPA / Enterprise OPA is what actually evaluates it, which is exactly what opa test does here.

Run the suite one more time and read the policy as the shared artifact all four products are built around:

git clone https://github.com/EnforceAuth/university-labs.git
cd university-labs
opa test courses/foundations-authorization-gap -v

Check for understanding

1. Which single product is "the control plane," and which component actually returns the allow or deny decision at request time?
2. A team has authorization rules hard-coded across a codebase and wants them extracted into Rego. Which product do they reach for?
3. An AI agent needs to ask "am I allowed to take this action" over MCP before acting. Which product answers that, and which verb of Define, Enforce, Audit does it serve?