Open your audit log and find something an agent did last week. It will be attributed to a person. That person was probably asleep.

This is the quiet identity problem in almost every organisation running agents today, and it undermines the one control everyone assumes they have.

Why Borrowed Credentials Break Everything

When an agent acts using a human account, four things break at once.

Your audit trail becomes fiction, because you cannot distinguish a person from an automation. Least privilege becomes impossible, since the agent inherits everything that human can reach. Offboarding breaks, because disabling the leaver account silently kills a production automation. And incident response stalls, since you cannot revoke the agent without locking out a person.

What an Agent Identity Should Contain

• A unique identifier distinct from any human account.
• A named human owner who is accountable and reviewed when they change role.
• Scoped permissions covering only the systems this agent needs, at the access level it needs.
• A purpose statement in plain language, so a reviewer in a year knows what it is for.
• An expiry or review date. Agents outlive the projects that created them, always.
• Its own credentials, short-lived and brokered rather than long-lived and pasted into a config file.

The Direction the Protocols Are Going

This is not a niche concern any more. The MCP specification is moving from Dynamic Client Registration toward Client ID Metadata Documents, where a client identity is a URL pointing to a JSON document that client controls. Client credentials are now bound to the issuer that minted them, so they cannot be reused across authorisation servers.

The direction is clear: machine clients get real, verifiable identities rather than shared secrets. Building on that now saves a migration later.

How to Retrofit This

1. Inventory what exists. Every agent, script and automation currently using a human credential. It will be more than you expect.
2. Create service identities for the top ten. Highest privilege first, because that is where the damage is.
3. Assign owners. A name, not a team. Teams do not review things, people do.
4. Cut permissions to the actual usage. Read your logs to see what each one really touches, then scope to that.
5. Add an expiry. Ninety days for new agents, renewed by the owner. This alone prevents orphaned automation.
6. Add it to offboarding. When someone leaves, their agents get reassigned or retired deliberately.

The Question That Will Be Asked

Eventually an auditor, a customer or a regulator will ask you to show who approved a specific automated action and what that automation was allowed to do at the time.

If your answer is that it ran under a shared account belonging to someone who has since left, the conversation goes badly. This work is easier to do now, with ten agents, than later with two hundred.

Conclusion

Give every agent its own identity, a named human owner, scoped permissions and an expiry date. Broker short-lived credentials rather than pasting long-lived secrets into configuration, and add agent reassignment to your offboarding checklist. Orphaned agent credentials with standing production access will be a defining audit finding of the next few years, and the fix is unglamorous account hygiene.

Frequently Asked Questions

Does this mean paying for more seats?

It depends on the vendor, and it is worth asking directly at renewal. Increasingly vendors distinguish machine identities from human seats, precisely because the old model made no sense here.

What about agents acting on behalf of a specific user?

Use delegation rather than impersonation. The agent has its own identity and acts with the user permissions for that request, and both facts appear in the log.

How do we handle agents in development?

Separate identities per environment, always. A development agent with production credentials is one careless configuration away from being a production incident.