There is a decision made in the first two weeks of any agent project that determines whether it will be auditable for years afterwards. It is the decision of how many identities to create. And it is almost always made out of laziness: one, called agent-sa.
What a shared identity costs
With one identity for the whole fleet, you lose four capabilities at once:
- Attribution. The log says the automation account deleted the record. Which of the eleven agents? Impossible to say.
- Least privilege. The identity's permissions are the union of what every agent needs. The agent that only reads reports carries production write access because another one needed it.
- Containment. Revoking the credential takes the whole platform down. In practice nobody revokes it — the cost is too high mid-incident.
- Baseline. Anomaly detection requires typical behaviour per actor. Eleven agents on one identity produce a profile that describes none of them.
A shared identity is not an operational shortcut. It is the decision not to be able to investigate.
The practical objection, and the answer
The objection is always the same: managing dozens of identities is work. It was, back when identity meant a static key that someone created and distributed by hand. With workload identity federation, identity derives from execution context — the pod, the cluster service account, the repository — and there is no key to manage.
The work that remains is defining each one's permissions, and that is work you should be doing anyway.
Where to start if you are already sharing
Do not try to split everything at once. Start with the agent holding the most write permissions and give it its own identity with reduced scope. Then split the ones doing external reads — those are likeliest to receive hostile content. The rest can wait.
