OPA Is Not Enough: Why Agentic AI Needs Runtime Policy, Not Just Auth Policy

Category: AI Engineering | Reading time: 6 min

---

Two Different Problems

Open Policy Agent (OPA) is excellent at what it was designed to do: authorisation policy for APIs and infrastructure. Should this user be allowed to call this endpoint? Can this service account access this resource? These are questions about access control — binary, evaluated at request time, based on identity and resource attributes.

Agentic AI introduces a different category of policy question: should this AI action be allowed, and under what conditions?

These are not the same question, and OPA at the API gateway is not the right tool for the second one.

---

What OPA Does Well

OPA evaluates policies at the boundary — the API gateway, the service mesh, the Kubernetes admission controller. When a request arrives, OPA checks: does the caller have permission to do this?

For infrastructure and APIs, this is exactly right. OPA is fast, expressive, and battle-tested at this layer.

But notice what OPA doesn't see:

• The agent's internal reasoning about what to do
• The multi-step workflow context (step 1 already completed, step 2 is about to run)
• The business-level attributes of the action (payment amount, vendor status, document classification)
• The delegation chain (who authorised the agent to act on behalf of whom)

OPA at the gateway can tell you whether the payment service is allowed to call the bank API. It cannot tell you whether this specific payment, for this amount, to this vendor, submitted by this role, requires CFO approval.

Plus, in typical agent stacks framework tools are often just framework function calls — not distinct HTTP requests to named APIs. The gateway may see one outer request while many tool invocations never cross a boundary OPA can inspect, so there is no natural place to attach API-style authz to each governed step.

---

The Runtime Policy Gap

Agentic AI workflows have a runtime context that API-level policy cannot see. Consider a multi-step payment workflow:

Step 1: extractInvoice      — fetch invoice data from DB
Step 2: lookupVendor        — fetch vendor status from vendor master
Step 3: evaluatePolicy      — should we proceed?
Step 4: submitPayment       — create payment record
Step 5: updateERP           — write to ERP ledger
Step 6: reconcile           — build OBO chain, close workflow

The policy evaluation at step 3 needs to know:

• input.amount — from the invoice extracted in step 1
• input.vendor_status — from the vendor lookup in step 2
• input.is_ofac_cleared — from the vendor lookup
• input.submitter_role — from the workflow initiation context
• input.prior_period_total — computed aggregate, not available in any single request

None of this context exists at the API gateway. The gateway sees a single HTTP request to /api/payments. It can authorise that request. It cannot evaluate the business-level policy for the specific payment the agent is about to make.

Runtime policy needs to be inside the workflow, not at the boundary.

---

The Regorus Approach: Same Language, Different Layer

Taos uses Regorus — an embedded Rego engine written in Rust — to evaluate the same Rego policy language as OPA, but at the step level inside the workflow execution.

This means:

# This rule runs INSIDE the workflow, after context is assembled
package taos.paymentpilot.vendor_payment

deny_blocked_vendor {
    input.vendor_status == "blocked"
}

tier_cfo_approval {
    input.amount >= 250000
    input.vendor_status == "approved"
    input.is_ofac_cleared == true
}

required_role = "cfo" { tier_cfo_approval }

The input here contains the fully assembled workflow context — invoice amount from step 1, vendor status from step 2, submitter role from the session. No HTTP roundtrip to an OPA server. No gateway rule that can't see the business context. The policy engine is embedded in the kernel, evaluating full workflow context in microseconds.

---

Why Not Both?

You should use both — they're complementary, not competing.

OPA at the gateway: controls which services and users can initiate which workflows. An AP clerk can call POST /api/payments. A non-employee cannot. This is access control — OPA handles it well.

Regorus in the kernel: controls what the workflow is allowed to do once initiated. An AP clerk can initiate a payment, but cannot self-approve one above $1,000. A payment to a blocked vendor is denied regardless of who initiates it. This is runtime governance — Regorus handles it at the step level.

The two layers are architecturally distinct:

User/Service Request
      │
      ▼
[OPA at Gateway]           ← Can you initiate this type of workflow?
      │
      ▼
[Taos Kernel]
  │
  ├─ [Step 1] extractInvoice
  ├─ [Step 2] lookupVendor
  ├─ [Regorus Policy Eval]  ← Should this specific workflow proceed, and how?
  ├─ [Step 4] submitPayment
  └─ [Step 5] updateERP

Both layers use Rego. The policy language is shared; the evaluation context and timing are different.

---

The Performance Argument for Embedding

OPA over HTTP adds latency: a network roundtrip to the OPA server, JSON serialisation/deserialisation, response parsing. For high-throughput agentic workflows processing thousands of actions per second, this adds up.

Regorus is embedded in the Taos kernel as a Rust library. Policy evaluation is a function call, not an HTTP request. The same Rego rules evaluate in microseconds rather than milliseconds.

For an OFAC check that fires on every payment in a high-throughput AP workflow, the difference between 2ms (OPA HTTP) and 50μs (Regorus embedded) is significant at scale.

---

Keeping Policies in Sync

One concern when running policies in two places (OPA gateway + Regorus kernel) is drift — the gateway policy and the workflow policy diverging. Taos addresses this by using a single policy source of truth: the control plane's policy bundle registry.

Both OPA and Regorus can consume policy bundles from the same registry. When the compliance team updates a policy, both enforcement layers update from the same source. No drift.

---

The Bottom Line

OPA is the right tool for access control at the API boundary. It is not the right tool for business-level governance inside agentic workflows. The context doesn't exist at the gateway; the enforcement needs to be inside the kernel.

Regorus gives you the same policy language as OPA — and the Taos kernel gives you the runtime enforcement layer that OPA was never designed to provide.

Use OPA for the boundary. Use Taos for the workflow. Use the same Rego policies for both.

---

Tags: OPA, Regorus, AI governance, policy-as-code, agentic AI, runtime policy, API security