Why a shared service account identity actively hides problems
When multiple agent instances, versions, or tasks share one identity, an audit log shows that "the service account" did something — not which agent, which version, or which task triggered it. Debugging an incident under those conditions means reconstructing context the identity model should have captured for free.
This is the same problem human shared-login accounts caused for decades in security audits, now recreated for a class of actor that changes behaviour far more often than a human does.
What a proper agent identity model includes
A distinct identity per agent deployment, scoped credentials per task rather than per session, and an audit trail that captures agent version and task context alongside every action, turns an opaque incident investigation into a traceable one.
This pairs directly with the task-scoped permission model covered in our AI practice's work on agentic authorisation — identity and permission are two halves of the same control.
A shared service account turns every agent incident into a mystery. A proper identity model turns it into a lookup.MNB Security Practice
Key actions
- Assign a distinct identity per agent deployment, not a shared service account
- Scope credentials per task, not per session
- Capture agent version and task context in every audit log entry
- Treat agent identity and permission scoping as linked controls