No. An agent that works under a person's login inherits everything that person can do, and every action it takes looks like theirs. That breaks the audit trail, defeats separation of duties and makes approvals meaningless. The deciding factor is attribution: each agent needs its own identity, with permissions cut to its role, so you can tell who acted.
Why do teams end up sharing logins?
Usually for speed. A team wants an agent to work in a system that has no interface for software, so someone gives it their username and password, or runs it inside their browser session. It works on day one.
Then the problems arrive. The person's permissions were set for a person, with years of accumulated access. The system's log shows the person doing things at three in the morning. When the person leaves or changes role, the agent breaks, or worse, keeps working with access nobody now reviews.
What does a shared login break?
| Control | What goes wrong |
|---|---|
| Audit trail | Agent actions are recorded as the person's; you cannot separate them |
| Least privilege | The agent gets every right the person has, not the few it needs |
| Separation of duties | If the person is an approver, the agent can approve its own drafts |
| Human approval | An approval made "by" the person may be the agent clicking the button |
| Access reviews | Reviewers see one user and miss that two actors use it |
| Leaver process | Disabling the person silently disables, or fails to disable, the agent |
| Your acceptable use policy | Most policies forbid sharing credentials, for people too |
The approval problem deserves emphasis. Human in the loop is not a control unless the person can say no, and a person whose login the agent holds cannot say no to anything the agent does in their name.
What should happen instead?
- The agent gets its own identity, registered in your access management system, owned by the process owner.
- Permissions are set for the role, not copied from a person.
- The agent acts through tools, each a defined action with defined inputs. Our explainer on what tool use is covers how this works.
- Where a system has no interface, a person does that step, or the system owner creates a dedicated service account with narrow rights.
- Staff are told plainly not to lend their credentials or browser sessions to agents. Put it in the acceptable use policy for staff using AI agents.
Is it different for customer logins?
It is stricter. A customer's credentials belong to the customer and often to their bank or provider as well. An agent holding them creates risks for both. We cover that case in whether an AI agent can hold a customer's login credentials.
A worked example
Take a lettings company where a property manager has an assistant agent drafting tenancy notices. To save time, the manager lets the agent use her login to the property management system. Her account also approves deposit returns.
A tenant disputes a deduction. The system log shows the manager approved the return at 23:40. She did not; the agent did, after misreading her instruction to "sort out the deposit queue". Nobody can now show whether a person reviewed it. The company re-registers the agent under its own identity with rights to draft notices and propose deposit returns, and approvals go back to the manager's own hands.
Which controls make the answer hold?
- Detect shared use. Flag logins with machine-like patterns: constant activity, impossible hours, many sessions.
- Separate identities for every agent, never pooled across agents either.
- Approvals bound to a person's own authentication, so an agent cannot click them through.
- Leaver and mover checks that list the agents a person owns, not just the accounts they hold.
- A filed record of each agent action under its own identity, with the verdict and the bound that decided.
The topic guide, agent governance is a bound, not a model, explains why identity is the first bound every action must meet.
Questions people ask
Can an agent act "on behalf of" a person with delegated access?
Yes, if the system supports delegated access that records both the person and the agent, with narrower rights than the person's. That is different from sharing a login.
What if the person is present and watching?
Watching does not change the record. The log still shows the person acting, and over time watching becomes glancing. Give the agent its own identity anyway.
Our system charges per named user. Does the agent need a licence?
Often yes. Budget for it. A licence is cheaper than an audit finding that you cannot tell your staff's actions from your agent's.