Topic starter
19/08/2026 3:55 pm
TL;DR: AI agents in Kubernetes can be coerced into misbehaviour without a vulnerability being exploited, because prompts, retrieved content, and tool responses become attack surface, according to ARMO. The practical shift is from static permission reviews to runtime reachability, behavioural baselines, and evidence-linked threat closure for every agent.
Editorial analysis by NHI Mgmt Group, based on content published by ARMO: “How to Threat Model AI Agents in Kubernetes: A Practical Framework”.
Key questions
Q: What fails when AI agent threat models rely only on declared permissions?
A: Declared permissions fail as a security boundary because they describe what the agent was approved to do, not what it can be steered into doing at runtime.
Q: Why do AI agents in Kubernetes create risk without a vulnerability being exploited?
A: Because the attacker can manipulate context instead of breaking code.
Q: How can security teams tell coercion from compromise in AI agent environments?
A: Compromise shows up like a conventional intrusion, with syscall anomalies, unauthorized binaries, or unexpected process activity.
Practitioner guidance
- Map the agent to runtime-visible components Inventory the inference pod, tool servers, RAG store, ServiceAccount bindings, and cluster runtime dependencies using telemetry the platform already emits.
- Measure reachable capability against declared permission Compare manifests, role bindings, and tool registrations with two to four weeks of observed API calls, syscalls, and tool invocations.
- Classify threats as coercion or compromise Separate vulnerability-driven compromise from prompt-driven coercion, then attach different detections to each class.
Bottom line: AI agents in Kubernetes can be coerced into harmful action without a software exploit, which makes runtime evidence the decisive input to threat modeling.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:31 pm
Runtime evidence, not approval-time intent, is now the governing unit for AI agent security. Traditional threat models assume a stable permission envelope and a clear exploit boundary. AI agents break both assumptions because prompts, retrieved content, and tool outputs can alter behaviour without changing code. For IAM and NHI governance, that means the control point moves to observed runtime reachability and evidence-linked closure, not just manifest review.
A few things that frame the scale:
- 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 teams maintain a threat model for an AI agent that keeps changing?
A: Treat the model as a living artifact. Re-open it whenever the agent gains a new tool connection, changes model version, or expands its prompt-reachable surface. If the catalog does not re-converge after those events, it is no longer describing the deployed system and should not be trusted for governance.
👉 Read our full editorial: Threat modeling AI agents in Kubernetes requires runtime evidence