When we started building DevPlus, we knew that self-serve infrastructure without guardrails is just chaos with a nicer UI. Engineers need to move fast, but platform teams need control over what gets deployed, by whom, and under what conditions.
Simple role-based access control wasn't going to cut it. We needed something declarative, composable, and powerful enough to express rules like "forbid any deployment over $1,000/month unless the principal is an admin" or "block destructive resource replacements outside business hours." That's why we built our governance engine on Cedar.
Why Cedar?
Cedar is an open-source policy language created by AWS. It's purpose-built for authorization , not configuration, not infrastructure-as-code, just authorization. That focus gives it a clean, readable syntax that both engineers and security teams can understand at a glance.
A Cedar policy reads like a sentence: permit this principal to perform this action on this resource, when these conditions are true. Or forbid it. The evaluation engine handles the composition , multiple policies are evaluated together, forbid always wins over permit, and if nothing matches, the default is deny.
Two Enforcement Points, One Engine
Our governance engine sits as a dedicated microservice and evaluates policies at two critical points:
- Request-time authorization , Every API call is evaluated against Cedar policies before it reaches a handler. The principal, the HTTP method, the resource path, and contextual attributes like role, project tags, and time of day all feed into the decision.
- Pre-apply deployment gating , After Terraform plans but before apply, the executor sends the plan details to the governance engine. Cost estimates, resource change counts, destructive replacements , all of it becomes context for Cedar to evaluate against your policies.
This means governance isn't bolted on after the fact. It's woven into the deployment lifecycle at the two moments that matter most: when you ask to do something, and right before it actually happens.
What You Can Express
Because Cedar supports rich context, our governance policies can go far beyond "admins can do everything." Here are real examples of what teams define:
- Cost guardrails , Forbid deployments where the estimated monthly cost exceeds a threshold
- Blast-radius limits , Block applies that replace existing resources or modify more than N resources at once
- Temporal constraints , Restrict production deployments to business hours or specific days of the week
- Project-scoped rules , Apply different policies based on project tags, environment, or team ownership
- Agent permissions , Each AI agent (deploy, delete, cost analysis, health) gets a scoped policy defining exactly which actions it can perform
Governance should be a conversation between intent and policy , not a wall that engineers learn to climb over.
Dynamic Policies, Zero Downtime
Policies can be defined as static Cedar files that ship with the service, or created dynamically through the admin UI. Dynamic policies are stored in the database, converted to Cedar syntax automatically, and hot-reloaded into the governance service without a restart.
This means a platform team can respond to a security incident by adding a new forbid policy, and it takes effect across the entire system within seconds. No deploys, no pull requests, no waiting.
Fail-Closed by Default
When the governance service is unreachable, deployments are blocked , not allowed. This fail-closed default is critical for enterprise environments where a governance gap is worse than a deployment delay. For teams that prioritize availability, we offer a configurable fail-open mode, but the secure default is always deny.
What's Next for Governance
We're just getting started. Our roadmap includes policy simulation (test a new policy against historical decisions before enabling it), approval workflows triggered by policy violations, and richer context from Discovery , so governance decisions can factor in the actual state of your infrastructure, not just the planned changes.
If you're building a platform where engineers self-serve infrastructure, governance isn't optional , it's the foundation. Cedar gives us the expressiveness to make it powerful and the simplicity to make it usable.