Migrating from Cedar / AWS Verified Permissions

Move an existing Cedar or AWS Verified Permissions (AVP) deployment onto Vengtoo in four stages, without a big-bang cutover:

Discover → Translate (into a non-prod environment) → Shadow (prove parity) → Cutover (promote → flip)

You never enforce with Vengtoo until the translation is proven to make the same decisions Cedar already makes. The safety comes from doing translation and validation in a non-prod environment, then promoting the proven model to production.

Validated

This flow has been run end-to-end against a real Cedar fintech policy set, role grants, ownership rules, an MFA-gated approval threshold, and forbid guardrails, with full decision parity confirmed on every test case.

Prerequisites

• A Vengtoo API key scoped to a non-prod environment, never translate straight into production.
• Your .cedar policy files and schema, or API access to the AVP policy store (ListPolicies / GetPolicy).
• Ideally, your existing Cedar test suite or decision logs: this becomes the coverage set for Stage 3.

Stage 1: Discover

Inventory what you actually have before mapping anything:

• Policies: the .cedar files, or the AVP policy store's contents via its API.
• Schema: entity types, actions, and attribute shapes. This maps closely onto Vengtoo resource types + attributes, so get this right first.
• Entities: the actual entity data (principals, resources, their in group memberships, and their attributes) the PEP passes at IsAuthorized time.
• A coverage set: real (principal, action, resource, context) → decision examples for Stage 3. Best sources, in order: your own Cedar test cases, your decision logs, then a generated grid across the schema if you have neither.

Stage 2: Translate

Map Cedar constructs onto the Vengtoo model:

Cedar construct	Vengtoo equivalent
permit(principal, action, resource)	an ALLOW policy
forbid(principal, action, resource)	a DENY policy at higher priority
principal in Role::"admin" / a group	a role + role assignment
a resource entity type	a resource type, with its actions declared
entity attributes (from the schema)	subject / resource attributes
when { context.mfa == true }	a context_attrs condition
when { resource.status == "locked" }	a resource_attrs condition (any fixed-value comparison works cleanly)

A forbid guardrail translated:

{
  "name": "deny-fraud-review-account",
  "effect": "DENY",
  "priority": 90,
  "resource_types": [{ "resource_type_id": "<account-type-id>", "actions": ["view", "edit"] }],
  "conditions": { "resource_attrs": [{ "key": "fraud_review", "op": "eq", "value": true }] }
}

What doesn't translate automatically

• when { resource.owner == principal }-style ownership rules. Vengtoo's ABAC conditions compare an attribute to a fixed value, not to another entity's attribute: there's no way to express "this resource's owner field must equal whoever's asking" as one reusable condition. The practical fix: generate an instance-level direct grant to the specific owner at the point the resource is created or assigned, rather than a general policy. This is real, ongoing integration work, not a one-time translation.
• Deep in hierarchies (nested groups/OUs): Vengtoo roles don't inherit from each other. Flatten each tier into its full cumulative permission set by hand; nothing keeps the tiers in sync afterward if one changes.
• Cedar record/set operations (has, .contains, complex nested &&/||): split into multiple conditions or multiple policies; there's no direct equivalent of an arbitrary boolean expression.
• Template-linked policies (AVP policy templates): expand to concrete policies at translation time, or model the template parameter as an attribute condition.
• Anything computed relative to another field (a time delta, a threshold that moves with a resource's own timestamp), not expressible today. Flag it and decide whether it needs to stay enforced elsewhere in application code for now.

Hand the actual model creation to /vengtoo-policies once you've worked out the mapping: this guide gives you the mapping, that skill builds the resource types, roles, policies, and conditions.

Stage 3: Shadow: prove parity before anything depends on it

Replay your Stage 1 coverage set through Vengtoo's evaluation endpoint in the non-prod environment, and diff every decision against what Cedar actually returned:

curl -X POST https://api.vengtoo.com/access/v1/evaluation \
  -H "Authorization: Bearer $VENGTOO_API_KEY" -H "Content-Type: application/json" \
  -d '{"subject":{"type":"user","external_id":"..."},"resource":{"type":"...","external_id":"..."},"action":{"name":"..."},"context":{}}'

Categorize every result:

• Match: good.
• False allow (Vengtoo allows, Cedar denied): the dangerous class; a policy is too broad or a DENY/condition is missing. Fix before anything else.
• False deny (Vengtoo denies, Cedar allowed): will break real access; usually a missing policy or a broken role assignment.

Don't move to Stage 4 until parity holds, or every remaining divergence is explained and intended (e.g. you're deliberately fixing a bug Cedar had).

Stage 4: Cutover

1. Promote the validated model from your non-prod environment to production: this carries drift detection and provenance, so you ship the exact model you proved, not a hand-rebuild.
2. Wire the enforcement point: the flip is either a config change or a code swap, not new integration logic:
   • In-app SDK enforcement: replace the Cedar isAuthorized call with the Vengtoo SDK's Check()/Evaluate().
   • Gateway/MCP enforcement: point your gateway at Vengtoo's ext_authz endpoint. See the Kong, Envoy, agentgateway, or IBM ContextForge guides for the actual wiring.
3. Roll out gradually: flip one route, service, or tenant at a time, and watch the decision log for divergence as you expand. Keep Cedar running as a fallback.
4. Rollback = point back at Cedar. It keeps running until you deliberately decommission it, so cutover is always reversible.

Run it with an AI coding agent

The /vengtoo-migrate skill runs this entire flow: it reads your Cedar policies and schema, does the mapping above, builds the model via /vengtoo-policies, and runs the shadow-compare for you.