Threat modeling AI agents in Kubernetes requires runtime evidence

At a glance

What this is: This is a practical framework for threat modeling AI agents in Kubernetes, with the key finding that prompt control can drive misbehaviour without breaking a vulnerability.

Why it matters: It matters because IAM, PAM, and NHI teams need to govern the difference between declared access and runtime reachability when agents can exercise authorised tools in unintended ways.

👉 Read ARMO's practical framework for threat modeling AI agents in Kubernetes

Context

AI agent threat modeling in Kubernetes fails when teams assume the attacker must first break something. In practice, prompt control can become control of the agent’s authorised actions, which means the real security problem is runtime reachability, not just declared permissions or static approval artifacts.

On Kubernetes, that problem has identity implications as well as application-security implications. ServiceAccounts, MCP tool servers, and per-Deployment baselines turn an abstract agent into an observable security object, and the difference between what is declared and what is reachable becomes an identity governance issue as soon as the agent can act on authorised access.

ARMO’s framework argues that the model must remain live, because a new tool, model update, or MCP connection can invalidate yesterday’s threat assumptions. That starting position is increasingly typical for teams deploying AI agents into production clusters.

Key questions

Q: How should security teams threat model AI agents in Kubernetes?

A: Start with runtime objects, not diagrams. Decompose the agent into the pod, ServiceAccount, tool servers, and data paths the cluster can observe, then compare declared permissions with what the agent actually reaches. Close each threat against a real telemetry signal and reopen the model whenever the tool surface changes.

Q: Why do AI agents complicate traditional Kubernetes threat models?

A: Because the attacker can control context rather than exploit code. A prompt, retrieved document, or tool response can steer an authorised agent into misusing its own access, which means the model must cover coercion as well as compromise and detect behavioural drift, not only runtime faults.

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. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

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.

Technical breakdown

Kubernetes-runtime primitives are the only useful threat-model boundary

AI agent threat modeling becomes actionable when the agent is decomposed into objects the cluster can actually observe. That means the inference pod, MCP tool servers, RAG store, ServiceAccount, and runtime substrate all become first-class security components. The point is not architectural neatness. It is to bind the model to telemetry sources such as kube-audit, eBPF, IAM event streams, and tool logs, so the catalog reflects what the agent really loaded and used rather than what a manifest claims it may use.

Practical implication: anchor every agent threat model to runtime telemetry from the cluster, not to design-time documentation.

Reachable capability is larger than declared permission

Declared permissions describe what an agent may do in principle, but reachable capability describes what it can be steered into doing under prompt influence. That difference is central to AI agent risk. A ServiceAccount may expose dozens of permissions, yet only a small subset may appear in normal operation. The dormant remainder still matters because prompt injection, coercive tool use, or indirect instruction can activate paths that were never exercised during approval. Security teams need to measure the gap between granted, observed, and reachable actions.

Practical implication: treat unused but granted permissions as exposed attack surface until runtime evidence proves otherwise.

Coercion and compromise produce different detection signals

The framework’s most useful distinction is between compromise and coercion. Compromise means the attacker breaks a vulnerability path, such as a stolen token or exposed kubelet API. Coercion means the attacker uses the agent’s legitimate access against itself, often through prompt injection or tool chaining. Those two classes do not look the same in detection. Compromise tends to create syscall and audit anomalies, while coercion more often appears as behavioural drift, unusual tool-call sequencing, or context-driven misuse of authorised access.

Practical implication: instrument separate detections for exploit-driven compromise and for authorised-but-coerced agent behaviour.

Threat narrative

Attacker objective: The attacker wants the agent to execute authorised actions on their behalf so that access, data, or downstream systems are used under legitimate credentials.

1. Entry occurs when an attacker controls a prompt, retrieved document, ticket, or tool response that the agent treats as context.
2. Escalation happens when that contextual control steers the agent into exercising authorised tools, ServiceAccount permissions, or MCP connections that it would not normally use.
3. Impact follows when the agent performs the attacker’s intended action with legitimate credentials, creating misuse of access, data exposure, or downstream abuse without a traditional exploit.

