--- title: How to Govern AI-Generated Infrastructure with Policy as... description: A hands-on handbook walks through building Policy as Code guardrails with Open Policy Agent (OPA) and Rego to catch security and compliance problems in... canonical: https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: How to Govern AI-Generated Infrastructure with Policy as Code and OPA [Full Handbook] | daily.dev og:description: A hands-on handbook walks through building Policy as Code guardrails with Open Policy Agent (OPA) and Rego to catch security and compliance problems in... og:url: https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm og:image: https://api.daily.dev/og/posts/CgwUXyoBm.png og:image:alt: How to Govern AI-Generated Infrastructure with Policy as Code and OPA [Full Handbook] og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # How to Govern AI-Generated Infrastructure with Policy as Code and OPA [Full Handbook] **[freeCodeCamp](https://daily.dev/sources/freecodecamp)** · 40 min read · 1 upvotes · 0 comments ## Summary A hands-on handbook walks through building Policy as Code guardrails with Open Policy Agent (OPA) and Rego to catch security and compliance problems in AI-generated infrastructure code. Starting from research showing roughly 44-56% of AI-generated code introduces vulnerabilities, the piece builds a Rego policy against a deliberately vulnerable Terraform repository (TerraGoat), tests it with fixtures, wraps it in a CI gate with a meaningful exit-code contract, extends enforcement to Kubernetes admission control via ValidatingAdmissionPolicy/CEL, has an LLM (Claude) generate policies validated only by opa check/opa test, and finally authorizes AI agent tool calls through the same OPA engine using a three-way allow/deny/require_approval decision model. A dedicated section confesses concrete mistakes the author made along the way — missed ingress rule shapes, a null-tags bug, an all-protocols port range bug — showing that 100% test coverage still missed real vulnerabilities. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does my OPA security group policy miss wide-open SSH access even though it checks cidr_blocks? Terraform can describe the same ingress rule in four different shapes: inline aws_security_group ingress blocks with cidr_blocks, the same block's ipv6_cidr_blocks field, the standalone aws_vpc_security_group_ingress_rule resource, and the deprecated aws_security_group_rule resource. A policy that only reads aws_security_group.ingress[].cidr_blocks silently passes traffic exposed through the other three shapes, producing zero violations on a plan with three publicly reachable SSH ports. _daily.dev surfaces practical writeups like this for teams hardening Terraform policy checks against real-world gaps._ ### Why does an OPA policy checking from_port and to_port fail to catch an AWS security group rule with protocol set to -1? AWS records an all-protocols ingress rule with from_port and to_port both set to 0, which opens every port on every protocol, but a naive policy that reads those fields literally treats it as only exposing port zero and clears the rule as safe. The fix is a covered_ports function that maps protocol -1 (or "all") to the full 0-65535 range before checking it against admin ports, and flags any rule whose ports can't be read as a violation rather than passing it. _developers writing infrastructure guardrails can find deep dives like this one through daily.dev to avoid the same all-protocols blind spot._ ### Since when has ValidatingAdmissionPolicy been generally available in Kubernetes, and what does it let you do without a webhook? ValidatingAdmissionPolicy has been generally available since Kubernetes v1.30, letting the API server evaluate CEL expressions natively at admission time with no external webhook to deploy or keep alive. It can inspect all three container lists on a Pod (containers, initContainers, ephemeralContainers) to enforce rules like requiring images from a trusted registry, and MutatingAdmissionPolicy became stable in v1.36 for the same in-server approach to mutation. _track Kubernetes admission-control changes like this on daily.dev before rolling out new cluster policies._ ## Similar posts on daily.dev - [Governance That Ships: Embedding Policy as Code Into Your System of Record](https://daily.dev/posts/governance-that-ships-embedding-policy-as-code-into-your-system-of-record-k5du9rdlm) · JFrog · 0 upvotes · 0 comments - [What Is Open Policy Agent? Best Practices and Use Cases](https://daily.dev/posts/what-is-open-policy-agent-best-practices-and-use-cases-wqsdtv48j) · Orca Security Blog · 0 upvotes · 0 comments - [Terraform Compliance and Governance Guide](https://daily.dev/posts/terraform-compliance-and-governance-guide-xfo3gbkpo) · Spacelift · 1 upvotes · 0 comments - [Governing AI in the Cloud: A Practical Guide for Architects](https://daily.dev/posts/governing-ai-in-the-cloud-a-practical-guide-for-architects-isy5nywua) · InfoQ · 0 upvotes · 0 comments - [Governance as Code for DevOps: A Practical Guide](https://daily.dev/posts/governance-as-code-for-devops-a-practical-guide-3fq0lpced) · Spacelift · 1 upvotes · 0 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#terraform](https://daily.dev/tags/terraform), [#policy-as-code](https://daily.dev/tags/policy-as-code) [View this post on daily.dev](https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"How to Govern AI-Generated Infrastructure with Policy as Code and OPA [Full Handbook]","url":"https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm"},"datePublished":"2026-09-29T14:01:34.923Z","dateModified":"2026-09-29T14:02:02.945Z","description":"A hands-on handbook walks through building Policy as Code guardrails with Open Policy Agent (OPA) and Rego to catch security and compliance problems in...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b0e7d18cfb61c04f0978e580710c8937?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b0e7d18cfb61c04f0978e580710c8937?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"freeCodeCamp","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"freeCodeCamp","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1628412854/logos/freecodecamp","url":"https://daily.dev/sources/freecodecamp"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes,terraform,policy-as-code","timeRequired":"PT40M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"freeCodeCamp","item":"https://daily.dev/sources/freecodecamp"},{"@type":"ListItem","position":3,"name":"How to Govern AI-Generated Infrastructure with Policy as Code and OPA [Full Handbook]"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/how-to-govern-ai-generated-infrastructure-with-policy-as-code-and-opa-full-handbook--cgwuxyobm#faq","mainEntity":[{"@type":"Question","name":"Why does my OPA security group policy miss wide-open SSH access even though it checks cidr_blocks?","acceptedAnswer":{"@type":"Answer","text":"Terraform can describe the same ingress rule in four different shapes: inline aws_security_group ingress blocks with cidr_blocks, the same block's ipv6_cidr_blocks field, the standalone aws_vpc_security_group_ingress_rule resource, and the deprecated aws_security_group_rule resource. A policy that only reads aws_security_group.ingress[].cidr_blocks silently passes traffic exposed through the other three shapes, producing zero violations on a plan with three publicly reachable SSH ports. daily.dev surfaces practical writeups like this for teams hardening Terraform policy checks against real-world gaps."}},{"@type":"Question","name":"Why does an OPA policy checking from_port and to_port fail to catch an AWS security group rule with protocol set to -1?","acceptedAnswer":{"@type":"Answer","text":"AWS records an all-protocols ingress rule with from_port and to_port both set to 0, which opens every port on every protocol, but a naive policy that reads those fields literally treats it as only exposing port zero and clears the rule as safe. The fix is a covered_ports function that maps protocol -1 (or \"all\") to the full 0-65535 range before checking it against admin ports, and flags any rule whose ports can't be read as a violation rather than passing it. developers writing infrastructure guardrails can find deep dives like this one through daily.dev to avoid the same all-protocols blind spot."}},{"@type":"Question","name":"Since when has ValidatingAdmissionPolicy been generally available in Kubernetes, and what does it let you do without a webhook?","acceptedAnswer":{"@type":"Answer","text":"ValidatingAdmissionPolicy has been generally available since Kubernetes v1.30, letting the API server evaluate CEL expressions natively at admission time with no external webhook to deploy or keep alive. It can inspect all three container lists on a Pod (containers, initContainers, ephemeralContainers) to enforce rules like requiring images from a trusted registry, and MutatingAdmissionPolicy became stable in v1.36 for the same in-server approach to mutation. track Kubernetes admission-control changes like this on daily.dev before rolling out new cluster policies."}}]} ```