AI workload baseline drift detection for agentic Kubernetes security

At a glance

What this is: This is an analysis of how to baseline AI agent behaviour in Kubernetes and detect when drift signals compromise rather than normal evolution.

Why it matters: It matters because IAM, PAM, and workload security teams need runtime evidence for credential use, tool access, and data movement, not just static permissions.

👉 Read ARMO's analysis of AI workload baseline drift detection for agentic Kubernetes security

Context

AI workload baseline drift detection is the practice of defining normal runtime behaviour for an agent and then watching for changes that indicate compromise, not just expected model or prompt updates. In Kubernetes, that baseline has to follow the Deployment or ServiceAccount, because pod-level snapshots age out faster than the workload itself changes.

The identity governance problem is that agent behaviour is not fixed at build time. Tool calling, credential use, data access, and network destinations can all change as context shifts, which means security teams need runtime baselines that understand what was authorised, what was expected, and what has crossed into risk. ARMO frames that challenge through Deployment-level behavioural profiling and drift correlation.

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. The result is a permanent learning window, which means the security team is always profiling and rarely detecting. Behavioural history belongs to the Deployment or ServiceAccount, where identity and runtime patterns persist long enough to be useful.

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. That makes static baselines noisy unless teams correlate changes with approved events. The operational problem is not just detecting anomalies, but deciding whether the change is expected evolution or suspicious drift.

Q: How can security teams tell whether behavioural drift is actually dangerous?

A: Use three tests together: deployment correlation, pattern continuity, and resource bounds. If the change does not line up with a recorded event, breaks core runtime patterns, and exceeds the expected consumption envelope, treat it as high priority. One test alone is rarely enough to separate normal evolution from compromise.

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.

Technical breakdown

Why static per-pod baselines fail for AI agents

A per-pod baseline assumes the workload has enough time to learn a stable pattern before the pod disappears. That assumption breaks in Kubernetes because rolling deployments, autoscaling, and node churn can reset the observation window before a profile converges. AI agents make it worse because prompts, tool access, and model updates legitimately change behaviour even when the underlying workload is healthy. The right unit of analysis is the Deployment or ServiceAccount, not the transient pod, because identity and runtime behaviour persist longer than any one container instance.

Practical implication: anchor behavioural baselines to stable workload identity, not ephemeral pods.

How to classify drift across tools, identity, data, and resources

Drift is only useful when it is separated into categories with different security meaning. Tool and API misuse can indicate prompt injection or agent escape. Credential and identity drift can indicate lateral movement or privilege escalation. Data access drift points toward unauthorised reads, bulk collection, or exfiltration. Resource drift is weaker on its own, but it strengthens suspicion when it appears alongside changes in tool use or identity assumption. Without this taxonomy, teams get one noisy alert stream instead of separate response paths.

Practical implication: route each drift category to a different triage workflow and severity threshold.

Why deployment correlation is the control that makes drift actionable

Not every change is suspicious. Deployment correlation asks whether a behavioural change lines up with a recorded model update, prompt change, configuration change, or new integration. Pattern continuity checks whether the agent still follows the same core runtime habits across tool use, identity, and data access. Resource bounds verify whether the workload is still operating inside its expected envelope. Drift that fails all three tests is high priority because it lacks the normal explanation of an approved change.

Practical implication: require a change record before accepting behavioural drift as normal evolution.

Threat narrative

Attacker objective: The objective is to hide malicious agent behaviour inside the noise of legitimate model, prompt, or toolchain change.

1. Entry occurs when an AI agent receives a prompt or context change that causes it to invoke an unexpected tool or API.
2. Escalation follows when the agent assumes a new credential, accesses a broader data source, or shifts into a new runtime pattern without deployment correlation.
3. Impact appears as data access drift, credential misuse, or sustained resource and network behaviour consistent with exfiltration or agent escape.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Deployment correlation is the difference between expected evolution and compromise: A behavioural change that aligns with a recorded deployment, prompt revision, or integration update belongs in the normal-change bucket. A change with no change record is the one that matters, because it removes the most plausible explanation for new runtime behaviour. The implication is that AI workload governance needs a change record before it needs a detection score.

