How should security teams identify AI agents in Kubernetes when there is no native agent identity type?

Use a dedicated service account for each agent so API calls name one non-human principal, not a shared workload identity. Put descriptive metadata such as owner, model and connected tools in labels or annotations, but treat those fields as mutable and review them. For investigation, bind the agent’s behavior to a workload object that survives pod restarts, so attribution remains stable.

Why Kubernetes still needs a proxy identity for AI agents

Kubernetes does not give you a native “agent” principal, so the practical move is to map each agent to a dedicated service account and treat that account as the API identity boundary. That keeps requests attributable, avoids shared credentials, and makes the agent’s authority visible in the cluster’s own control plane rather than hidden in application logic or pod names.

A dedicated account also gives you a stable handle for authorization, auditing and revocation. When the agent changes implementation details, restarts, or moves between pods, the identity that matters to the cluster remains the same if it is anchored to the service account rather than the ephemeral runtime instance.

For teams working through agent identity design, Agentic AI Identity Guide is the clearest starting point because it covers identity models, delegation, registration and retirement for AI agents. If you also need a broader control lens, Zero Trust for AI Agents explains why the agent, principal and request all need verification before any action is trusted.

How metadata helps, and why it cannot be the identity

Labels and annotations are useful for the descriptive fields that Kubernetes does not model as first-class identity properties, such as owner, model name, environment, or connected tools. They improve search, governance and incident response, but they remain mutable metadata, so they should never be the only evidence of who or what an agent is.

The better pattern is to separate identity from description. The service account answers “which principal called the API?”, while metadata answers “what is this workload doing and who owns it?”. That separation matters because humans can edit labels more easily than they can safely change the account that authorization and audit rely on.

For practitioners building inventory and response processes, the AI Agent Observability, Audit and Incident Response Guide is useful because it focuses on what to log and how to attribute agent actions. If your environment still lacks clear inventory, Shadow AI and AI Agent Discovery Guide helps teams discover unmanaged agents through the signals they leave behind.

What to bind for stable attribution across restarts

For investigation and operational continuity, bind the agent to a workload object that survives pod restarts, rather than to a single container instance. That gives you a durable attribution anchor when replicas roll, pods are rescheduled, or the implementation is redeployed under the same logical agent.

In practice, that means the workload object, service account, and descriptive metadata should line up, so the same agent can be traced from request to runtime to owner. If those three drift apart, attribution becomes fragile and security teams lose confidence in both alert triage and post-incident reconstruction.

The strongest supporting pattern is to keep the agent’s authority narrow and observable. AI Agent Authorisation Guide is relevant here because it frames least privilege and per-action authorization as the control point, not just the existence of an account. For a standards view, SPIFFE workload identity specification is a useful reference for stable workload identity concepts, even when you are using Kubernetes service accounts as the primary operational handle.

Risk and Threat Considerations

When AI agents are tracked only through pod names or mutable metadata, attribution breaks as soon as the workload is restarted, renamed, or scaled. Shared identities increase the blast radius further, because one compromised agent can inherit another agent’s access path and make investigation ambiguous.

Failure mechanism: The cluster cannot distinguish one agent from another if multiple workloads reuse the same principal, or if investigators rely on labels that can be changed without changing authorization.

Impact: Unauthorized actions become harder to trace, revocation becomes less precise, and a single compromise can look like normal activity from an indistinct workload.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Each agent needs its own principal to avoid shared, excessive access.
	NHI-09 — NHI Reuse	Shared workload identities and reused principals obscure attribution across agents.
	NHI-10 — Human Use of NHI	Operators can misuse mutable metadata as if it were trustworthy identity evidence.
Recommendation — Assign each agent a unique service account and remove shared privileges. Prevent reuse by binding one service account to one agent. Keep descriptive metadata separate from the trust decision for access.
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	The question is about agent identity and preventing ambiguous or excessive authority.
Recommendation — Bind each agent to a unique principal and verify requests before allowing action.
NIST SP 800-53 Rev 5	IA-9 — Service Identification and Authentication	Kubernetes agents are non-human services that need a distinct authenticated principal.
	AU-2 — Event Logging	Stable attribution depends on logging which principal and workload performed each action.
	AC-6 — Least Privilege	Dedicated agent identities should only carry the access required for their task.
Recommendation — Use service accounts as the agent authentication boundary and avoid shared credentials. Log service account, workload and owner data together for every agent action. Scope each agent’s permissions to the minimum required for its function.
NIST Zero Trust (SP 800-207)	GV.OC-01 — Strategy, Scope, and Objectives Are Established and Communicated	The answer depends on defining a clear identity boundary for each agent in the cluster.
Recommendation — Define the agent identity boundary before deployment and enforce it consistently.
CIS Controls v8	CIS-5 — Account Management	Unique agent service accounts are an account-management control, not just a naming choice.
Recommendation — Provision, track and retire one account per agent lifecycle.

Practitioner Guidance

What to prioritise: Give each agent its own service account first, then align the workload object, metadata and ownership record so they all point to the same logical actor. That order matters because descriptive tags are only useful after the API principal is unambiguous.

What to verify: Confirm that no two agents share the same API identity, and that the service account remains the authoritative handle in logs, alerts and access reviews even after redeployments or pod churn.

Common mistake: Treating labels as identity and using them to decide who may act. Labels are for context, not trust, and they should be assumed editable.

Practitioner takeaway: The goal is not to name every agent perfectly in metadata, but to make sure the cluster can always answer one question reliably: which non-human principal actually performed the action?