Artificial intelligence is becoming part of daily software delivery, often before it becomes part of the security architecture. That gap has a name: Shadow AI. It is any AI tool, model, agent, extension, or integration used in the software lifecycle without formal approval, ownership, risk assessment, or monitoring.
For platform and security teams, Shadow AI is not really a “developers using a chatbot” problem. It is an access problem. Ungoverned AI can reach source code, secrets, customer data, cloud environments, and deployment workflows. And once an AI system is allowed to call tools and take actions, it stops being productivity software and becomes a new non-human identity with permissions, a blast radius, and a place in your threat model.
This article threat-models a common cloud-native delivery path, from a developer laptop to a workload running in a Kubernetes pod, and maps each stage to controls you can implement today with CNCF and open source projects.
From advisory to action
The risk rises sharply when AI stops giving advice and starts taking action.
An assistant that suggests a code snippet creates one class of risk: data leaving an approved boundary, or a subtly wrong suggestion trusted without review. An agent with a Git token, cloud credentials, or a Kubernetes ServiceAccount creates a different class entirely. It can create, alter, or delete resources at machine speed, and Kubernetes will not distinguish between a harmful action taken by an attacker and the same action taken by an over-privileged automation identity.
So the questions worth answering are operational, not philosophical:
- Which AI tools and agents are in use?
- What data do they receive?
- Which systems can they reach, and with what permissions?
- Who owns each agent’s behavior?
- Can access be revoked immediately if an agent misbehaves?
A workable model gives every agent a human owner, registers it as an identifiable workload, constrains it with least privilege, and monitors what it actually does.
The delivery path
Consider a typical cloud-native delivery path:
Delivery path from developer laptop to Kubernetes pod, showing Shadow AI injection points at each stage and the defensive control that clamps each one
Shadow AI can appear at every stage, and a small convenience decision at the start of the path can become a production exposure at the end.
| Delivery stage | Typical Shadow AI use | Primary risk |
| Developer laptop | Unapproved code assistant, local model plugin, public chatbot | Source code, secrets, or architecture leave approved boundaries |
| Source control | AI bot reviews PRs, generates commits, summarizes repositories | Excessive repo permissions, unsafe code changes, no clear ownership |
| CI pipeline | AI generates pipeline logic, analyzes logs, “fixes” failing builds | Build secrets and cloud credentials exposed; automated supply-chain changes |
| Artifact registry | AI-assisted image or dependency selection | Vulnerable, malicious, or untraceable dependencies reach production |
| CD platform | AI agent approves, modifies, or rolls out releases | Bypassed change controls, unauthorized deployment, poor traceability |
| Kubernetes runtime | Agent queries clusters, remediates alerts, scales workloads | Over-privileged ServiceAccounts, destructive actions, lateral movement |
Threat model
A threat model does not require you to predict every attack. It requires you to name the valuable assets, the likely abuse paths, and the controls that limit impact.
Assets to protect
- Source code and proprietary algorithms
- API keys, tokens, certificates, and other secrets
- Customer, employee, and commercial data
- CI/CD configuration and software-signing keys
- Cloud and Kubernetes identities
- Container images and software supply-chain integrity
- Production availability and reputation
Threat actors
Shadow AI rarely starts with a malicious insider. More often a well-intentioned engineer adopts a tool to move faster, and attackers exploit the resulting blind spot. Relevant actors include:
- External attackers targeting exposed AI integrations or stolen credentials
- Malicious insiders abusing poorly governed access
- Compromised third-party or AI-tool providers
- Attackers using prompt injection to manipulate an agent
- A legitimate agent acting incorrectly because of ambiguous instructions, unsafe context, or excessive permissions
Prompt injection is the through-line. Agents routinely read untrusted content: issue descriptions, READMEs, dependency changelogs, build logs. Any of it can steer an agent into disclosing data or taking an unsafe action, which is why prompt filtering alone will never be enough and defense-in-depth is the real answer. The OWASP guidance on AI agents and LLM applications is a good baseline for these failure modes.
Attack paths by stage, and the controls that clamp them
1. Developer laptop
A developer installs an AI coding extension or pastes an error log into a public service. That log contains an API token, an internal hostname, or a customer identifier. The organization has now lost visibility over where proprietary data went and how it may be retained. A second risk follows: the assistant suggests a dependency or command that the developer trusts without validation.
Defensive control. Provide approved AI tools so usage is visible instead of hidden; a blanket ban tends to push it further into the shadows. Back this with pre-commit secret scanning, wired in as a git hook with something like gitleaks, so tokens never reach a shared surface in the first place, and enforce signed commits. Gitsign (part of the Sigstore project) lets developers sign commits with short-lived, identity-based certificates instead of long-lived GPG keys, which makes “who produced this change” auditable, including when the author is an agent.
Where an agent genuinely needs to run commands autonomously, isolate it rather than trusting it. The mechanism worth understanding is a disposable, VM-isolated workspace: the agent gets its own kernel and filesystem, and the host’s SSH keys, cloud credential files, and other repository checkouts are simply not present inside it. If the agent is manipulated into doing something destructive, you throw the environment away and the damage stops there.
Plenty of implementations exist, open source and commercial, from developer-facing tools that reduce this to a single command down to the microVM and syscall-interception runtimes they are built on (the tooling table later in this article names the open source ones). The property matters more than the product: an agent operating with broad autonomy should not be running directly on the machine that holds your credentials.
2. Source control
An unapproved AI bot is connected to your Git host with broad permissions. It can read every repository, comment on pull requests, create branches, or push code. The threat is not only leakage: if the integration token is stolen, or the bot is manipulated through a malicious issue or PR description, it can introduce unsafe changes or disclose repository content.
Defensive control. Give every AI integration a named owner, its own identity, minimal repository scope, and short-lived credentials. An agent that reviews code for one team should not hold org-wide repository access. Require review gates and provenance on everything merged, and treat agent-authored PRs like any other untrusted contributor: mandatory human review, no self-approval.
3. CI pipeline
CI systems hold some of the most powerful credentials you own: source-control tokens, registry credentials, cloud keys, and signing keys. A Shadow AI capability that inspects build logs, generates scripts, or autonomously “fixes” a failing build becomes an ungoverned privileged operator. A prompt-injection payload hidden in source, a README, or a build log can change how it behaves.
Defensive control. Keep long-lived secrets out of prompts, logs, and build environments. Run AI-connected jobs in isolated environments with tightly scoped, ephemeral credentials, and require policy checks before any pipeline can alter infrastructure or release software. In Kubernetes-native CI, an admission policy is a hard gate that an agent cannot talk its way past: a Kyverno or OPA/Gatekeeper rule that rejects unsigned images, for instance, holds regardless of what a compromised pipeline job tries to push.
4. Artifact registry and supply chain
AI-generated code can pull in insecure packages, weak configurations, or dependencies nobody reviewed. An assistant may recommend a base image or copy a snippet without checking provenance, licensing, vulnerabilities, or maintenance status. If you cannot establish what went into an image, who approved it, and whether it passed a gate, fast delivery is just unmanaged risk.
Defensive control. Require image scanning, SBOM generation, signed artifacts, and promotion gates, and hold AI-generated code to the same review and release bar as human-written code. A practical open source chain looks like:
- Trivy or Grype to scan images and IaC for known vulnerabilities.
- Syft to generate an SBOM per artifact.
- Cosign (Sigstore) to sign images and attach attestations.
- in-toto to capture signed attestations for each pipeline step, the foundation of SLSA-style provenance.
- Notation (Notary Project) to verify signatures at the registry boundary, so a consumer can check an artifact independently of the pipeline that produced it.
5. Continuous delivery
An AI release agent may be able to edit Helm charts, update GitOps manifests, change deployment targets, approve releases, or trigger rollbacks. Connected to production without boundaries, it can bypass exactly the change-management controls a mature process depends on.
Defensive control. Draw a hard line between an agent that recommends a release action and one that executes it. High-impact actions should sit behind explicit approval gates with strong audit trails: production deployment, privilege escalation, data export, deletion, network-policy changes. In a GitOps model, the pull request is the approval gate: the agent proposes a manifest change, a human approves the merge, and the GitOps controller (Argo CD or Flux) reconciles. Neither controller takes instructions from the agent; it only ever applies what is already merged. Enforce that no path to production exists that skips the gate.
6. Kubernetes runtime
This stage is often the most consequential. A remediation agent gets cluster-admin “temporarily” to investigate an alert, and a convenience tool becomes a high-value target. A compromised or manipulated agent with broad permissions can enumerate secrets, deploy a malicious workload, alter network policies, or exfiltrate data.
Defensive control. Namespace boundaries, workload identity, minimal RBAC, admission control, runtime detection, and network segmentation. Concretely:
- SPIFFE/SPIRE to give each workload (including agents) a cryptographic identity instead of a shared, long-lived token.
- Least-privilege RBAC scoped to a namespace and a verb set, never cluster-admin.
- Falco or Tetragon (an eBPF component of Cilium) for runtime detection of the behavior that follows a compromise: a shell in a container, unexpected secret reads, outbound connections.
- Network policies to segment east-west traffic and contain lateral movement.
For example, an agent whose only job is to restart a Deployment needs a namespaced Role, not a cluster-wide one: bound to a single namespace, limited to the apps API group and the deployments resource, and granting only get, list, and patch (a rollout restart is a patch, so create and delete are never needed). That is a world away from cluster-admin: even if the agent is fully under someone else’s control, it cannot read secrets, touch other namespaces, or delete workloads.
Controls that scale
None of this is about slowing AI adoption. The point is to make AI use visible, accountable, and proportionate to its risk.
Build an AI inventory
Keep a living inventory of approved and discovered AI tools, models, extensions, code assistants, agents, API integrations, and MCP servers. Each entry needs a business and a technical owner, its purpose and users, the data classification it is allowed to touch, the systems it connects to and with what permissions, the model or provider behind it, whether it is in production, when it was last reviewed, and how to revoke its access. You cannot govern what you cannot see, and every other control on this list assumes this one exists.
Treat AI agents as identities
Every agent should have a unique identity. It should never borrow a developer’s personal credentials or a shared admin account. Least privilege by default means:
- Separate credentials per environment
- Short-lived tokens, not persistent secrets
- Read-only access where possible
- Namespace-scoped Kubernetes permissions
- Explicit allowlists for APIs, tools, repositories, and MCP servers
- Immediate revocation
In-cluster, SPIFFE/SPIRE and cert-manager already do this job. Outside the cluster, where the agent is talking to a Git host, a registry, or a ticketing system rather than to the Kubernetes API, Keycloak is the usual anchor for those service identities.
Match the control to the blast radius
Not every AI function needs the same treatment:
| AI capability | Recommended control level |
| Code explanation or documentation drafting | Approved tool, data-classification rules, developer training |
| Code suggestion | Human review, standard testing, secret scanning, dependency checks |
| Pull-request creation | Restricted repo permissions, mandatory peer review |
| CI/CD pipeline modification | Isolated execution, policy-as-code checks, approval gate |
| Cluster remediation | Strict namespace RBAC, limited scope, full audit trail, human approval for high-impact actions |
| Autonomous production changes | Exceptional approval only, time-bound access, kill switch, continuous monitoring |
Apply defense in depth
If prompt filtering is only one layer, the others have to carry real weight. A mature architecture combines governance, identity and access management, source-control protections, secrets management, secure CI/CD, dependency and container scanning, Kubernetes admission and runtime policy, network controls, and centralized logging. The test is simple: if any single control fails, the agent must still be unable to cause material harm.
Tooling by area (CNCF and open source)
No single project solves Shadow AI. Pick tools by the risk area you need to improve, then integrate them into a coherent architecture. Maturity levels below reflect the CNCF Landscape at the time of writing.
| Area | CNCF projects | Other open source | What it addresses |
| Kubernetes policy & admission | Kyverno (graduated), Open Policy Agent / Gatekeeper (graduated), Kubescape (incubating), Kubewarden (sandbox) | Polaris, kube-bench | Enforce deployment policy, block unsigned or non-compliant workloads, reduce permissions |
| Runtime detection | Falco (graduated), Tetragon / Cilium (graduated), KubeArmor (sandbox), Inspektor Gadget (sandbox) | Tracee, osquery, Wazuh | Detect suspicious runtime behavior: shells, secret reads, unexpected egress |
| Network segmentation | Cilium (graduated), Istio (graduated), Linkerd (graduated), Antrea (sandbox) | Calico Open Source | Segment east-west traffic, restrict egress to model and tool endpoints, contain lateral movement |
| Workload & agent identity | SPIFFE/SPIRE (graduated), cert-manager (graduated), Keycloak (incubating) | Teleport (machine & workload identity), Zitadel, authentik, Ory Hydra/Kratos | Give agents a scoped, short-lived identity; enable least privilege and revocation |
| Supply chain: signing, SBOM, provenance | in-toto (incubating), The Update Framework (graduated), Notary/Notation (incubating) | Sigstore/Cosign & Gitsign, Trivy, Syft, Grype, OSV-Scanner, OWASP Dependency-Track, OpenSSF Scorecard, GUAC | Scan code and images, generate SBOMs, sign artifacts and commits, prove provenance, query it across the estate |
| Secrets management | OpenBao (sandbox), SOPS (sandbox), External Secrets Operator (sandbox), Secrets Store CSI Driver (Kubernetes SIG-Auth) | Sealed Secrets, gitleaks, TruffleHog, Infisical | Central secrets engine, dynamic/short-lived credentials, keep tokens out of repos, prompts, logs, and images |
| Agent runtime isolation | Confidential Containers (incubating) | Kata Containers (OpenInfra Foundation), Firecracker, gVisor, Sysbox, ToolHive | Give an autonomous agent a disposable environment instead of access to the host, its keys, and its checkouts |
| Agent governance: discovery, tool-call policy | kagent (sandbox), Envoy AI Gateway (extension of Envoy Gateway; Envoy graduated), Backstage (incubating), OpenTelemetry (graduated) | agentgateway, agentregistry, ToolHive, ContextForge MCP Gateway | Register and discover agents and MCP servers, authenticate and authorize tool calls, trace what an agent actually invoked |
Two caveats on the right-hand column. First, open source is not the same as foundation-governed. Several of those entries are single-vendor projects with an open source core and a paid edition: Calico by Tigera, Tracee by Aqua, TruffleHog by Truffle Security, ToolHive by Stacklok, Teleport by Gravitational. They are legitimate choices, but check that the capability you are actually relying on is in the free edition.
Second, read the license before you embed or redistribute. gitleaks is MIT; Tracee, Polaris, Calico, and ToolHive are Apache-2.0. TruffleHog, Zitadel, and Teleport’s community edition are AGPL-3.0, which carries source-disclosure obligations if you offer a modified version as a network service.
The gaps deserve the same bluntness. The pipeline and runtime layers are well served by mature CNCF projects. AI governance itself is thinner: prompt inspection, agent discovery, tool-call policy. No project at graduated maturity owns that space end to end, and the ones aimed squarely at it are young, though the gateway layer improved noticeably during 2026.
Four projects are worth knowing before you write your own proxy:
- kagent (CNCF Sandbox, accepted May 2025) is a framework for building and running agents in Kubernetes, which at least puts agent workloads under the same declarative model as everything else in the cluster.
- Envoy AI Gateway (Apache-2.0) reached v1.0 in June 2026, with contributions from Bloomberg, Nutanix, Tetrate, and the Envoy community. It uses a two-tier pattern: an outer gateway for authentication and global rate limiting, an inner one for fine-grained control over self-hosted model endpoints, plus routing for MCP traffic. It is the option with the strongest cloud-native lineage, since it extends Envoy Gateway rather than starting from scratch.
- agentgateway (Linux Foundation) is a policy proxy for MCP and Agent2Agent traffic. It terminates agent-to-tool and agent-to-model calls and applies JWT, API-key, or OAuth authentication, role-based authorization through a CEL policy engine, content filtering, rate limiting, and OpenTelemetry tracing. Architecturally it is the chokepoint the allowlisting and least-privilege advice above assumes you have.
- agentregistry targets the inventory problem directly, cataloging MCP servers, agents, and skills and scanning connected runtimes to surface what was never registered. It was submitted to the CNCF Sandbox in March 2026, but the application is still under review, so evaluate it as an early-stage project rather than a CNCF-governed one.
The inventory may not need a new tool at all. Backstage already models ownership, and its catalog can hold agents and MCP servers as first-class components with a named owner. OpenTelemetry’s GenAI semantic conventions then give you a standard shape for the traces that record which tool an agent actually called.
One layer still has no foundation-governed answer: scanning MCP servers for tool poisoning and prompt-injection payloads. Tooling exists, but the maintained options are vendor-developed, so treat that as an evaluation exercise rather than a settled choice. Until it matures, the pragmatic position is unchanged. Pair OWASP guidance with a policy enforcement point in front of model and tool endpoints, then lean on the identity and admission controls above to constrain what an agent can do, even when you cannot fully inspect what it is thinking.
Whichever way you assemble it, every one of these projects still needs an owner. Someone has to maintain the policies, triage the findings, keep the integrations working, and prove the controls do what the architecture diagram claims they do.
Conclusion
Shadow AI is the next evolution of Shadow IT, with a critical difference: modern AI agents can interpret information, call tools, and act across engineering systems. That makes them powerful accelerators and potential high-speed paths to source-code leakage, credential compromise, supply-chain abuse, and production disruption.
The decision is not whether your developers will use AI. They already are. The decision is whether you manage AI as an untracked pile of productivity tools or as a governed set of identities, data flows, and production-capable workloads.
The path forward is concrete, and most of it is already covered by cloud-native open source: discover AI use, assign ownership, scope permissions with real workload identity, protect the supply chain with signing and provenance, enforce Kubernetes boundaries with admission and runtime policy, segment the network, monitor behavior, and keep a human in the loop for consequential actions. Let agents help teams move faster, but never let them operate beyond your ability to see, control, and stop them.