Checkov Static Analysis for Infrastructure-as-Code in AI Pipelines
AI agents write Terraform modules and Kubernetes manifests routinely now, often shipping a full feature, infrastructure included, faster than a human engineer can finish reading the ticket. I've been digging into one narrow fix for one specific gap: Checkov as the static analysis gate that catches misconfigurations in that generated infrastructure code before any of it runs.
Why does the gap matter so much? Models trained on public repositories copy insecure patterns because pattern-matching at scale means a model will happily reuse the wildcard IAM policy that showed up a thousand times in its training data. Studies from early 2026 put AI-generated code at roughly 40% more secrets exposure than hand-written code, wide enough that treating the scan as optional stops making sense. Gartner has argued for years that through 2025, 99% of cloud security failures trace back to the customer rather than the cloud provider, and misconfigured infrastructure code is a primary way that failure happens. When AI writes the infrastructure, the human review step that used to catch a stray 0.0.0.0/0 rule gets thin or disappears outright, so something automated has to fill that gap before an apply command runs.
What Checkov is and how it actually works
Checkov started as an open-source project out of Bridgecrew, which Palo Alto Networks bought in 2021. The commercial layer lives inside Prisma Cloud now, but Checkov itself stayed free and Apache 2.0 licensed. I went in expecting the usual pattern of acquired open-source tools getting quietly walled off after a deal like that. This one stayed open, and that's worth noting rather than assuming.
What it does is simple to describe, even if the code underneath isn't. It reads your infrastructure files, checks them against a library of rules, and flags anything that looks wrong before a single resource gets provisioned. That library is big; Checkov.io lists more than 750 built-in policies, putting it among the largest rule sets I could find among open-source scanners for infrastructure code.
Format coverage matters a lot for AI pipelines, since an agent might produce Terraform one day and a Helm chart the next. Checkov reads Terraform (both HCL and plan output), OpenTofu, CloudFormation, AWS SAM, Kubernetes manifests, Helm charts, Kustomize overlays, Dockerfiles, ARM templates, Bicep, the Serverless framework, and OpenAPI specs. A team doesn't need five different scanners stitched together just because their agent touches five different file types in a single sprint.
Version 3.0 added graph-based scanning, and working through what that actually changes, it's a bigger deal than the name suggests. Older static checks look at one resource and one attribute at a time: does this S3 bucket have encryption enabled, yes or no. Graph-based checks look at how resources relate to each other, catching problems that only exist because two separate pieces of infrastructure interact badly. A security group can look fine sitting alone and still open a path once you trace how it connects to a load balancer and a database subnet.
Rules come in two formats, and the split is deliberate. Python rules handle logic complex enough to need an abstract syntax tree; declarative YAML handles simpler stuff, like enforcing tags or checking CIDR ranges or catching a missing required argument. This split is a big part of why Checkov spreads inside large companies: a security engineer writes the hard Python rule once, and platform teams downstream fork a YAML version and tune it for their own namespace without touching the Python at all.
Output comes as JSON, JUnit-XML, or SARIF, and each format feeds a different consumer. JUnit-XML slots into CI dashboards that already understand test results, while SARIF feeds security tooling, including GitHub's native code scanning interface. JSON is for anything parsing the result on its own, which increasingly means another piece of automation in the pipeline rather than a person reading it.
One thing worth flagging on competitive context: Tenable deprecated Terrascan, one of the other open-source scanners for infrastructure code, when it made the repository read-only in November 2025. That leaves the open-source field concentrated mostly around Checkov and Trivy, which comes back up near the end of this piece.
The specific misconfigurations Checkov catches that matter most in AI workload infrastructure
Not all 750-plus checks carry equal weight in an AI pipeline. Sorting through which ones matter most, the pattern that emerges is that they map onto the attack surface an agent tends to create by default, when it's optimizing for getting a deployment to work rather than locking it down.
Start with permissions. AI-generated workloads get over-provisioned IAM roles constantly, mostly because broad permissions are the path of least resistance when a model is trying to make a deployment succeed rather than trying to make it minimal. Research on Fortune 50 enterprise codebases found 322% more privilege escalation paths in AI-generated code compared to human-written code. That's an order-of-magnitude shift in exposure, not a rounding error. Checkov's IAM checks go straight after this: wildcard policies, roles missing permission boundaries, service accounts bound to cluster-admin when they only need read access to one namespace.
Secrets come second. The same Fortune 50 research found a 40% jump in secrets exposure specifically. Separately, researchers scanning close to 5,600 vibe-coded applications turned up more than 400 exposed secrets sitting in plain sight. Checkov flags hardcoded credentials, environment variables carrying secret values, and configurations missing encryption at rest, catching the problem in the infrastructure definition before the secret ever reaches a running container.
Network egress deserves its own mention. NVIDIA's AI Red Team guidance treats default-deny outbound traffic as mandatory for any sandbox running agentic workloads, for good reason: an agent that can reach the open internet can exfiltrate data or pull down a second-stage payload without anyone noticing until much later. Checkov checks Kubernetes NetworkPolicy manifests to confirm a default-deny egress posture is actually written into the config rather than just assumed.
Container and pod security checks catch more mundane but no less dangerous stuff: containers running as root, missing readOnlyRootFilesystem settings, privileged mode left on. NVIDIA's guidance also calls out filesystem write restrictions outside the agent's workspace as mandatory, and Checkov's securityContext checks map onto that requirement almost one to one.
Credential isolation matters too, specifically stopping an agent from inheriting whatever secrets live on the host machine. This shows up as checks against projected secret volume configurations and workload identity bindings (IRSA on AWS, or the equivalent elsewhere), confirming an agent only gets the credentials it's explicitly supposed to have.
Resource quotas round this out. Missing limits on AI workload pods open the door to denial-of-service scenarios, and this gets sharp fast on GPU-heavy inference workloads, where one uncapped pod can quietly starve every other workload sharing that node.
One more, and maybe the most interesting structurally: the Fortune 50 research also found 153% more design flaws in AI-generated code. Sitting with that number for a moment, a single-attribute check won't catch a design flaw. Graph-based Checkov policies, the ones evaluating how resources relate rather than what each one contains alone, are the check type best positioned to surface that category of problem.
Why the infrastructure backing AI execution sandboxes needs its own scanning pass
Here's a distinction that gets missed more often than it should, and it took working through several incident reports before the shape of it became clear. There are two separate infrastructure surfaces in any AI pipeline: the code an agent generates as its output, and the code that provisions the sandbox the agent runs inside. Teams scan the first one, usually, but the second one gets forgotten, and that's the more dangerous gap.
The threat isn't hypothetical. A 2025 arXiv study running across 400 code samples documented a 37.6% jump in critical vulnerabilities after five rounds of AI-driven "improvement" on that code. Five iterations doesn't sound like much, but it's the kind of loop an agent might run through in a single afternoon. When the code itself keeps getting worse, the sandbox around it is the last structural defense standing between a bad output and real damage.
The incident evidence backs this up in a way that's hard to argue with. Researchers tested 16 public AI agents from YCombinator's Spring 2025 batch and found 7 compromised. Some leaked user data, one allowed remote code execution, and one deleted its entire database. Weak sandbox configuration let each of those happen; the agent's own code wasn't even the primary point of failure in most cases.
So what should Checkov enforce on sandbox infrastructure specifically? A dedicated namespace per sandbox, with a NetworkPolicy that restricts communication between sandboxes and not just between the sandbox and the internet. Resource quotas set at the namespace level, so one runaway agent can't eat the whole cluster. Non-root execution enforced in the pod security context, no exceptions. And no privilege escalation path available from a sandbox pod to the host machine or to a neighboring tenant's workload.
The isolation technology underneath runs a rough hierarchy, from strongest to weakest: microVMs like Firecracker or Kata Containers sit at the top, gVisor's user-space kernel sits in the middle, and plain hardened containers sit at the bottom. As of 2026, the industry no longer considers shared-kernel container isolation on its own good enough for running untrusted agent code, a real shift from where the industry stood two or three years earlier.
There's newer tooling built around this problem directly. The Kubernetes Agent Sandbox project, which came out of Kubernetes SIG Apps and got a formal presentation at KubeCon NA 2025, provides a declarative API built for isolated, stateful agent workloads. Its SandboxTemplate, SandboxClaim, and WarmPool resources are all just YAML, which means Checkov can scan them fully like anything else. Checkov can confirm that runtime class annotations, gVisor's runsc or Kata, show up in the manifest and match whatever isolation tier the team claims to run.
Purpose-built sandbox runtimes carry this same logic. Daytona, for instance, hits roughly 90-millisecond cold starts for isolated execution environments, and that speed only means something if the security posture behind it is actually enforced rather than assumed. The guarantees a runtime like that offers live in its infrastructure code and Kubernetes manifests. Running Checkov against those manifests before deployment turns a security posture into something you can check and reproduce on demand.
One more number worth sitting with: Veracode's 2025 report found that 45% of AI-generated code fails security tests outright. Even with a scanning gate catching every misconfiguration in the generated infrastructure code, a meaningful chunk of the code that reaches execution is still going to be insecure. That's why the sandbox boundary can't be an afterthought. It's the backstop for everything the earlier gate missed.
How Checkov fits into the CI/CD pipeline where AI agents generate or consume IaC
Placement is the whole game here. Checkov needs to run after the infrastructure code gets written or changed, whether by a human or an agent, and before any terraform apply or kubectl apply fires. A check that happens as an audit somewhere downstream functions more like a report card that arrives after the damage is done than a gate.
Two integration points matter most in AI-driven pipelines. A pre-commit hook catches problems before anything reaches the repository, and it's the fastest feedback loop around, but it only works when the agent or developer sits in an environment where that hook actually fires. The CI/CD step, whether that's GitHub Actions, GitLab CI, or Azure DevOps, is the real authoritative gate: it runs on every push or pull request, it can block a merge or an apply outright when a policy fails, and it produces SARIF output that feeds straight into a security dashboard.
When an agent generates infrastructure code as its output, the flow looks like this. The agent writes Terraform or Kubernetes YAML into a working directory, or opens a pull request directly, and Checkov runs against that output before any downstream automation is allowed to apply it. Failed checks show up as pipeline annotations or PR comments, and the agent's output gets treated exactly the same way a human's would, with no special exemption and no lighter scrutiny because "it's just the AI."
One detail that trips people up: scanning the Terraform plan JSON, not just the raw HCL source, catches misconfigurations that only surface after variable substitution and module resolution actually happen. This matters more when an agent parameterizes Terraform with values it decides at runtime, since the source file alone can look perfectly clean while the resolved plan tells a different story.
For companies running many repositories, AWS's own prescriptive guidance documents a pattern worth copying: keep custom Checkov policies in one repository, owned by the security team, and pull that policy set automatically into every pipeline across the org. AI pipelines spanning multiple repos inherit the same policy set this way, with no per-repo setup needed and no drift between teams.
Which output format to pick depends on who's consuming the result. JUnit-XML slots into CI dashboards that already understand test results, making policy failures look and feel like test failures to engineering teams already wired for that workflow. SARIF feeds security tooling and GitHub's native code scanning. JSON is the one to reach for when a downstream agent or orchestrator needs to parse the result and decide on its own whether to proceed.
Most teams start Checkov in warn mode, non-blocking, while they tune the policy set and get a feel for the false-positive rate, then flip to hard-fail once that rate is understood. It's a staged rollout, and it exists specifically to avoid the scenario where a brand-new scanner blocks half the team's merges on day one over checks nobody's reviewed yet.
Writing custom Checkov policies for AI-specific infrastructure patterns
The built-in library covers well-understood cloud misconfigurations, the kind that existed long before anyone talked about AI agents. It has no idea what a misconfigured WarmPool looks like, and it doesn't know, out of the box, that an agent namespace should never carry a wildcard egress NetworkPolicy. That's where custom policies come in, and skipping them isn't really an option once you're running agent infrastructure at any real scale.
Python custom checks subclass BaseResourceCheck, or BaseGraphCheck when the logic needs to understand relationships between resources rather than one resource sitting alone. You define which resource types the check applies to, give it a check ID, and write the actual logic inside scanresourceconf. This format suits RBAC checks tuned to AI workload service accounts, GPU resource limit enforcement, or checking that an agent's identity binding is actually what it claims to be. Graph-aware checks can enforce something like: every inference deployment must have a matching NetworkPolicy that defaults to deny on egress.
YAML custom policies stay declarative: you name the resource type, point at an attribute path, and state the condition you expect to hold. These work well for tag enforcement on AI workload namespaces, required annotation checks, or checking CIDR ranges on inference endpoint network policies. The barrier to entry is lower too, which matters for platform teams and security engineers who don't have a Python developer on staff and don't want to pull one in just to write a tagging rule.
A few AI-specific policies worth writing down and actually enforcing. Require every pod in an agent namespace to declare a runtimeClassName, either gVisor or Kata, so a manifest can't silently fall back to plain shared-kernel runc without anyone noticing. Require resource limits on any container requesting GPU access, so one agent workload can't quietly hog GPU capacity meant for others. Reject any projected secret volume that isn't using workload identity federation, closing off the path where agents inherit static, long-lived credentials. Flag MCP server configuration files that declare outbound endpoint bindings with no allowlist attached; this is a newer surface, adjacent to infrastructure code, that tools in the Mend AI Scanner category have started paying attention to, and it's worth a Checkov rule even before it becomes standard in anyone's default policy set.
The centralized-policy pattern from the previous section applies here too. AI-specific custom policies belong in one security-team-owned repository, spreading automatically to every pipeline producing or consuming agent infrastructure, rather than getting copy-pasted and slowly drifting apart across five different teams' forks.
How Checkov integrates with the broader scanning ecosystem around AI pipelines
Checkov's coverage ends in specific places, and assuming it covers more than it does is its own kind of risk.
Runtime behavior sits outside its scope entirely. A perfectly configured sandbox manifest can still end up hosting an agent that misbehaves once it's running; that's a different layer of the problem, handled by seccomp profiles, eBPF-based monitoring, and admission controllers rather than anything a static scan catches before deployment.
Secret detection inside application code is another gap. Tools built for that job, Gitleaks and Trufflehog among them, specialize in scanning source files for credentials that shouldn't be there. Checkov catches secrets sitting inside infrastructure configuration, not secrets an agent might type directly into the application code it's writing.
Container image vulnerabilities are the third gap, and Trivy is the natural tool to fill it, scanning images for known CVEs. Trivy also scans infrastructure code in its own right, making it Checkov's closest open-source neighbor rather than a straight competitor. The sensible setup runs both, since one catches misconfigured infrastructure definitions and the other catches vulnerable software sitting inside the containers that infrastructure stands up.
So where does that leave Checkov? Positioned as an essential pre-execution gate for the infrastructure code AI agents write and the infrastructure code that hosts them, standing next to a small set of other tools that each cover a piece of the picture Checkov was never meant to cover alone.
