Agent Identity: Why Service Accounts Are Not Enough

Only 21.9% of teams treat AI agents as independent, identity-bearing entities rather than extensions of human users or generic service accounts — and the 2026 security research identifies this as the core of the problem.

It sounds like an administrative detail. It determines whether anything else in your security model works.

For a vendor-side perspective on remote workforce management, see this guide from Monitask.

The two wrong patterns

Borrowed human credentials

The agent runs as a person — usually whoever set it up, or the user it acts for.

What breaks:

Attribution. Every action appears to have been taken by that person. Your audit log becomes fiction.

Permissions. The agent inherits everything that person can do, which is far more than the task needs.

Revocation. Removing the agent's access means removing the person's.

Departure. When that person leaves and their account is disabled, the agent stops — usually discovered in production.

And accountability. A human whose credentials took an action they did not take is in an unpleasant position.

Shared service accounts

One account used by several agents, or by agents and scripts together.

What breaks:

You cannot tell which agent did what. The log says "service-account-3", and three things use it.

You cannot revoke one without breaking the others.

Permissions become the union of everything that account needs, which grows and never shrinks.

And rotation is painful, so it does not happen.

What an agent identity needs

Its own credential, not shared, not borrowed.

Attribution in logs — actions recorded as taken by this agent, and where relevant, on whose behalf. Both parts matter: an agent acting for a user needs the record to show both.

Scoped permissions per system, granted to the agent rather than inherited.

Individual revocation. One action, stopping this agent, without touching anything else.

A lifecycle. Created, reviewed, rotated, retired. Agents created for pilots persist for years otherwise.

And an owner. A named person responsible for it. Unowned agents are how "shadow AI" becomes permanent.

Delegation: acting on behalf of a user

The pattern most people actually need, and the one most often done badly.

An agent doing something for a user should have that user's permissions, not more, and the log should record both the agent and the user.

Done through borrowed credentials, both properties are lost. The agent has everything the user has in every context, and the log shows only the user.

Done properly, the agent has its own identity and receives a scoped, time-limited delegation for the specific task. Standard authorisation mechanisms support this — it is more work at setup and it is not novel technology.

Agents calling agents

Where this gets genuinely hard.

Only 24.4% of organisations have full visibility into which agents are communicating with each other, and more than half of agents run without security oversight or logging.

Permissions compose in ways nobody designed. An agent with narrow scope that can invoke one with broad scope has broad scope.

Attribution across a chain requires the identity to propagate, and by default it does not — the second agent sees a call from the first, with no trace of the original user.

If you run more than one agent, map what can call what before assuming individual scopes hold. See permissions.

Doing it without an identity platform

Most organisations do not have agent identity built into their tooling yet. Workable approximations: For broader independent background, see OWASP GenAI Security Project.

A dedicated account per agent in each system. Not per team, not per project — per agent.

A naming convention that makes agents obviously distinguishable from humans in any log.

A register. Which agents exist, what each can reach, who owns it, when it was last reviewed. A spreadsheet is fine and it is far better than nothing.

Scheduled review. Quarterly: is this still needed, does it still need this access, who owns it now.

And credentials that can be revoked individually, tested before you need to.

For small teams

The same principle, proportionate.

Separate accounts, not yours. So you can revoke without disrupting yourself.

One per agent if you run several, so you can tell what did what.

Write down what exists and what each can reach. Three lines in a note.

And check what a connected integration is actually granted — the consent screen usually grants more than the task needs.

See agents for a one-person business.

The short version

Only about a fifth of teams give agents their own identity, and the research names this as the root problem.

Borrowed human credentials destroy attribution and inherit far too much. Shared service accounts destroy the ability to tell agents apart or revoke one.

Delegation should be scoped and time-limited, with both agent and user in the log.

Permissions compose across agent chains in ways nobody designed — map what can call what.

And keep a register with an owner per agent, because unowned agents are how shadow deployment becomes permanent.