The shared-secret shortcut
The easiest way to give a service or an agent an identity is to hand it a static credential — an API key, a token — and treat possession of that string as proof of who it is. This is quick to set up and, over time, becomes the weakest link: the secret can be copied, checked into a repository by accident, or extracted from a compromised host, and whoever holds a copy is now indistinguishable from the legitimate principal.
A verifiable identity is stronger than a shared secret when it can prove itself without exposing something that, once seen, is fully cloneable — for example, through a cryptographic key pair where only a signature is ever transmitted, never the private key itself.
What changes for agents specifically
An autonomous agent often needs an identity distinct from both the human who deployed it and the service account it runs under, because its behavior — what it requests, how often, on whose authority — is different from either. Collapsing an agent's identity into a shared service account makes it impossible to answer a basic audit question later: was this specific action taken by the agent acting autonomously, or by a person using the same credentials directly?
Giving each agent (or each class of agent performing a given task) its own distinguishable identity is what makes the rest of an authorization system — scoped permissions, revocation, evidence — actually attributable to the right actor.