NHI Mgmt Group analysis

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.

Reachable capability is the right named concept for AI agent governance. The article makes clear that dormant permissions are not harmless documentation artifacts. They are latent attack surface whenever a prompt can steer the agent into action. That reframes agent governance away from approval-time entitlement review and toward evidence-based reachability analysis. In NHI terms, the agent behaves like a high-variance non-human identity whose effective privileges are discovered in production, not assumed at deployment. Practitioners should baseline what the agent can really reach before trusting declared scope.

Behavioural closure is the missing control in most AI agent programmes. A threat model that does not reconverge after tool, model, or connection changes is functionally stale. That is a control failure, not a process inconvenience. The governance assumption that a threat model can be frozen at launch collapses as soon as the agent’s runtime surface changes. In identity programmes, this is the same problem seen in unmanaged lifecycle drift. Practitioners should treat threat-model refresh as part of access governance, not as optional documentation hygiene.

Coercion requires a different detection philosophy than compromise. Traditional Kubernetes security is strongest when something breaks. AI agents create a second path where nothing breaks, but the agent behaves outside intent. That means policy, telemetry, and response need to detect authorised misuse rather than only exploit indicators. The practical consequence is that teams need behavioural envelopes for agents, not just patching and admission control. Practitioners should align detection engineering with prompt-driven misuse and tool-call anomalies.

Agentic AI security will increasingly converge with NHI policy, MCP governance, and runtime authorisation. The article is a sign that agent identity is becoming an operational category, not a theoretical one. As more agents connect to tools and data stores, the category boundary between AI security and identity governance will keep narrowing. That makes OWASP NHI and agentic-AI guidance more relevant, not less. Practitioners should expect their IAM, PAM, and AI governance teams to share responsibility for agent behaviour.

What this signals

AI agent governance is moving from approval-time policy to runtime evidence management. Teams should expect their control stack to shift toward behavioural baselines, per-Deployment observation, and tighter linkage between IAM signals and agent action paths. The concept to watch is reachable capability drift: the gap between what an agent is permitted to do and what it can be steered into doing.

For identity programmes, the practical signal is that ServiceAccounts, delegated tool access, and MCP connections are becoming part of the identity estate whether or not they are treated that way in current processes. That means lifecycle controls, access reviews, and offboarding logic need to extend into agent operations, not stop at human IAM boundaries.

For practitioners

• 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.
• Reopen the threat model on every agent change Trigger revalidation whenever a new MCP connection, model update, tool change, or autonomy shift modifies the agent’s runtime surface.

Key takeaways

• AI agents in Kubernetes can be manipulated through context, which means threat modeling must account for authorised misuse as well as code exploitation.
• Runtime reachability is a better security measure than declared permission, because dormant access becomes relevant the moment prompt control changes agent behaviour.
• Teams need living threat catalogs, not static approvals, if they want AI agent governance to keep pace with tool, model, and connection changes.

Key terms

• Reachable Capability: The set of actions an AI agent can actually be steered into performing at runtime, not just what its manifest or design says it may do. It combines declared permissions, exposed tools, and prompt-reachable paths, which is why it is a more accurate security boundary than approval-time scope.
• Coercion: A failure mode where an AI agent or automated system performs authorized actions that have been redirected by attacker-controlled content. The identity remains valid, but the sequence of actions is no longer aligned with the organisation’s intent or policy boundary.
• Runtime Evidence Signal: An observable telemetry source that can prove whether a threat materialised, such as kube-audit events, eBPF activity, or tool-call logs. In AI agent governance, every catalogued threat should close against one of these signals, otherwise the threat model is only a hypothesis.

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

👉 ARMO's full post includes the step-by-step runtime catalog method and the closure criteria for live agent threat models.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It gives security practitioners a common operating model for governing non-human access across IAM, PAM, and AI programmes.