Skip to main content

Deployment topologies and latency budgets

Objective​

Choose among the five deployment topologies (sidecar, centralized, Enterprise-OPA masking, AI-MCP gateway with workload mTLS, and admission controller) and state the latency budget and tradeoff each carries.

Concept​

The five-layer architecture from Lesson 1 does not say where the PDP runs relative to the PEP. That placement is the topology decision, and it is the highest-leverage choice an architect makes, because it sets your latency, your availability blast radius, and how you distribute policy. All five topologies run the same policy and produce the same decisions; they differ in where evaluation happens.

A note on latency budgets before the topologies. The end-to-end authorization overhead you can tolerate depends on the call it guards. As a working range, a co-located PDP should add on the order of sub-5ms to a request, and a network-hop PDP should stay within roughly tens of milliseconds, under about 50ms, or the check starts to distort the workload it protects. Treat these as budgets to design against and measure, not guarantees; the actual number depends on policy complexity, data size, and network.

Sidecar (PDP co-located with the workload)​

An OPA (or Enterprise OPA) instance runs next to each workload, in the same pod or host. The PEP calls localhost, so there is no network hop and evaluation is fastest: this is the topology that hits the sub-5ms budget. It also fails independently, one workload's PDP going down does not take out everyone else's. The cost is many PDP instances to run and keep in sync with current bundles. Writ handles that sync by promoting one signed bundle to all of them. Choose the sidecar when latency is tight and you want failure isolation.

Centralized (a shared PDP service)​

One PDP service (usually a cluster) serves many PEPs over the network. The PEP makes a remote call for each decision, so you pay a network hop: design against the under-50ms budget and watch the tail. The upside is operational simplicity, fewer PDPs to run, one place to observe, and uniform data. The downside is a shared failure domain and the round trip. Choose centralized when a small latency cost is acceptable and running a PDP next to every workload is not.

Enterprise-OPA masking (eopa in the data path)​

When the workload is a data system, the enforcement point sits in front of the data and Enterprise OPA does more than a boolean decision: it can mask or filter the response so the caller sees only the rows and fields they are entitled to. This is where Enterprise OPA's data-layer features earn their place: decision_logs.mask for keeping sensitive fields out of the log, delta bundles for shipping large policy or data efficiently, and datasources for pulling context. The tradeoff is that the PDP is now in the data path and its latency is part of the query's latency, so the budget is strict. Choose this when authorization has to shape data, not just gate access to it.

AI-MCP gateway (workload mTLS)​

An AI agent that calls tools through the Model Context Protocol is a workload like any other, and it needs a PEP in front of its tool calls. In this topology an AI-MCP gateway intercepts each tool invocation and asks the PDP whether this agent, on this identity, may invoke this tool. The identity is a workload identity established over mutual TLS (the SPIFFE layer from Lesson 1), because there is no human behind the agent to authenticate. This is exactly the decision the course lab models. Herald, the authorization MCP server, is EnforceAuth's product in this space: agents query it for a decision before they act. Choose this topology to bring agent tool-use under the same policy and audit as everything else. The latency budget matters here too, because a slow authorization check stalls the agent mid-task.

Admission controller (Kubernetes)​

The enforcement point is a Kubernetes admission webhook: before an object is created or changed in the cluster, the API server calls out to a PDP that admits or rejects it. This guards the infrastructure domain: no pod that violates policy is ever admitted. It runs at change time, not request time, so its latency budget is about not stalling kubectl apply and cluster operations rather than a per-request hot path, but a slow or unavailable webhook can block deployments cluster-wide, which makes its fail mode (Lesson 3) a deliberate choice.

Choosing​

topology            PDP placement           budget        pick it when
------------------  ----------------------  ------------  -----------------------------
sidecar             next to each workload   sub-5ms       latency tight, want isolation
centralized         shared service          under ~50ms   simplicity over co-location
eopa masking        in the data path        strict        authz must shape data
AI-MCP gateway      in front of tool calls  agent-facing  agents calling tools (mTLS)
admission control   k8s admission webhook   change-time   gate cluster changes

Text version: co-located topologies (sidecar) are fastest and fail independently; networked topologies (centralized) are simpler but share a failure domain and pay a hop; the data-path, agent, and admission topologies are chosen by what they guard. You can mix them: a real deployment often runs sidecars for latency-critical services and an AI-MCP gateway for agents, all governed by one Writ control plane.

Hands-on lab​

The course lab models the AI-MCP gateway topology specifically. Re-open ../lab/policy.rego and notice the topology in the input: subject.spiffe_id is a workload identity, context.mtls_verified is the mutual-TLS check that identity depends on, and action: "invoke" with resource.tool is an agent invoking a tool through the gateway. The policy is topology-agnostic Rego (the same decision would run in a sidecar or centralized PDP unchanged); the topology is where you run it and how the identity arrives. Read the header comment's note that Writ governs how this policy shipped but is not on the request path, which is true in every one of the five topologies.

You will implement the decision rules in Lesson 3. For now, answer for yourself: if this same policy guarded a latency-critical internal service instead of an agent, which topology would you move it to, and what would you give up?

Check for understanding​

  1. Which topology best fits a sub-5ms latency budget and why? What operational cost does it add?
  2. In the AI-MCP gateway topology, why is the caller's identity established over mutual TLS rather than a bearer token tied to a human? Which architecture layer from Lesson 1 is this?
  3. Name one capability Enterprise OPA adds in the data-path (masking) topology that a plain boolean allow/deny does not, and state the latency tradeoff of putting the PDP in the data path.