Infrastructure governance for rule breakers: How to make guardrails invisible
Platform engineering teams face an impossible balancing act: deliver infrastructure faster while maintaining security, compliance, and cost controls. The solution lies in embedding governance directly into deployment workflows, creating invisible guardrails that eliminate bottlenecks without sacrificing safety.
TL;DR: Main Insights
- Manual governance processes create deployment bottlenecks that prevent platform teams from matching the speed AI-enabled development teams now demand
- Invisible guardrails work by embedding policy checks directly into the deployment workflow, automating approvals and enforcement before infrastructure goes live
- Project-based templates and hierarchical policy inheritance enable self-service infrastructure while maintaining consistent governance across thousands of environments
- Dynamic approval thresholds allow platform teams to differentiate between minor violations requiring developer approval and critical issues requiring platform team review
Robert Coppasmith leads customer engineering at env0 with deep experience in cloud automation and enterprise software, previously holding senior roles at IBM and IBM Turbonomic. Ardum Martinov serves as Director of Solutions Architecture at env0, supporting implementation and use case development for platform engineering teams.
You can watch the full discussion here if you missed it.
The platform engineering bottleneck: When speed meets governance
Platform engineering teams today manage hundreds of repositories and thousands of environments across multiple engineering teams. As Coppasmith explains, "Most of the organizations that we work with have on the low side hundreds of repositories, right? Definitely know a few that are probably reaching the thousands, right? And from an environment standpoint and infrastructure standpoint, we're usually in the thousands of environments there."
This scale creates significant challenges. Teams must maintain security requirements, ensure reliability, enforce compliance standards, and control costs - all while supporting increasingly rapid deployment cycles. The AI era compounds these pressures through two specific effects.
Environment explosion occurs when AI model training and testing require massive infrastructure resources. Martinov describes a healthcare customer scenario: "I can picture one team standing up an isolated environment just for validating new clinician-facing AI workflows, right? And by the end of the day those environments, within one day you can have as many as two or three dozen environments spun up and gone."
Barrier-free creation accelerates development velocity as AI tools enable engineers to accomplish in minutes what previously took hours. Coppasmith notes, "No longer takes me like five hours to sit down and work through a large piece of code, right? With AI helping me, that could be done in an hour, if not in minutes."
The result? A growing gap between how fast platform teams can move through manual governance processes and how fast the business demands infrastructure delivery.
Why traditional governance breaks down
Manual governance processes cannot scale to meet modern deployment velocity. Coppasmith identifies the core problem: "Manual governance will never be able to meet the speed that is required to deliver infrastructure as quickly as the business needs today."
Traditional approaches rely on:
- Manual approvals for every deployment
- Manual security reviews by centralized teams
- Manual ticket creation and tracking
- Centralized DevOps teams reviewing every change
This creates deployment delays, bottlenecks, and inconsistent policy enforcement. The discrepancy becomes critical when AI-enabled development teams operate at one speed while platform teams remain constrained by manual processes. As Martinov explains, "The bottleneck is no longer the creation, the bottleneck becomes the governance."
The evolution toward embedded governance
Platform engineering has progressed through three distinct phases, each focused on increasing speed:
Phase 1: Automation introduced scripting, CI/CD pipelines, and infrastructure as code to accelerate deployments.
Phase 2: Self-service provided developers with pre-approved infrastructure catalogs, eliminating the need to submit requests for common resources.
Phase 3: Governance embeds policy enforcement directly into deployment workflows, enabling teams to move at full speed without sacrificing safety.
Coppasmith emphasizes the critical insight: "Until organizations feel comfortable that there is a safety net or that there are mechanisms in place to check these things as they go, you will never reach the desired speed that you probably can."
The key is making governance and infrastructure delivery a single unified process rather than separate sequential steps.
How invisible guardrails work in practice
The invisible guardrail approach inserts automated policy checks immediately after the plan stage in deployment workflows, before any merge or apply occurs. This architecture includes:
Multi-layer policy engine that automates security checks, cost validation, and operational constraints without human intervention.
Dynamic approval mechanisms that only require human review for exceptions worth consideration, not every deployment.
Pre-deployment enforcement that catches violations before infrastructure goes live rather than detecting problems after deployment.
Coppasmith demonstrates this with a concrete example: "Right after the plan, before any merge and commit takes place or any apply takes place is where this governance policy runs. Not only are we letting, well the benefit of this is you can almost remove the human being from the plan review step and just have and just offload that basically to the governance engine."
Templates and projects: The foundation of self-service governance
Two foundational concepts enable invisible guardrails at scale:
Projects function as logical workshops where users deploy infrastructure. Platform teams assign users to projects and configure project-level policies that automatically apply to all deployments within that project.
Templates serve as blueprints pointing to infrastructure as code in version control systems. Templates enable platform teams to attach governance controls that would be difficult to enforce directly in code.
Martinov describes the user experience: "You have a stencil catalog. You come in here, you build a stencil. This is part of the governance piece that we were talking about earlier, right? Only certain people could have access to the stencil and that's all they deploy. It's repeatable. It's controllable and it's simple to use."
When developers create new environments, they see only templates explicitly assigned to their project - a pre-approved catalog of infrastructure they can deploy without platform team involvement.
Policy enforcement with nuance and flexibility
Effective governance requires more than binary pass/fail checks. The platform demonstrates how to implement graduated policy responses:
During the demonstration, Coppasmith deploys an EC2 instance that violates two cost policies. The deployment enters a "waiting for approval" state, clearly showing why: the $55.70 monthly cost exceeds both a $15 threshold and a 200% overage limit.
The platform supports multiple violation levels:
- Pending - requires approval but allows deployment to proceed
- Warn - flags the issue with higher severity
- Deny - blocks deployment entirely
Coppasmith explains the flexibility: "If I wanted the engineers themselves to be able to approve maybe a lesser violation without having to bother the platform team I can do that. And certainly so for larger violations I can always assign that to a specific team."
This graduated approach removes platform teams from routine approvals while ensuring critical violations receive appropriate review.
Hierarchical policy inheritance reduces administrative overhead
Project hierarchies enable policy reuse across organizational structures. Policies set at parent project levels automatically apply to all child projects, eliminating the need to configure identical policies in multiple locations.
Coppasmith demonstrates this during the deployment: "Anything set at a higher level will trickle down to the lower entities. The developer services project is actually our parent project. So we are inheriting this rule from a top level."
This inheritance model makes policy administration scalable even across thousands of environments.
If you enjoyed this, find here more great insights and events from our Platform Engineering Community.
If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.
Key takeaways
- Embed governance into deployment workflows rather than treating it as a separate approval process. This eliminates the speed gap between infrastructure delivery and policy enforcement, allowing platform teams to match the velocity AI-enabled development teams now demand.
- Use templates and project-level policies to enable self-service without sacrificing control. Pre-approved infrastructure catalogs combined with hierarchical policy inheritance let developers deploy what they need while ensuring consistent governance across thousands of environments.
- Implement graduated policy responses instead of binary pass/fail checks. Dynamic approval thresholds allow minor violations to proceed with developer approval while escalating critical issues to platform teams, reducing bottlenecks without compromising safety.
- Shift policy enforcement left to catch violations before deployment. Running automated checks immediately after the plan stage prevents problems from reaching production while providing clear feedback about why deployments are blocked, making governance invisible to compliant workflows.
