Give an AI agent a Git token and a Kubernetes ServiceAccount. Now ask which team owns it, and where its logs go. If you cannot answer both in one breath, congratulations: you have shadow AI in your pipeline. This week Matteo Bisi of ReeVo has a CNCF community post out that names the problem, threat-models it end to end, and cross-references the open-source controls you already have but are probably not using yet.
The identity you forgot to inventory
Bisi's working definition is uncomfortably broad on purpose: shadow AI is any AI tool, model, agent, extension, or integration used in the software lifecycle without formal approval, ownership, risk assessment, or monitoring. The assistant writing your commit messages is one thing. The agent holding a token that can push to main, or a ServiceAccount that can restart a workload, is a different beast. Kubernetes will not distinguish a malicious call from a well-meaning agent with too much RBAC. The blast radius is the same either way.
The verdict Bisi lands early is the one that costs you meetings: treat AI as an identity class. Named business and technical owners on file. Purpose and data classification recorded. Environment-scoped credentials that are short-lived, read-only by default, with an explicit allowlist for anything more. A revocation button someone can actually press at 2 a.m.
Reasonable. Also, if we are being honest, mostly aspirational at your shop.
Six stages, one attack surface
The post walks the delivery path in six stages and gives each its own failure mode. On the developer laptop: unapproved assistants and local models leaking source and secrets. In source control: AI-authored pull requests with more repo scope than the human author has. In CI: prompts and logs quietly ingesting build secrets and cloud credentials. In the artifact registry: an AI helpfully picking a dependency with a fresh vulnerability. In continuous delivery: recommender roles fused with executor roles, so a suggestion becomes a release. In the cluster: agent remediation loops that scale, patch, or delete on behalf of a compromised prompt.
Prompt injection is the through-line. Every stage inherits it. If your only defence is a filter on the model's inputs, everything downstream is doing security theatre.
The controls that already exist
The strong move in Bisi's write-up is that he does not stop at the diagnosis. Each stage gets a set of concrete, mostly CNCF-adjacent controls you can wire up this quarter.
On the laptop: pre-commit secret scanning with gitleaks, commit signing via Gitsign and the wider Sigstore stack, and disposable, VM-isolated workspaces for the agents you do let touch code.
In the supply chain: image scanning with Trivy or Grype, SBOMs from Syft, and artifact signatures via Cosign, in-toto, or Notation. Nothing you have not read about before. The point is that AI-authored artifacts are still artifacts, and the same attestations apply.
In delivery: keep the recommender separate from the executor, and put a GitOps controller (Argo CD, Flux) between the two so merge approval remains the last human choke point before anything hits production.
In the cluster: SPIFFE/SPIRE for workload identity, namespace-scoped RBAC that follows the same model as above (short-lived, allowlisted, revocable), and runtime detection with Falco or Tetragon on Cilium to catch the behaviour when the identity story fails. Add network segmentation via Cilium, Istio, or Linkerd so a compromised agent cannot casually pivot.
There is a lot to like here. Bisi is not selling anything. He is pointing at parts of the stack you already run and asking why the agent piggybacking on them is not held to the same standards as every other production identity.
Where the toolbox still has a hole
Bisi flags the gap plainly, and it is the honest read: no CNCF graduated project today owns end-to-end AI governance. Prompt inspection and tool-call policy remain immature. Emerging pieces (kagent, Envoy AI Gateway, Backstage, OpenTelemetry) each cover a slice, but nothing yet stitches the identity, the prompt, the tool call, and the runtime effect into one auditable trace.
That is a healthier account of the state of the art than most vendor whitepapers on the same topic. If you were hoping for one control plane you can turn on, keep waiting. If you were hoping to composite one from parts you already run, the parts exist. Someone on your team just has to own the assembly.
Ban the AI and it moves to a personal laptop with your source tree on it. Approve it and forget to scope it, and it moves to production on your behalf. Pick one.
Top comments (0)