Your Policy as Code Journey

Moving to Policy as Code is not a single flip — it is a sequence of decisions about where policies live, how they reach runtimes, and how you prove enforcement. This page helps you pick a path before you wire EnforceAuth.

Where are you today?

Starting point	Typical next step
Greenfield / first Policy as Code project	OPA vs EOPA → 15-minute quickstart with EACommerce or your own repo
Embedded if checks in application code	OPA vs EOPA → discover sprawl with Zift, extract Rego, deploy via EnforceAuth
AI agents calling enterprise MCP tools	MCP Authorization Gateway + EnforceAuth bundles → OPA behind the gateway
OPA already running (sidecar, daemon, or SDK)	Confirm PDP choice in OPA vs EOPA; point policy source + bundle destination at EnforceAuth
Styra DAS™ / EOPA fleet (subset of readers)	OPA vs EOPA → Migration from DAS™ / EOPA (DAS™ deprecated April 30, 2026)

The four layers

Every EnforceAuth deployment stacks four layers. You can adopt them in order:

1. Authoring     Git repo with Rego (+ tests)
       ↓
2. Control plane EnforceAuth — build, test, promote bundles
       ↓
3. Distribution  S3 / GCS / Azure bundle destination
       ↓
4. Enforcement   PDP (OPA/EOPA) + PEP (your app) + decision logs back to EnforceAuth

Skip layer 4 and you have policies in Git with no runtime proof. Skip layer 2 and you are back to manual bundle scripts with no audit trail.

Decision 1 — OSS OPA or Enterprise OPA (EOPA)?

→ OPA vs EOPA — full comparison, decision tree, masking, delta bundles, partitioning, and procurement notes.

Short answer: OSS OPA for most new teams. Choose EOPA when masking, delta bundles, or partitioning are hard requirements — not because you use EnforceAuth. Migrating from Styra DAS™ is a separate, smaller audience.

Decision 2 — Sidecar, host agent, or something else?

This is the most common confusion. Sidecar and agent are not two brands of the same thing — they are placement choices for the PDP.

Pattern	What it means	Choose when…
Sidecar	OPA/EOPA container in the same pod as your app; PEP calls localhost:8181	Kubernetes microservices; you want per-service isolation
Host agent / daemon	One OPA/EOPA process per VM or host shared by apps on that machine	VMs, legacy stacks, not on Kubernetes
Centralized PDP	Shared OPA/EOPA cluster behind a load balancer	Many polyglot PEPs, one policy revision
Embedded SDK	Bundle loaded in-process (Go SDK, Lambda layer)	Strict latency SLOs, serverless
Gateway / mesh	Envoy/Istio/API gateway calls OPA	North-south ingress authorization

Sidecar vs host agent — the practical difference

Sidecar: Every pod gets its own PDP copy. Policy updates poll independently. Blast radius of a bad config is one pod. Ops cost scales with pod count.

Host agent: One PDP per machine. All processes on that host share it. Fewer PDP instances to patch, but a bad rollout affects every app on the host.

Rule of thumb:

• On Kubernetes → start with sidecar unless you have a platform team running a shared authorization service.
• On VMs → host agent (systemd-managed OPA/EOPA).
• Not sure yet → run centralized OPA in dev, move to sidecar before production scale.

Full comparison: Deployment patterns.

Decision 3 — How do policies reach production?

Method	Best for
GitHub Actions + deploy-action	Teams already on GitHub; OIDC trust, no deploy API keys
Console manual deploy	First-time setup, debugging pipeline failures
Git webhook auto-deploy	Push-to-deploy after policy source is trusted
Other CI (GitLab, CircleCI)	Generic OIDC trust policies

See GitHub Actions and CI/CD.

Decision 4 — How do you find embedded auth to extract?

If authorization lives in if (user.role === 'admin') scattered across services, start with Zift:

1. Structural scan (free, fast) — finds role checks, guards, middleware
2. Optional deep scan — LLM-assisted classification
3. zift extract — Rego or Cedar stubs to drop into your policy repo
4. Connect repo to EnforceAuth and deploy

Zift does not replace EnforceAuth — it feeds the policy repo EnforceAuth already manages.

Recommended paths by persona

Platform engineer (greenfield)

1. Quickstart
2. GitHub Actions for deploy automation
3. Deployment patterns — pick sidecar or agent
4. PDP integration — bundles + decision logs

Application developer (OPA already running)

1. Quickstart Option A
2. Application integration — align input schema
3. API keys — wire decision log plugin

Architect (embedded auth migration)

1. Authorization gap
2. Zift — inventory embedded logic
3. Policy as Code fundamentals
4. Multi-environment best practices

Next

• 15-minute quickstart — hands-on setup
• Choose your path — role-based reading lists
• Deployment patterns
• EnforceAuth getting started