Yes. Give each workload its own ServiceAccount with only the permissions it needs. Pods that do not name one get the namespace's default ServiceAccount, so every such pod shares one identity, and any permission added to it reaches all of them.
What the documentation says
The Kubernetes documentation explains that each namespace gets a ServiceAccount named default. By default it has no permissions beyond API discovery rights that all authenticated principals receive when RBAC is on. If you deploy a pod without specifying a service account, Kubernetes assigns that default account. To use a custom account you create the object, grant permissions with RBAC, and set serviceAccountName on the pod.
The docs also say to use RBAC to grant the minimum permissions each service account needs, so that pods using it get no more than required. And they describe how credentials are delivered: from Kubernetes v1.22 a short lived, automatically rotating token via the TokenRequest API is mounted as a projected volume, and you can turn off automatic injection with automountServiceAccountToken set to false.
Why sharing the default is a problem
- Permission creep. Someone gives the default account a role for one app. Every other pod in the namespace now has it.
- Poor audit trail. API server logs show the account, not the app, so you cannot tell which workload acted.
- Larger blast radius. If one pod is compromised, the attacker holds the shared identity.
- Cloud identity coupling. If you bind a cloud role to a service account, a shared account hands that role to everything using it. See workload identity.
How to do it
- Create a ServiceAccount per workload, named after it.
- Set serviceAccountName in each Deployment or Job template.
- If the app does not call the Kubernetes API, set automountServiceAccountToken to false, as in this guide.
- For apps that do need the API, write a Role with the specific verbs and resources, and bind it with a RoleBinding.
- Avoid cluster wide roles unless truly needed, and avoid wildcard verbs and resources.
- Leave the default account with no extra bindings.
Review what exists
List bindings that reference default accounts and review any that grant more than discovery access. Look for service accounts nobody uses. Check which workloads mount tokens and whether they use the API. The Kubernetes security checklist is a good source for further checks.
Tokens that never expire
The docs call long lived service account token Secrets not recommended, because those tokens do not expire or rotate, and say that you can still create them manually. Prefer the TokenRequest API or projected volumes. If a legacy integration forces a static token, record its owner and plan its replacement. See how service account tokens work.
Quick check
Does the default service account have admin rights?
No. By default it has only the API discovery permissions given to authenticated principals when RBAC is on, but people often add roles to it, and then all pods share them.
Should pods that do not use the API mount a token?
No. Set automountServiceAccountToken to false so a compromised container does not get a credential it never needed.
Are projected tokens better than Secret tokens?
Yes. The docs recommend projected volumes or the TokenRequest API because those tokens expire and rotate, unlike static Secret tokens.
Where Safeguard fits
Safeguard's agent identity and policy features cover identity for AI agents and guardrails around them, and its asset discovery helps you keep an inventory of workloads. Dependency scanning covers the code those workloads run; try a free scan.
Sources
Last reviewed: 19 October 2026.
