What breaks when runtime security is not blocking access to service account tokens inside a compromised container?

Why This Matters for Security Teams

service account tokens are not ordinary application data. They are bearer credentials that can authenticate workloads to the control plane, other services, and sometimes cloud APIs. If runtime security does not prevent token access inside a compromised container, the attacker is no longer limited to the initial foothold. They can often turn a single pod compromise into cluster-level trust abuse, secret discovery, or lateral movement into adjacent namespaces.

This is where identity and runtime security meet. The issue is not just whether a pod can read a file, but whether a non-human identity can be used outside its intended workload context. The OWASP Non-Human Identity Top 10 highlights how unmanaged or overexposed machine credentials become a pivot point for broader compromise. Security teams often focus on admission controls and image scanning, yet runtime token blocking is the control that stops an intruder from using what the workload already trusts.

In practice, many security teams encounter this only after an attacker has already used a stolen token to enumerate the cluster and widen access, rather than through intentional containment testing.

How It Works in Practice

A compromised container usually inherits whatever the orchestration platform mounts or injects by default. In Kubernetes, that may include a service account token, CA bundle, and namespace context. If runtime security is not actively restricting file reads, process access, or token exfiltration, malware or an operator with shell access can harvest the token and replay it against the API server. From there, the attacker may query secrets, list pods, watch events, or find service accounts with broader permissions than the original workload needed.

The practical defense stack should combine identity hardening and runtime enforcement. At minimum, teams should:

• Disable unnecessary token mounts and use short-lived projected tokens where supported.
• Apply least privilege to the service account and verify the token cannot be reused outside the workload context.
• Block sensitive file access and suspicious process behavior at runtime, especially interactive shells and credential-dumping tools.
• Monitor API server authentication events for anomalous service account use, token replay, and unusual namespace traversal.

Runtime protection should also be aligned with broader control guidance. NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to access enforcement, auditing, and system monitoring, even though it does not prescribe Kubernetes-specific mechanics. The operational goal is simple: a pod compromise should not automatically become a control-plane compromise. These controls tend to break down when legacy workloads require long-lived secrets, because static credentials are harder to confine and easier to replay.

Common Variations and Edge Cases

Tighter token protection often increases operational overhead, requiring organisations to balance workload convenience against containment strength. That tradeoff is most visible in clusters that run legacy applications, sidecar-heavy architectures, or controllers that still depend on broad namespace visibility. In those environments, best practice is evolving rather than settled, and some teams still accept higher exposure in exchange for application compatibility.

There are also edge cases where blocking token access alone is not enough. If a workload already has overprivileged RBAC bindings, the attacker may not need to steal a token at all. If the runtime policy only protects mounted files but not in-memory credential use, an adversary can still abuse the identity through the application process. And if detection is weak, short-lived token theft may remain invisible until audit logs show suspicious API calls.

For cloud-native environments, the safest interpretation is that service account tokens must be treated as high-value NHI credentials. That means access to them should be constrained by design, denied at runtime where possible, and continuously audited when denial is not feasible. The Anthropic report on the first AI-orchestrated cyber espionage campaign is a reminder that automated abuse increasingly targets exactly this sort of reusable access. Where clusters still rely on static tokens, the guidance breaks down fastest in multi-tenant environments with broad API access and weak audit segregation.

Related resources from NHI Mgmt Group

• What breaks when agents are given personal access tokens and service account keys directly?
• How should security teams reduce the impact of a compromised service account?
• How should security teams respond when a compromised laptop has cached service-account credentials?
• How should security teams reduce the risk of Kubernetes service account tokens?