Notifications
Clear all
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.
NHIMG editorial — based on content published by ARMO: AI Workload Baseline and Drift Detection: Defining “Normal” Agent Behavior
Questions worth separating out
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 AI agents complicate drift detection more than traditional workloads?
A: AI agents change runtime behaviour through prompts, context, model updates, and tool availability, so their normal state is not fixed.
Q: How can security teams tell whether behavioural drift is actually dangerous?
A: Use three tests together: deployment correlation, pattern continuity, and resource bounds.
Practitioner guidance
- Define baselines at the Deployment and ServiceAccount level Use runtime identity that survives pod churn as the unit of behavioural history.
- Separate drift into response-specific categories Create distinct handling paths for tool misuse, credential drift, data access drift, and resource anomalies.
- Require deployment correlation before reclassifying drift as normal Treat any behavioural change without a matching deployment, prompt, or integration event as suspicious until proven otherwise.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- Deployment-level behavioural profile examples for Kubernetes workloads with rolling updates and autoscaling.
- Runtime signal taxonomy examples showing how tool, identity, data, and resource drift are separated in practice.
- Correlation workflow details for distinguishing expected model updates from suspicious behavioural change.
- Implementation detail on how observe-to-enforce moves from detection into policy enforcement.
👉 Read ARMO's analysis of AI workload baseline drift detection for agentic Kubernetes security →
AI workload drift detection: are your Kubernetes controls keeping up?
Explore further
20/08/2026 6:40 pm
Static baselines are the wrong mental model for AI agent governance: AI agents change because prompts, context, tools, and model versions change, so a snapshot of normal behaviour decays almost immediately. That makes drift detection a lifecycle problem, not a one-time tuning exercise. Practitioners should treat baseline governance as continuous identity observation, not a fixed detection rule.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
A question worth separating out:
Q: How should teams respond when drift points to new credential use or data access?
A: Treat identity drift and data access drift as access events, not just telemetry issues. Investigate whether the new role assumption, token use, or bulk read pattern matches a change record, then decide whether to contain, re-baseline, or revoke authority. That is where workload observability becomes IAM and PAM decision-making.
👉 Read our full editorial: AI workload baseline drift detection for agentic Kubernetes security
