Topic starter
20/08/2026 6:04 pm
TL;DR: AI agents change behavior with prompts, context, and tool availability, so static workload baselines miss the difference between expected evolution and risky drift, according to ARMO. Security teams need deployment correlation, pattern continuity, and resource bounds to separate benign change from credential misuse, data exfiltration, or tool/API abuse.
Editorial analysis by NHI Mgmt Group, based on content published by ARMO: “AI Workload Baseline and Drift Detection: Defining “Normal” Agent Behavior”.
Key questions
Q: What breaks when AI agent baselines are defined per pod instead of per deployment?
A: Per-pod baselines usually fail because Kubernetes pods are too short-lived for behavioural learning to stabilise.
Q: Why do deployment updates not always mean an AI agent is compromised?
A: Because many behavioural changes are expected when a model, prompt, toolchain, or integration changes.
Q: How do teams know if AI agent drift is actually a security problem?
A: Look for changes that do not correlate with model updates, prompt changes, or approved tool expansions, then compare them with resource bounds and cross-layer traces.
Practitioner guidance
- Anchor baselines to stable workload identities Track behaviour at the Deployment and ServiceAccount level so pod churn does not reset the observation window or create a permanent learning gap.
- Correlate drift with recorded change events Require a matching deployment, model update, prompt revision, or integration change before accepting behavioural drift as expected evolution.
- Prioritise identity and data access anomalies Escalate new role assumptions, unusual token requests, bulk reads, and unexpected data destinations ahead of lower-value model-only deviations.
Bottom line: Static AI workload baselines do not cope well with agents that evolve through prompts, context, model changes, and tool availability.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:40 pm
Deployment-level continuity is now the only baseline model that matches AI workload reality. Per-pod observation fails because the identity being monitored disappears before the baseline can stabilise. The important shift is not just operational convenience, but a change in what the control is built to observe. Practitioners should treat the Deployment and ServiceAccount as the durable security subject, not the ephemeral container.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should security teams respond when tool use and data access drift happen together?
A: Treat the combination as a higher-priority incident path, because tool misuse plus new data access often means the agent has crossed from benign variation into active abuse. Separate routine model drift from access-boundary drift, and use the latter to drive containment, identity review, and deeper investigation.
👉 Read our full editorial: AI workload baseline drift detection for agentic Kubernetes security