From OPA to Intended: When Policy Engines Are Not Enough for AI Agents

OPA Is Great at What It Does

Open Policy Agent is one of the best policy engines ever built. It provides a declarative policy language (Rego), a fast evaluation engine, and a clean architecture for decoupling policy from application code. For infrastructure authorization -- Kubernetes admission control, API gateway policies, microservice authorization -- OPA is an excellent choice.

We have deep respect for the OPA project and the team behind it. Several of our engineers have contributed to the OPA ecosystem. This post is not about OPA's limitations as a policy engine. It is about the gap between what policy engines do and what AI agent governance requires.

The Gap

Policy engines answer the question: given this input, does this policy allow or deny? That question is well-defined, and OPA answers it efficiently. You write a policy in Rego, submit a query with an input document, and get back a decision.

For infrastructure operations, this model works because the input is well-structured. A Kubernetes admission request has a defined schema. An HTTP request has a defined schema. The policy engine does not need to understand intent because the intent is encoded in the structure of the request itself.

AI agent actions are different. When an AI agent submits an action, the raw request is often ambiguous. "Write to the database" could mean updating a configuration value or dropping a production table. "Call the API" could mean reading a dashboard metric or initiating a wire transfer. The intent is not in the structure -- it is in the context.

This is where the gap between policy engines and authority systems becomes clear.

Gap 1: No Intent Classification

OPA evaluates policies against structured input. It does not classify intent. If you want to write a policy that says "deny production deployments during business hours," you need to pre-classify the action as a "production deployment" before sending it to OPA. The classification logic lives outside the policy engine, in your application code, where it is inconsistent, untested, and unmaintained.

Intended classifies intent as a first-class operation. Every action is mapped to the MIR taxonomy before policy evaluation. The classification is standardized, versioned, and consistent across all agents and all domains. Policies reference MIR categories, not raw action parameters.

Gap 2: No Risk Scoring

OPA returns allow or deny. There is no concept of risk. A policy either matches or it does not. You cannot express "allow this action, but flag it as high-risk" or "allow this action if the risk score is below 0.7."

Intended scores risk on a continuous scale using eight factors: action severity, resource sensitivity, historical patterns, temporal context, agent trust level, domain-specific rules, velocity, and cumulative exposure. The risk score feeds into policy evaluation, enabling graduated responses that OPA's binary model cannot express.

Gap 3: No Domain Intelligence

OPA policies are generic. You write rules against input fields. There is no built-in understanding of enterprise domains. If you want policies that reflect the specific governance requirements of financial operations versus software development versus HR administration, you need to build that domain knowledge into your Rego policies from scratch.

Intended ships 14 Domain Intelligence Packs that encode the specific intents, risk rules, escalation policies, and compliance mappings for each enterprise domain. The FinOps pack knows that payment approvals above a threshold require dual authorization. The SDLC pack knows that production deployments during a code freeze should be escalated. The HR pack knows that bulk access changes trigger a compliance review.

Gap 4: No Cryptographic Proof

OPA logs decisions as text entries. Those logs are useful for debugging and monitoring, but they do not provide cryptographic proof. There is no signed token, no evidence bundle, no hash-chained ledger. An auditor reviewing OPA logs must trust the log storage system.

Intended produces a signed authority token, an HMAC evidence bundle, and a hash-chained audit entry for every decision. These are independently verifiable without platform access. The proof is mathematical, not trust-based.

The Migration Path

Migrating from OPA to Intended does not require a big-bang cutover. The recommended path runs both systems in parallel, gradually shifting governance responsibility from OPA to Intended as confidence grows.

Phase 1: Observe (Week 1-2)

Deploy Intended in observe mode alongside your existing OPA setup. In this mode, Intended classifies intents and evaluates policies but does not enforce decisions. OPA remains the enforcement point. Intended logs what it would have decided, so you can compare its decisions against OPA's.

This phase answers the question: are Intended's decisions consistent with what we expect? It also highlights gaps -- actions that Intended classifies differently than your current OPA policies assume, or risk factors that your current setup does not account for.

Phase 2: Shadow (Week 3-4)

Switch Intended to shadow mode. In this mode, Intended evaluates and records decisions, and you compare them against OPA's decisions in real-time. Any discrepancies are flagged for review. This surfaces edge cases and policy gaps before enforcement begins.

During this phase, you translate your OPA policies into Intended policies. Many policies translate directly -- allow/deny rules based on resource type, action type, and identity are straightforward. Others require rethinking -- policies that were complex in Rego because they were encoding domain knowledge may be simpler in Intended because the domain knowledge is built into the Domain Intelligence Packs.

Phase 3: Enforce Low-Risk (Week 5-6)

Enable Intended enforcement for low-risk action categories while keeping OPA as the enforcement point for high-risk actions. This lets you validate Intended's enforcement behavior in production with minimal blast radius.

Monitor the results. Confirm that low-risk actions are being classified, evaluated, and recorded correctly. Review the authority tokens and evidence bundles to ensure they meet your compliance requirements.

Phase 4: Full Enforcement (Week 7-8)

Extend Intended enforcement to all action categories. Decommission OPA for AI agent governance. Keep OPA for infrastructure policies where it excels -- Kubernetes admission, API gateway rules, network policies. Use Intended for AI agent authority.

What You Gain

The migration from OPA to Intended for AI agent governance gives you:

• Consistent intent classification across all agents and domains, using the MIR taxonomy instead of ad-hoc Rego logic
• Risk scoring that enables graduated responses instead of binary allow/deny
• Domain intelligence that encodes enterprise governance requirements without custom policy engineering
• Cryptographic proof that satisfies compliance requirements with mathematical verification instead of log-based trust
• Escalation workflows that route uncertain decisions to human reviewers with full context
• A continuous audit chain that is tamper-evident and independently verifiable

You also gain operational simplicity. Rego policies for AI agent governance tend to be complex because they are encoding domain knowledge that does not belong in a policy language. Intended policies are simpler because the domain knowledge is in the Domain Intelligence Packs, not in the policies themselves.

When to Stay with OPA

To be clear: if your AI agents only perform simple, well-structured operations with binary authorization requirements, OPA may be sufficient. If your agents interact with a single system, the intent is always clear from the request structure, and your compliance requirements do not mandate cryptographic proof, OPA is a fine choice.

Intended is for organizations where AI agents operate across multiple domains, where intent is ambiguous, where risk needs to be scored rather than binary, and where compliance requires provable authorization.

If that describes your environment, read the migration guide for step-by-step instructions. If you are not sure, start with Intended's free tier and run it in observe mode alongside your existing setup. The data will tell you whether you need the upgrade.