Shadow AI in CI/CD: The Six-Stage Threat Model from Laptop to Kubernetes

Shadow AI in CI/CD: The Six-Stage Threat Model from Laptop to Kubernetes

Cloud Platform Engineering

Every enterprise already has shadow AI in its software pipeline. The CNCF just published a six-stage map of where to find it — and what’s at risk at each stage.

The Framework

The CNCF defines shadow AI as “any AI tool, model, agent, extension, or integration used in the software lifecycle without formal approval, ownership, risk assessment, or monitoring.” That definition is broader than most governance programs account for, covering VS Code extensions, browser plugins, local models, and CI-integrated bots alongside the obvious enterprise tools.

The critical escalation is execution capability. AI systems that only suggest code are a governance headache. AI agents that can push commits, trigger builds, or call Kubernetes APIs are non-human identities with access permissions — and most enterprises have not modeled them as such. The six-stage threat model traces this access expansion from developer laptop through to production runtime, pairing each stage with the specific blast radius and a concrete control set.

Developer Laptop

Unapproved coding assistants are the most widespread entry point. Without output logging, there is no visibility into what context — source code, environment variables, API call patterns — leaves the machine. The CNCF recommends secret scanning (gitleaks), signed commits (gitsign), and isolated execution environments for any tool that needs network access.

Source Control

AI bots with excessive repository permissions can read code across branches, write to protected paths, and surface sensitive content in pull request summaries. The attack surface scales with the bot’s permission scope. Controls: named ownership per integration, minimal-scope tokens scoped to the specific repo and action, short-lived credentials, and mandatory human review on any AI-authored merge to protected branches.

CI Pipeline

This is the stage where shadow AI transitions from a compliance problem to a material security incident. CI systems hold the most privileged credentials in a typical organization — cloud provider keys, artifact registry tokens, deployment service accounts. A compromised AI job in this environment can modify infrastructure-as-code, alter release artifacts before signing, or exfiltrate secrets during a build. The CNCF singles out CI as the highest-leverage attack point in the chain. Controls: isolated build environments per job, ephemeral credentials with per-job scope, and admission policies (Kyverno/OPA) that reject unapproved base images before the build starts.

Artifact Registry

AI-assisted dependency selection introduces a gap between what the model recommends and what is actually safe at the moment of installation. Models have training cutoffs; registries do not. The npm provenance worm attack in August 2026 demonstrated that even packages carrying valid provenance attestations can be malicious when an attacker has repository write access — the signature is technically valid, but the code is not. Controls: image scanning (Trivy/Grype), SBOMs generated at build time (Syft), artifact signing (Cosign), provenance chains (in-toto).

Continuous Delivery

Release agents can bypass approval gates — that is frequently their purpose. An AI agent with CD permissions can execute deployments in response to a prompt or automated trigger without the human review step that exists in GitOps workflows for exactly this reason. The CNCF’s control recommendation is explicit: GitOps controllers should apply only merged PRs, never direct agent commands, and hard approval gates must be enforced at the CD layer, not just the pipeline layer.

Kubernetes Runtime

The terminal stage is where shadow AI risk converges with classical identity risk. Over-privileged ServiceAccounts — the default in many cluster configurations — allow an agent to enumerate secrets, deploy workloads to sensitive namespaces, or move laterally across the cluster. The same principles that govern human service accounts now apply to non-human AI identities: SPIFFE/SPIRE workload identity for cryptographic attestation, namespace-scoped RBAC, runtime detection (Falco/Tetragon), and network policies between namespaces. The JFrog Agent Guard pattern addresses the artifact-layer piece, but Kubernetes runtime is a separate and often unaddressed surface.

The So What

The six-stage model is a checklist, not a strategy. The strategic shift it requires is recognizing that AI agents are now a principal class in your authorization model — alongside users, service accounts, and third-party integrations. Enterprises that have not run an AI inventory (cataloging every agent with business owner, data classification, connected systems, and revocation procedure) are operating blind to a permission surface that is growing every sprint. Start the inventory. Then close the gaps in order of blast radius: CI pipeline first, Kubernetes runtime second, artifact registry third.

Source: CNCF Blog

Content created with AI assistance and reviewed for accuracy.

💬

Join the conversation

Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.

Join Stack Insiders →

Newsletter coming soon.

Curated digests across AI, biohacking, photography, travel, and more. Be the first to know when we launch.