TL;DR: Static workload baselines struggle to separate expected AI agent evolution from risky drift, according to ARMO. Runtime baselines tied to stable workload identity give security teams a practical way to spot when changes move into access or data 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: 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.
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.
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.
Glossary terms: Behavior Baseline, Drift Correlation, Runtime-Informed Posture, Workload Identity
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
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