Writ·Step 2 · Policy Control Plane

The universal enterprise control plane for the world’s most popular authorization engines.

Every decision logged and correlated to the point-in-time policy version.

Author once in Rego or Cedar. Sign and ship bundles to OPA, Enterprise OPA, or any Cedar-compatible PDP. The same surface governs every engine — for your team and for your AI agents.

Get started free See what ships

console.enforceauth.com / ea-financial / decisions

Decisionslive

filter…today

timeoutcomepolicybundle

14:32:11allowretail_api · accounts.regob·54e2cc8c

14:32:09allowretail_api · authentication.regob·54e2cc8c

14:32:08denyretail_api · compliance.regob·54e2cc8c

14:32:06allowidentity_provider · mfa.regob·54e2cc8c

14:32:04partialwealth_k8s · rbac.regob·8a1cc73f

14:31:58allowretail_api · compliance.regob·54e2cc8c

Every decision pinned to its bundle hash · replay any row.

What Writ does

Authoring, deployment, decisions, and audit — in one surface.

01 · Authoring

Authoring.

Real Rego and Cedar files, organized in a tree that maps to your fleet.

Rego (OPA-compatible) and Cedar policies authored in-console or via git
Drafts — iterate without disturbing the live bundle
Native test conventions per language: *_test.rego and Cedar test bundles
Policy IDE: syntax highlighting, errors, hover docs for both languages
Entity tree: tenant → org → system → app
Search across every policy file via the index

Every capability also exposed as an MCP tool · see Herald MCP

console.enforceauth.com / ea-financial / policies

Policiesea-financial · retail_api

filter…

entities

ea-financial

Retail API

Identity Provider

Wealth K8s

filetestsstatus

accounts.rego4/4active

authentication.rego6/6active

compliance.rego3/3active

transactions.rego3/3draft

accounts_test.rego—test

Rego and Cedar · inline pass/fail · branch-aware drafts.

The agent surface

And the agent that expands the automation and discovery.

Every Writ capability is also an MCP tool. Your agent can pull historical decisions, correlate them to the bundle that was live, and replay them against today’s policy.

Claudeea-financial · Writ MCP connected

live

Why was wire-transfer wt_8821 denied yesterday at 14:32 UTC?

Let me pull that decision and check the bundle that was active at the time.

tool · ea_get_decision3 args

{
  "tenant": "ea-financial",
  "decision_id": "dec_2c4f91a",
  "include_bundle": true
}

→ 200 OK · 78ms · returned decision + bundle metadata

The deny matched accounts.rego:42 (daily-limit guard) under bundle 54e2cc8c — that was the production version at the time of the request. Today’s bundle b1f9213a inherits the same rule, so the same input would deny now.

Replay against today’s bundle →Compare bundles 54e2cc8c ↔ b1f9213a →

Ask about decisions, bundles, drift, or policy history…

03 · Evaluate

Continue to Herald MCP.

The dedicated agent surface — every Writ tool, packaged for Claude, Cursor, and any compliant MCP client. Same RBAC, same audit log.

Explore Herald MCP

Writ vs. a raw engine

Bring your engine.
We handle everything around it.

Rego on OPA or Enterprise OPA. Cedar on Amazon Verified Permissions or any Cedar-compatible PDP. Writ manages the policy lifecycle around whichever engine your fleet runs.

Dimension

raw policy engine

EnforceAuth · Writ

Engine & language

Policy language

×Rego or Cedar — pick one stack and live with it

Both — author either, deploy to either engine

Policy engine

OPA · Enterprise OPA · AVP · Cedar-compatible PDPs

Same engines — Writ doesn’t fork them

Authoring & workflow

Where policies live

×Files in your repo · convention is up to you

Entity tree · typed org / system / app · same files

Bundle build

×opa build → S3 / manual upload

Content-addressed, signed bundles · auto-built from git

Promotion

×Build your own dev/staging/prod pipeline

dev → staging → prod with one click or PR merge

Observability

Decision log

×OPA decision logs → your SIEM (DIY pipeline)

Searchable log · filter by entity / action / outcome · 1d–4y retention

Log replay

×Not a thing

Re-evaluate yesterday’s traffic against today’s rules

Decision coverage

×Tests only · production coverage is invisible

Which rules actually fired in prod last hour?

Operations

Auth on the control plane

×opactl + bearer tokens, single-tenant

OIDC · entity-scoped RBAC · API keys · audit log

Multi-tenancy

×One OPA per tenant or build it yourself

Native · tenant_id on every record

Agent surface

×None

Every operation also an MCP tool · same RBAC, same audit

Deployment

×Your servers, your problem

SaaS · single-tenant · self-hosted · air-gapped

Writ doesn’t fork the engines. We contribute upstream to OPA, ship unmodified evaluators in our PDPs, and stay byte-compatible with both ecosystems. Bundles produced by Writ run on stock OPA. Cedar policies authored in Writ run on AVP and other Cedar-compatible PDPs. Policies authored anywhere else import into Writ.

Where Writ runs

From SaaS to air-gapped.
Same product, four ways to run it.

The control plane and the data plane can move from our cloud to yours as your compliance posture requires.

Multi-tenant SaaS

default

EnforceAuth hosts both the control plane and the PDP fleet in our managed environment. You bring policies, we run everything else.

Control plane: console.enforceauth.com
Data plane: EnforceAuth multi-region PDPs
Data residency: North America · EU · APAC
Egress: in-region only

Single-tenant SaaS

isolated

A dedicated EnforceAuth stack in the region of your choice, with isolated databases and dedicated PDP cells. Pin every entity to a single region for residency control.

Control plane: Dedicated EnforceAuth tenant
Data plane: Region-pinned dedicated PDPs
Data residency: Single region of choice
Egress: Locked to your region

Customer cloud

BYOC

Self-hosted in your cloud account via a Terraform or Pulumi module. Updates pull signed bundles over a narrow outbound allowlist.

Control plane: Your cloud account
Data plane: Your cloud account
Data residency: Stays in your network
Egress: Outbound to update channel only

Air-gapped on-prem

sealed

No outbound connectivity. Updates arrive as signed, hash-verified artifacts on physical media or via a one-way diode. Cosign chain validated offline; audit logs exit the same way.

Control plane: Your physical infra
Data plane: Your physical infra
Data residency: Never leaves your network
Egress: None — offline update channel

Same binary

The artifact running in our SaaS is the same one you install on-prem.

Same UI

Console, REST API, and MCP tools are identical across all four modes.

Migrate later

Start on SaaS and move to a self-hosted tenant when you need to.

The full journey