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.
