Intended vs Building with OPA and Cedar

An Honest Comparison

We get asked this question every week: why would I use Intended when I could just use OPA or Cedar? It is a fair question. OPA and Cedar are excellent, well-tested, widely-adopted policy engines. We respect both projects deeply.

But there is a fundamental misunderstanding embedded in the question. OPA and Cedar are policy evaluation engines. Intended is an AI agent governance platform. A policy evaluation engine is one component of a governance platform, roughly 20 percent of what you need. The other 80 percent is what this post is about.

What OPA Gives You

Open Policy Agent is a general-purpose policy engine. You write policies in Rego, a purpose-built query language. You send OPA a JSON input document, and it evaluates your policies against that input and returns a decision. OPA is fast, well-documented, and battle-tested at companies like Netflix, Goldman Sachs, and Atlassian.

Here is what OPA gives you out of the box. A policy evaluation engine with sub-millisecond latency. A policy language (Rego) that can express complex authorization logic. A bundle system for distributing policies to multiple OPA instances. A decision log system for recording evaluation results. Integration with Kubernetes via the Gatekeeper admission controller. A large ecosystem of community policies and integrations.

This is genuinely valuable. If all you need is policy evaluation, OPA is an excellent choice.

What Cedar Gives You

Cedar is Amazon's policy language and evaluation engine, originally built for Amazon Verified Permissions. Cedar takes a different approach from OPA. Instead of a query language, Cedar uses a structured policy syntax with explicit principal, action, and resource declarations. Cedar is strongly typed, analyzable, and designed for authorization specifically rather than general-purpose policy evaluation.

Cedar gives you a clean policy syntax that reads like natural language. Static analysis tools that can detect policy conflicts. A formally verified evaluation engine. Integration with Amazon Verified Permissions for managed deployment. A type system that catches policy errors before deployment.

Cedar's design is elegant. If you are building a traditional RBAC or ABAC system, Cedar is arguably better than OPA because it was purpose-built for authorization.

The Missing 80 Percent

Here is where the comparison gets honest. Neither OPA nor Cedar provides the following capabilities, and you will need all of them to build a real AI governance platform.

Intent Classification

When an AI agent says "I want to delete the production database backup from last Tuesday," that is natural language. Before you can evaluate a policy, you need to classify that intent into a structured format. What domain is this? Data management. What action category? Deletion. What resource type? Database backup. What environment? Production. What risk level? High.

OPA and Cedar accept structured JSON inputs. They do not help you get from natural language to structured input. Intended's intent compiler handles this classification automatically, mapping natural language agent requests to the Intended Intent Reference taxonomy of 14 domains and 100-plus categories.

Cryptographic Decision Tokens

When OPA or Cedar makes a decision, the result is a JSON object. There is no cryptographic proof that the decision was made, when it was made, or that it has not been tampered with. You get a JSON blob and a log entry.

Intended issues cryptographic authority tokens for every decision. These tokens are signed, timestamped, and include a nonce for replay protection. An agent cannot execute an authorized action without presenting a valid token. The token itself is the proof of authorization.

Hash-Chained Audit Trails

OPA's decision logs record evaluation results, but they are plain log entries. There is no cryptographic chain linking one decision to the next. If someone modifies a log entry, there is no detection mechanism.

Intended's audit subsystem maintains a hash-chained ledger. Each decision record includes the hash of the previous record, creating a tamper-evident chain. If any record is modified, the chain breaks and the tampering is detectable during verification.

Risk Scoring

OPA and Cedar give you binary decisions: allow or deny. Some OPA policies can return structured data, but the engine does not have a built-in concept of risk scoring.

Intended evaluates risk across eight dimensions: scope of impact, reversibility, data sensitivity, environment classification, regulatory implications, historical patterns, velocity, and agent trust level. The result is a composite risk score that drives dynamic policy decisions: allow, allow-with-conditions, escalate, or deny.

Connector Normalization

AI agents interact with dozens of systems: GitHub, Jira, Salesforce, ServiceNow, AWS, Kubernetes, databases, internal APIs. Each system has its own event format, its own webhook structure, its own data model.

OPA and Cedar do not handle this. You need to build normalization layers for every system your agents interact with. Intended's connector framework normalizes events from all supported systems into a unified intent format that the Authority Engine can evaluate.

Escalation Workflows

When a policy decision is not clear-cut, someone needs to review it. OPA returns a decision. What happens when that decision is "maybe"? You need an escalation system: routing logic, reviewer assignment, approval workflows, timeout handling, and audit trails for the escalation process itself.

Intended includes a built-in escalation engine. When a decision falls into an ambiguous zone, the engine routes it to the appropriate human reviewer based on domain, severity, and team configuration. The original agent request is held in a pending state until the human resolves the escalation.

Domain Packs

Different industries and use cases have different governance requirements. A financial services company deploying AI agents for trade execution has fundamentally different policy needs than a SaaS company using agents for customer support.

OPA and Cedar have community policy libraries, but nothing equivalent to domain-specific governance packs. Intended ships 14 domain packs covering infrastructure, SecOps, SDLC, SaaS operations, data management, compliance, financial operations, customer operations, HR operations, legal operations, content operations, communication operations, supply chain, and AI/ML operations.

The Build-vs-Buy Math

Let us be concrete about what it takes to build all of this on top of OPA or Cedar.

Intent classification: 2-3 engineers for 3-4 months to build a basic classifier. Ongoing maintenance as your agent capabilities expand. You need training data, evaluation benchmarks, and a deployment pipeline for model updates.

Cryptographic tokens: 1-2 engineers for 2-3 months. You need key management, token signing, verification, rotation, and revocation. Getting the cryptography right is critical and subtle.

Hash-chained audit: 1 engineer for 2-3 months. Serializable transactions, chain verification, and repair procedures for chain breaks.

Risk scoring: 1-2 engineers for 2-3 months. You need to define your risk dimensions, calibrate weights, build the scoring pipeline, and validate against real-world decisions.

Connector normalization: 1 engineer per connector, 2-4 weeks each. For 7 connectors, that is 4-7 months of engineering time.

Escalation workflows: 1-2 engineers for 2-3 months. Routing logic, reviewer management, notification system, timeout handling, audit trails.

Domain packs: 1-2 engineers plus domain experts for 3-6 months per domain.

Total: roughly 8-12 engineers for 6-12 months. That is before you account for ongoing maintenance, security patching, SOC 2 compliance for your governance layer, and on-call operations.

Or you can use Intended, which includes all of this as a managed platform. The policy engine is important, and both OPA and Cedar are excellent at what they do. But the policy engine is 20 percent of the problem. The other 80 percent is what makes it a governance platform.

When to Use OPA or Cedar Directly

We are not saying everyone needs Intended. If your requirements are limited to traditional infrastructure policy enforcement -- Kubernetes admission control, API gateway authorization, or cloud resource policy evaluation -- OPA and Cedar are excellent choices. They are mature, performant, and well-supported.

Intended is specifically for AI agent governance: the scenario where autonomous software agents are making decisions and taking actions in your production systems, and you need to classify, authorize, audit, and control those actions with cryptographic proof and compliance-grade evidence.

If that is your problem, using OPA or Cedar as a foundation means building the other 80 percent yourself. We built Intended so you do not have to.