Why do AI agents on Kubernetes create a different identity risk than normal workloads?

Why This Matters for Security Teams

AI agents running on Kubernetes are not just another workload class. They can interpret prompts, call internal tools, chain API requests, and act on data they were never meant to see. That makes the identity risk dynamic: the same service account can be low-risk in a benign session and high-risk when the agent is influenced by malicious instructions. Current guidance suggests treating the agent’s runtime behaviour, not only its deployment manifest, as the real security boundary.

This is why static RBAC often breaks down. A normal pod usually follows a narrow, predictable path. An agent can branch, retry, escalate through available integrations, and reuse credentials across multiple tool calls. The threat is amplified when secrets are long-lived or stored outside a secrets manager, a pattern documented in NHIMG research on NHI exposure and rotation gaps in the Ultimate Guide to NHIs. For agentic systems, the question is not only “what can this pod reach?” but “what could this pod be induced to do?” In practice, many security teams discover that distinction only after an agent has already chained internal access into unauthorized action.

Attackers also move quickly once credentials are exposed. NHIMG reports that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, which is a useful reminder that agent identity failures are operational, not theoretical, as discussed in LLMjacking: How Attackers Hijack AI Using Compromised NHIs.

How It Works in Practice

For autonomous workloads, identity needs to be issued and evaluated at runtime. Best practice is evolving toward workload identity, short-lived credentials, and policy decisions that consider intent, context, and task scope. In Kubernetes, that means the pod identity should prove what the agent is through cryptographic workload identity, while authorization should decide what the agent may do right now. The SPIFFE workload identity specification is often used as the identity primitive for this model.

Practically, teams reduce blast radius by combining pod-level identity with just-in-time access, ephemeral secrets, and policy-as-code. A task-specific token can be minted for a single action, validated against request context, and revoked automatically once the task ends. This is a different control model from static Kubernetes service accounts or broad namespace-scoped RBAC. Static permissions assume stable intent; agents do not have stable intent. The OWASP Agentic AI Top 10 and the CSA MAESTRO agentic AI threat modeling framework both reflect this shift toward runtime evaluation and tool-use governance.

• Use workload identity for the pod, not shared secrets baked into images or ConfigMaps.
• Issue short-lived tokens per task, with automatic revocation after completion.
• Constrain tool access by policy, not by a one-time deployment decision.
• Log prompt, tool call, and token usage together so identity decisions can be reconstructed.

NHIMG’s OWASP NHI Top 10 reinforces the point that agentic systems need identity controls aligned to tool execution, not just infrastructure access. These controls tend to break down when agents run across multiple clusters with inconsistent policy enforcement because credential scope and telemetry become fragmented.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance blast-radius reduction against developer friction and scheduler complexity. That tradeoff is especially visible in data science platforms, multi-tenant clusters, and agent pipelines that depend on third-party APIs. There is no universal standard for this yet, so current guidance suggests prioritising short-lived credentials and intent-based authorization where the agent can take meaningful actions.

Edge cases usually involve cross-namespace access, human-in-the-loop fallback, or agents that must persist state across long-running workflows. In those environments, overly aggressive TTLs can interrupt legitimate jobs, while overly permissive tokens recreate the same standing-access problem under a new label. NIST’s NIST AI Risk Management Framework is useful here because it encourages governance around measurable risk, not just control presence. NIST’s NIST Cybersecurity Framework 2.0 also remains relevant for asset visibility and access oversight.

The biggest exception is long-lived agent processes that legitimately need broad internal reach. In those cases, the answer is not to pretend the workload is ordinary. It is to segment the agent, split duties across smaller identities, and place the most sensitive tool calls behind explicit approval or step-up controls. When teams skip that redesign, they usually find the weakness after prompt injection or lateral movement has already turned a harmless pod into an active abuse path.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Why do AI agents create a different access-risk profile than traditional applications?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more risk when they reuse existing credentials?