Notifications
Clear all
Topic starter
20/08/2026 5:54 pm
TL;DR: AI workload discovery in Kubernetes cannot rely on tags, CMDBs, or cloud asset inventory because AI agents are only visible through runtime evidence such as loaded SDKs, process behavior, and outbound LLM calls, according to ARMO. The practical implication is that discovery must shift from declaration-based inventories to observation-based controls before teams can govern agent identity or least privilege.
NHIMG editorial — based on content published by ARMO: AI Workload Discovery: How to Find Every AI Agent Running in Your Clusters
By the numbers:
- Only 38% have automated certificate lifecycle management in place.
- 57% of organisations lack a complete inventory of their machine identities.
Questions worth separating out
Q: How should security teams find AI workloads that were never tagged in Kubernetes?
A: They should rely on runtime observation, not tags alone.
Q: Why do AI agents on GKE complicate workload identity governance?
A: Because the agent’s cloud permissions, Kubernetes identity, and runtime behaviour all interact with cluster architecture.
Q: What breaks when discovery only uses cloud asset inventory for AI agents?
A: Cloud asset inventory sees managed services and declared resources, but it misses containers that behave like agents without advertising themselves.
Practitioner guidance
- Implement runtime-first discovery Use process, network, and cluster telemetry to identify AI workloads from what they actually load and call, not from tags or CMDB entries alone.
- Map every discovered agent to a workload identity Record the service account, namespace, and tool endpoints for each discovered agent so IAM and NHI controls can be applied to the real runtime identity.
- Classify workloads by observable role Separate inference servers, agent orchestrators, tool runtimes, and RAG components so policy reflects the different access patterns each class creates.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of the four signal classes used to identify AI workloads in Kubernetes clusters.
- A practical completeness test that teams can use to measure how much of their AI workload estate is still invisible.
- Examples of how runtime signals separate inference servers, agent orchestrators, and tool runtimes.
- Operational guidance for on-demand workloads that only surface through network telemetry.
👉 Read ARMO's analysis of how to find every AI agent running in Kubernetes →
AI workload discovery in Kubernetes: are your controls keeping up?
Explore further
20/08/2026 6:34 pm
Runtime observation is now a governance requirement for AI workload security. Declarative inventories are still useful, but they are structurally insufficient for agent discovery because they only reflect what teams say they deployed. AI workload identity emerges at runtime through loaded frameworks, process behavior, and external calls, which means governance has to start with observation. For teams already using NHI and workload identity controls, the lesson is direct: if you cannot enumerate the workload, you cannot govern its service account or privileges.
A question worth separating out:
Q: What should teams do when runtime discovery reveals unknown AI workloads?
A: They should pause expansion of those workloads, classify their runtime role, and map the service account or token each one uses before granting broader access. The immediate goal is containment through visibility and identity mapping, because an undiscovered agent cannot be safely authorised until its actual behavior is understood.
👉 Read our full editorial: AI workload discovery in Kubernetes depends on runtime observation