Identity drift is the highest-value signal because it bridges workload security and IAM: New role assumption, unexpected token use, and service account switching are not just technical anomalies, they are access events. That is where AI workload monitoring joins IAM and PAM, because the question becomes who or what is acting under which authority. Security teams should prioritise identity drift over generic performance drift.

Tool/API misuse drift defines a new runtime governance gap: Runtime tool authority: AI agents do not merely consume APIs, they can pivot between tools based on context. That makes the gap less about blocked endpoints and more about whether the agent's actual tool use matches its authorised tool envelope. Practitioners need to govern the envelope, not just the inventory.

Resource anomalies only matter when they reinforce behavioural evidence: Burst CPU, memory, or network use can be normal in AI systems. The meaningful signal is correlation, such as high egress alongside new data access or a fresh credential assumption. That means observability should support explanation, not just alert generation, if teams want to distinguish inference spikes from exfiltration.

From our research:

• 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.
• The operational next step is to pair behavioural baselines with identity governance so runtime access can be explained, reviewed, and challenged before it becomes incident response.

What this signals

Runtime identity has become the governance boundary for AI agents. When a workload can change tools, credentials, and data paths in response to prompts, the old separation between posture and behaviour breaks down. Security teams need a control model that can explain what the agent actually did, not just what it was allowed to do. See also the SPIFFE workload identity specification for workload identity concepts that become relevant when runtime access is the thing under scrutiny.

Identity drift will become a standard triage category. New token use, role assumption, and service account switching are no longer edge cases in AI-enabled environments. They are the evidence trail for whether an agent has stayed inside its intended authority or crossed into misuse. That pushes AI workload security closer to IAM, PAM, and lifecycle governance than many teams expect.

AI workload baseline drift detection is really a control-plane discipline. A team that cannot correlate behavioural change with an approved event will spend more time tuning alerts than reducing risk. The right question is not whether the model looked unusual, but whether the runtime behaviour still matches the authorised identity envelope and declared change record.

For practitioners

• Define baselines at the Deployment and ServiceAccount level Use runtime identity that survives pod churn as the unit of behavioural history. Tie each baseline to the workload identity that actually assumes credentials and calls tools, then let new pods inherit that profile immediately.
• Separate drift into response-specific categories Create distinct handling paths for tool misuse, credential drift, data access drift, and resource anomalies. Do not force every deviation into one anomaly queue, because each category implies a different likelihood of prompt injection, lateral movement, or exfiltration.
• 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. That rule prevents teams from normalising silent changes in credentials, tool chains, or data destinations.
• Track observed credential use, not only granted credential scope Compare what the agent is allowed to use with what it actually uses during the last 30 days. New role assumption or token use without a corresponding change record should trigger investigation, not baseline refresh.
• Use resource bounds as a supporting signal, not the primary signal Set expected CPU, memory, and network envelopes for inference and tool execution, then correlate any breach of those bounds with identity or data drift. This keeps alerting focused on combinations that suggest compromise rather than expected burstiness.

Key takeaways

• AI agent baselines must evolve with the workload because prompts, context, and tool access change normal behaviour over time.
• Deployment correlation, pattern continuity, and resource bounds are the practical tests that separate legitimate change from high-risk drift.
• Identity drift matters most when it shows new credential use, new data access, or tool misuse, because those are access events, not mere anomalies.

Key terms

• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Drift Correlation: Drift correlation is the practice of checking whether a runtime change lines up with an approved deployment, prompt revision, configuration update, or integration change. It turns anomaly detection into a decision process by separating expected evolution from changes that lack a legitimate explanation.
• Identity Drift: Identity drift is the gap between the access path originally approved and the behavior that exists later. For browser extensions, drift can appear through updates, remote configuration, publisher changes, or permission expansion, turning a trusted integration into a materially different risk.
• Runtime-Informed Posture: Runtime-informed posture combines declared permissions with observed behaviour. It shows the gap between what an AI workload could do on paper and what it actually does in production, which is the difference security teams need when assessing real exploitable risk.

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.

👉 ARMO's full post covers the runtime signal model, drift taxonomy, and observe-to-enforce workflow in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.