Notifications
Clear all
Topic starter
09/07/2026 3:18 pm
TL;DR: Kubernetes-based AI agents need their own workload identity when they act autonomously, persist beyond a user session, or reach beyond the user’s permission scope, according to Teleport. The governance problem is not container security alone, but identity reuse that breaks accountability, traceability, and least privilege.
NHIMG editorial — based on content published by Teleport: Kubernetes for Agentic AI: Best Practices for Identity and Access
By the numbers:
- 70% of organizations currently grant their AI systems more access than a human in the same role.
- 67% of organizations report a high reliance on static credentials such as API keys and long-lived tokens.
- A 20-point increase in AI-related incidents aligned with that reliance on static credentials.
Questions worth separating out
Q: How should security teams govern AI agents that run inside Kubernetes?
A: Treat the agent as a workload identity with its own lifecycle, not as an extension of the initiating user.
Q: Why do AI agents complicate Kubernetes RBAC models?
A: RBAC controls permissions, but it does not fully isolate shared execution paths, shared data stores, or agent-to-agent communication.
Q: What breaks when an AI agent inherits a human user identity?
A: Attribution becomes unreliable when the agent acts after the user session has ended or outside the user’s intended scope.
Practitioner guidance
- Assign distinct workload identities to agents that outlive a user session Bind identity to the pod, namespace, or execution context using short-lived credentials such as SPIFFE IDs or OIDC tokens.
- Separate agent tenancy with network and namespace boundaries Combine namespace isolation, service mesh controls, and network segmentation so one agent cannot freely traverse another agent’s tools or data paths.
- Make tool invocation and data access task-scoped Restrict agents to pre-approved tool interfaces, apply OAuth2 scopes where possible, and use query-level controls for shared stores such as RAG databases or vector stores.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific guidance on when an agent should inherit a user identity versus receive a unique workload identity.
- Implementation detail for SPIFFE IDs, Kubernetes service accounts, and short-lived OIDC or SVID credentials.
- Practical tenancy controls across namespaces, service meshes, and network boundaries for shared agent infrastructure.
- Tool and data access patterns, including MCP Access Controls, session recording, and identity chain visibility.
👉 Read Teleport's analysis of Kubernetes identity and access for agentic AI →
Kubernetes for agentic AI: what identity teams should change?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
09/07/2026 3:35 pm
Workload identity, not session identity, becomes the governance baseline for agentic Kubernetes deployments. Agents that persist beyond the user session or initiate their own workflows are no longer represented accurately by the human account that started them. That breaks the assumption that authorisation can be anchored to the initiating user, and it makes traceability dependent on the workload itself. The implication is that identity teams must reframe the agent as the primary subject of control, not the user behind the prompt.
A few things that frame the scale:
- 69% of organisations now have more machine identities than human ones, according to The Critical Gaps in Machine Identity Management report.
- 66% report that managing machine identities requires significantly more manual intervention compared to human identity management, according to The Critical Gaps in Machine Identity Management report.
A question worth separating out:
Q: Who is accountable when an AI agent uses privileged access in production?
A: Accountability should follow the initiating human, the workload identity, and the policy that allowed the action. If those three are not visible together, incident review becomes guesswork. Teams should align runtime authorisation, audit trails, and ownership so every privileged agent action can be traced to a responsible control point.
👉 Read our full editorial: Kubernetes agent identity needs workload-level access and isolation
