Notifications
Clear all
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.
NHIMG editorial — based on content published by ARMO: Threat Model AI Agents in Kubernetes: A Practical Framework
Questions worth separating out
Q: How should security teams threat model AI agents in Kubernetes?
A: Start with runtime objects, not diagrams.
Q: Why do AI agents complicate traditional Kubernetes threat models?
A: Because the attacker can control context rather than exploit code.
Q: What breaks when AI agents are given broad inherited permissions?
A: Broad inherited permissions break the assumption that access is tied to a narrow business need.
Practitioner guidance
- Map agent components to observable runtime objects Inventory each agent’s pod, ServiceAccount, MCP server, RAG store, and external tool path, then bind each one to a telemetry source such as kube-audit, eBPF, or identity event streams.
- Measure reachable capability against declared permission Run a two-to-four-week observation window and compare granted permissions with the API calls, tool invocations, and syscalls the agent actually uses.
- Separate coercion detections from compromise detections Create one detection path for exploit-style compromise and another for authorised but anomalous behaviour, including unusual tool-call sequences and drift from baseline.
What's in the full article
ARMO's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step decomposition of AI agents into Kubernetes-runtime primitives and telemetry sources
- The full reachable-capability workflow for comparing declared permissions with observed agent behaviour
- Per-step examples of coercion and compromise classes mapped to specific runtime evidence signals
- The maintenance loop for reopening the catalog after new MCP connections, model updates, or tool changes
👉 Read ARMO's practical framework for threat modeling AI agents in Kubernetes →
AI agents in Kubernetes: what runtime threat modeling actually needs?
Explore further
19/08/2026 4:31 pm
AI agent threat modeling is now an identity governance problem as much as a Kubernetes problem. When an agent can act through ServiceAccounts, MCP tools, and delegated runtime access, the security question is no longer only whether the pod is hardened. It is whether the agent’s effective identity, reachability, and privilege boundaries match its intended role. Organisations that model only declared permissions miss the control surface that prompt coercion actually uses. Practitioners should govern agent identity as runtime behaviour, not as a static manifest.
A question worth separating out:
Q: How do teams know when an AI agent threat model is stale?
A: It is stale when a change in model version, MCP connection, tool registration, or behavioural baseline has not triggered a new review. The threat model must converge against current runtime evidence, because a frozen catalog cannot reflect the agent the cluster is actually running.
👉 Read our full editorial: Threat modeling AI agents in Kubernetes requires runtime evidence
