For years, enterprise automations ran under an identity that should not really exist: the shared service account. A technical user, created for “the bot”, password in a vault, permissions extended as needed and never rolled back. As long as the bot only retyped screens, that was a known risk. With agents that call tools, read data and trigger postings on their own, it becomes a liability question.

What changed

The identity providers have recognised the problem — and productised it. Okta, Microsoft Entra and others now offer building blocks that give an agent a first-class identity of its own: registration like a user, single sign-on into the applications it needs, and cross-application access that no longer runs on stored passwords but on short-lived, scoped tokens. This is no longer a niche; it is the direction identity management is moving in.

That shifts the question. It used to be: how do we get the bot into the system? Now it is: which rights does this agent have, who granted them, and when do they expire? Exactly the questions an auditor asks about a human employee.

Why the service account has to go

  • No attribution. If three agents share one account, the audit log says “the bot posted it” — not which one, why, or with what goal.
  • Standing privileges. Service accounts accumulate permissions over years. A compromised credential is a master key.
  • No expiry. Vault passwords rotate rarely. A token with a 60-minute lifetime expires on its own.
  • No access reviews. People get reviewed regularly, service accounts almost never. An agent with an identity lands in that same process automatically.

What this means for you

Anyone putting an agent into operation today should settle three things before the first productive call. First: the agent exists in the identity system as its own principal — with an owner, a purpose and an expiry date. Second: its rights are least privilege and documented as policy, not as a click history in the admin panel. Third: every one of its actions carries its name in the log. This is not a security extra to retrofit; it is the foundation on which autonomy becomes defensible at all.

For existing bot fleets, an inventory pays off: which service accounts exist, who uses them, what rights do they hold? In most organisations the honest answer is uncomfortable — which is exactly why it is the right place to start.