Cedar can’t say “warn”.

When you ship a policy schema in 2026, you get one question: why didn’t you just use Cedar?

It is the right question. Cedar is excellent at authorization. AWS is pushing it hard. Verified Permissions is real. The ecosystem is growing. Anyone building a policy layer in the same year without a public reason to fork the stack should be asked to defend the decision.

So we ran the audit before we wrote a line of schema. Here is what we adopted, what we couldn’t adopt, and the condition under which we’d flip our own defaults.

What we adopted verbatim

The rule for this project was: invent nothing you can borrow.

• JSON Schema 2020-12 as the meta-format — so linters, IDEs, and CI validators just work.
• Cedar as a bidirectional interchange format. Any Conduct pack renders as annotated Cedar text; any Cedar policy from AWS Verified Permissions can be imported back in. Roundtrip is lossless on schema v1.
• MITRE ATLAS, OWASP Agentic Top 10, NIST AI RMF, ISO 42001, ISO 27001, PCI DSS, SOC 2, HIPAA, GDPR, and SR 11-7 as tag prefixes on the frameworks[] array. Buyers already know these vocabularies. We use them unchanged.
• Namespaced annotations map so metadata from OPA, Kyverno, Cedar, or your own tooling roundtrips through Conduct without loss.

That covers most of the surface. The remaining gap is where we had to author.

Why AWS Cedar first among many

Of every existing policy language, we shipped the Cedar exporter first. Four reasons, none of them AWS loyalty:

• Largest existing installed base. AWS Verified Permissions is the biggest managed policy service in production. If a customer already has policies, they most likely have them in Cedar. Making the roundtrip lossless means they don’t have to rewrite anything to try us.
• Modern, purpose-built, permissive. Cedar is BSD-2-Clause open source, born in 2023 for the exact problem shape we care about — authorization decisions evaluated in milliseconds — not a legacy XML dialect (XACML) or a Turing-complete language pretending to be a schema (Rego).
• Annotation model roundtrips cleanly. Cedar’s @annotation mechanism maps one-to-one with our namespaced annotations map. Metadata crosses the boundary without loss. OPA package comments and Kyverno labels do not have this property natively — they need bespoke serialization.
• AWS Bedrock AgentCore is investing here. AWS is actively pushing Cedar as the policy layer for agent scenarios. If any incumbent ships first-class agent primitives in the next 18 months, it will be them. Being in-lane with that gravity is worth more than pretending it isn’t happening.

That is why Cedar first. It is not why Cedar only.

Why not Cedar-only

Every policy language ships with an implicit cloud alignment. Cedar-only means AWS-only. That is a bet not every buyer wants to make, and honestly not one we want to make either. The other ecosystems are load-bearing for real teams:

• OPA / Rego runs Kubernetes admission, service mesh policy, and API gateways across every cloud.
• Kyverno is the Kubernetes-native admission standard for teams that want YAML instead of Rego.
• HashiCorp Sentinel owns Terraform pre-apply policy. If your infra pipeline gates on Sentinel, your agent’s Terraform changes need to speak that dialect.
• XACML still lives in older enterprise IAM stacks. Legacy, but real.

The good news: the roundtrip machinery already exists. Our namespaced annotations map is designed to carry OPA, Kyverno, and Cedar metadata simultaneously without loss. The export engines are a shipping question, not a design question. Each is a two- to three-week engineering project when a real customer asks. Cedar shipped first; the others ship on demand.

The mapping table on /docs/schema walks every concept — rule id, decision, actor, resource, match condition, severity, compliance, metadata, enforcement point — across all six policy languages. Every field we ship has a corresponding field in at least three of them. The category is new. The vocabulary isn’t.

Five things Cedar cannot express

Cedar 4.5 is still principal / action / resource with permit and forbid. Excellent scope for authorization. Wrong scope for agentic tool-call policy. Here is what breaks when you try to force-fit it.

1. Non-binary decisions

Agentic policy needs at least four decisions beyond allow. warn proceeds but flags. inject prepends context to the prompt. audit records without deciding. approval pauses the run until a human answers. Encoding these as Cedar obligations pushes semantics out of the policy language and into runtime convention — the exact anti-pattern Cedar was designed to prevent.

2. Free-text pattern matching

Cedar’s like is glob, not regex. Its condition grammar targets structural attribute checks, not scanning LLM prompts for card numbers, secrets, or PII. Regex over tool_input.prompt is our common case. Wedging it into Cedar loses linter and IDE support without giving you a stronger primitive in return.

3. Enforcement-surface metadata

Every Conduct rule declares which of four surfaces — proxy, pre-tool hook, MCP guard_check, workflow runtime — can hard-block it versus advise it. Cedar assumes one PDP. It has no concept of “which enforcement point evaluates me.” That metadata is load-bearing for us: it tells buyers where a rule can actually stop something versus where it can only tell them after.

4. Compliance frameworks as searchable fields

Auditors ask “show me every rule tagged NIST_AI_RMF:MG-2.6.” Cedar can carry that as @annotation, but annotations are opaque strings — no schema, no validation, no searchable field. Our frameworks[] array is queryable by construction. It matters because the compliance surface is how these packs get sold.

5. The pack container

Cedar policies are individual documents. What we ship are bundles — slug, version, tier, UI hints, rules array. Pack-as-unit is what customers install, version, and publish. Cedar has no equivalent.

The one-liner

Interchange means: portability guarantee, escape hatch, no lock-in. Authoring means: what pack authors type, what CI validates, what customers install. We optimized each for its job.

The flip condition

Standards move. If any of the ecosystems above — Cedar, OPA, Kyverno, Sentinel — ships first-class primitives for agentic tool calls (non-binary decisions, prompt content matchers, enforcement-surface metadata) before we do, we adopt their vocabulary and generate our JSON view from it. AWS is the most likely candidate given the Bedrock AgentCore investment, but we’re not betting on a single vendor to define the category.

Until then, this schema is the honest floor. It carries every concept the incumbents carry plus the four our category needs. It exports back to Cedar today, to OPA and Kyverno on request, to Sentinel when a Terraform-heavy customer asks. Nobody gets locked in — in either direction, to any vendor.

What we’re not claiming

We are not building a general policy engine. Runtime enforcement stays Conduct-specific. What ships is a portable representation for a category none of the incumbents target: OPA/Rego is generic policy, Cedar is authorization, Kyverno is Kubernetes admission, Sentinel is Terraform. Ours is the shape between all of those — an agent invoking a tool.

The mapping table on /docs/schema walks the concept-by-concept alignment across all six engines. Every field we ship has a corresponding field in at least three of them. The category is new. The vocabulary isn’t.