They break because the baseline never stabilises. Pods are short-lived, deployments change quickly, and agent behaviour varies by prompt and tool chain, so the detector stays in learning mode while attacks happen. The control failure is not bad calibration. It is that the environment does not provide the stable identity and time window baselines need.
Why This Matters for Security Teams
Behavioural baselines sound attractive because they promise anomaly detection without hand-curated rules, but AI agents in Kubernetes do not produce the kind of stable signal those models expect. Autoscaling, rolling updates, ephemeral containers, and prompt-driven tool use all change the “normal” pattern faster than many detectors can learn it. That means the system can be noisy when it should be decisive, and permissive when it should be suspicious. Guidance from the NIST AI Risk Management Framework is useful here because it pushes teams to treat model behaviour as a governed risk, not just a telemetry problem.
The real issue is identity and context. An AI agent may look like the same workload one minute and a materially different execution path the next, depending on prompt, retrieval source, tool permissions, and downstream automation. In that environment, a baseline can easily become a lagging average rather than a meaningful control. Teams often assume a detector “not firing” means the agent is safe, when in reality the detector may simply be unable to converge on a stable reference state. In practice, many security teams encounter the weakness only after an agent has already used legitimate tools to perform unintended actions, rather than through intentional detection design.
How It Works in Practice
In Kubernetes, behavioural baselines typically ingest signals such as pod start frequency, API call volume, network destinations, command execution patterns, and service-to-service relationships. For conventional workloads, those features can be stable enough to support thresholding or anomaly scoring. For agentic ai workloads, the signal shifts because the agent is not a fixed application path. It can vary by prompt, retrieval results, policy gates, tool availability, and whether a chain-of-thought style workflow is externalised into multiple calls. That makes the baseline reflect orchestration dynamics as much as security posture.
A more reliable approach is to combine behavioural monitoring with control-plane and identity controls. Security teams usually need:
- Workload identity bound to short-lived credentials rather than pod names or IP addresses.
- Tool and API allowlisting for agents, with explicit scoping for each execution path.
- Audit logs that correlate prompt input, tool invocation, and downstream side effects.
- Policy checks at admission, runtime, and egress so a moving baseline is not the only safeguard.
This is consistent with the attack patterns captured in the MITRE ATLAS adversarial AI threat matrix and the control emphasis in the OWASP Agentic AI Top 10. It also aligns with the threat modelling perspective in the CSA MAESTRO agentic AI threat modeling framework. The practical takeaway is that baselines should be treated as one input to detection, not the primary trust mechanism. These controls tend to break down when agents are redeployed frequently across clusters because the environment changes faster than the detector can rebuild a meaningful normal.
Common Variations and Edge Cases
Tighter monitoring often increases operational overhead, requiring organisations to balance detection sensitivity against deployment speed and noise tolerance. That tradeoff becomes sharper in multi-tenant clusters, bursty batch environments, and development namespaces where agents are constantly recreated. In those cases, a single “normal” profile is usually too blunt to distinguish expected churn from malicious activity.
There is no universal standard for this yet, but current guidance suggests moving from pure behavioural baselines toward context-aware controls. For example, a production agent with tightly bounded tools can be monitored against a narrower set of expected actions than a research sandbox agent that is allowed to experiment. Similarly, a baseline may still be useful for capacity or reliability monitoring even when it is weak as a security control.
Teams should also be careful not to confuse platform noise with adversarial behaviour. A spike in Kubernetes API activity may reflect scaling, but it may also reflect prompt injection, tool abuse, or lateral movement through a mis-scoped service account. Where agentic systems can reach sensitive data or act on behalf of users, the security model should assume identity, privilege, and workload behaviour are all coupled. That is why the question sits at the intersection of AI governance and Kubernetes security, not just observability.
For practitioners building policy around this issue, the most useful rule is simple: if the workload’s identity, prompt inputs, and tool graph change too quickly to stabilise, the baseline cannot be the control of record. It can inform investigations, but it should not carry the burden of prevention.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATLAS and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF fits when behaviour-based detection becomes a governed AI risk. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance addresses tool abuse and prompt-driven behaviour shifts. | |
| MITRE ATLAS | T1595 | ATLAS covers adversarial AI threat patterns that evade weak baselines. |
| NIST CSF 2.0 | DE.CM | Continuous monitoring is the CSF function most affected when baselines never stabilise. |
| CSA MAESTRO | MAESTRO helps model agent workflows, tools, and control points in Kubernetes. |
Pair continuous monitoring with identity and admission controls instead of trusting one anomaly model.
Related resources from NHI Mgmt Group
- What breaks when observability is used instead of access control for AI agents?
- What breaks when access review does not cover non-human identities used by AI agents?
- What breaks when human MFA is used for bots and AI agents?
- What breaks when certificates are used without lifecycle governance for AI agents?
