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.
Editorial analysis by NHI Mgmt Group, based on content published by ARMO: “AI Workload Discovery: How to Find Every AI Agent Running in Your Clusters”.
Key questions
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 declaration-based inventories miss shadow AI in Kubernetes?
A: Because declarations record intent, while AI workload identity is assembled at runtime from prompts, tools, SDKs, and external model calls.
Q: What signs show that an AI workload discovery programme is too weak?
A: If the inventory contains only tagged workloads, if GPU usage is treated as the main detection signal, or if the team cannot explain which workloads are calling LLM endpoints, discovery is incomplete.
Practitioner guidance
- Implement runtime-based AI workload discovery Use process, library, and network telemetry to identify AI workloads that never appear in tags or CMDB records.
- Correlate declared and observed signals Compare Kubernetes labels, image metadata, GPU requests, outbound LLM calls, and loaded agent frameworks to expose shadow AI.
- Map discovered workloads to service accounts Record the Kubernetes identity, RBAC bindings, and namespace for each discovered AI workload before applying access policy.
Bottom line: AI workload discovery in Kubernetes fails when teams rely on metadata that cannot express agent behavior, framework use, or outbound model access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:34 pm
Runtime observation is now the control boundary for AI workload governance. In Kubernetes, the inventory problem is no longer about counting containers but about determining which containers are acting as AI systems. The declaration-observation gap means that a manifest-driven inventory can look complete while missing the workloads that matter most. For IAM and NHI teams, the practical conclusion is that agent identity starts at observation time, not approval time.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams do after they identify an AI agent in a cluster?
A: They should classify it by role, map it to a service account, and review the privilege attached to that identity before applying policy. An inference server, an orchestrator, and a tool runtime do not need the same access, so governance has to follow the discovered function rather than the container alone.
👉 Read our full editorial: AI workload discovery in Kubernetes depends on runtime observation