Should an AI Agent Have Its Own User Account?
An agent borrowing a human's credentials inherits every permission that human has, logs every action under their name, and cannot be switched off without switching them off too.
Yes. Every AI agent that touches a system on its own should have its own user account there, not a borrowed human one. The reason has little to do with security posture and everything to do with three properties you lose the moment credentials are shared: you cannot tell who did something, you cannot switch one thing off, and you cannot give the agent less access than the person it borrowed from.
Each of those failures has a concrete shape, and they show up in that order as an agent deployment grows. None of this is a new principle. NIST's zero trust architecture publication states that authentication and authorisation of the subject are discrete functions performed before a session to a resource is established. An agent is a subject. It just did not used to be one.
Attribution: the log has to name the actor
An agent running as alice@company.example produces a log where every action is Alice's. Six weeks later a record was modified incorrectly and the audit trail says Alice did it. She did not, and now the investigation is a memory exercise instead of a query.
This gets worse rather than better with scale. Two agents sharing one human's credentials are indistinguishable from each other and from the human, so the first question of any incident, what changed and who changed it, has no answer. Separate identities turn that into one filter. The broader practice of keeping usable records here is in keeping an audit trail of AI use.
Revocation: you need an off switch that costs nothing
An agent misbehaving at 2am should be stoppable by disabling one account. If it runs as a person, disabling it locks that person out of their own tools, so the decision becomes a trade-off and someone hesitates. Hesitation during an incident is the expensive part.
A dedicated identity makes shutdown a boring, reversible action that a junior on-call can take without escalating. That single property is worth the provisioning effort on its own.
It also fixes the reverse case. When the human who set up the agent leaves, an agent running on their credentials dies with their account, usually silently, usually at the worst moment. This is the same class of mess covered in offboarding an employee from AI tools, and agents make it considerably worse because nobody remembers they exist.
Scope: the whole point is giving it less
A human developer has read and write access across a dozen systems because their job varies. An agent that reformats support tickets needs read on tickets and write on one field. Borrowed credentials give it the developer's blast radius to do a fraction of the developer's job.
A dedicated identity is what makes least privilege possible at all. This is the part people frame as extra work and it is actually the payoff: sandboxing an agent is much easier when the agent has something to sandbox. The runtime side of that is in how to sandbox an AI agent.
Provisioning an AI agent user account
Item | What good looks like | Why |
|---|---|---|
Identity | One account per agent, named for its job | Attribution and independent revocation |
Naming | svc-agent-ticket-triage, not bot1 | Someone reading a log in six months |
Owner | A named human accountable for it | Orphaned accounts never get reviewed |
Permissions | Explicit allow list, no role inheritance | Roles grow, agents should not |
Credentials | Short-lived tokens, rotated automatically | A leaked long-lived key is permanent |
Spend cap | Hard limit at the billing layer | Runaway loops are the common failure |
Logging | Every action, with the agent identity attached | Otherwise attribution is theoretical |
Review date | Calendar entry, quarterly | Access creeps, and nobody notices |
Offboarding | Documented steps to disable it | Agents outlive the projects that created them |
The spend cap row is the one teams skip and regret. An agent in a retry loop will spend real money quickly and quietly, and the cap needs to sit at the billing layer rather than in the agent's own instructions, for the same reason you do not ask a process to limit itself. The practical setup is in setting spending limits for AI agents.
The trap: one service account for all of them
The usual first attempt is a single account called something like ai-automation, shared by five agents. This solves the human-credential problem and reintroduces every other one at a smaller scale. You cannot tell which agent did what, cannot disable one without disabling five, and end up granting the union of all five permission sets to all of them.
That union effect is the real damage. The document-summarising agent gets the payment agent's write access because they share an account, so a prompt injection in a document now has a path to money. The rule is one identity per agent, where an agent means a distinct job with a distinct permission set, not a distinct process.
Where this is genuinely hard
Three honest obstacles, none of which change the recommendation.
Per-seat pricing. Some SaaS charges for every account, so a dedicated agent identity has a monthly cost. Many vendors have a service or integration account tier; ask before paying for a seat.
Tools with no service account concept. Some products only understand humans. Options are an API key scoped separately, a dedicated low-privilege account that is clearly labelled, or accepting the tool is not agent-ready and keeping a human in the loop for it.
Consumer-grade tools with no permission granularity. If access is all or nothing, a separate identity still buys you attribution and revocation, which is two out of three.
What none of these justify is the agent running as a person. If you can only do one thing, do the separate identity and leave the permission scoping for later.
Questions
Is a service account the same as a user account here?
Functionally yes, and a service account is usually better where the platform offers one, since it typically supports non-interactive authentication and token rotation. The requirement is one identity per agent, whatever the platform calls it.
Should the agent account have multi-factor authentication?
It should not need interactive login at all. Use non-interactive credentials with short lifetimes and automated rotation. If a platform forces a password login, that is a reason to isolate the account further, not a reason to share a human's.
How do I stop an agent account becoming a permanent super-user?
Two things. Start from deny and add specific permissions rather than assigning a role, and put a recurring review in the calendar with a named owner. Permission creep on unowned accounts is the normal outcome, not the exception.
Do I need this for an agent that only reads?
Yes, though the stakes are lower. Read access is still exfiltration surface, and attribution matters when you need to answer what did this thing look at. It is also much easier to provision correctly before the agent gains write access than after.
Where does this sit in the overall risk picture?
It is one of the cheapest controls available, and it is upstream of several others. Our wider survey of the risks worth taking seriously puts it in context alongside prompt injection and data handling, which are the two failure modes a scoped identity most limits the damage from.
How did this land?
About the author
Staff Engineer, Platform
Carlo works on the platform that turns prompts into running apps. He writes the engineering deep dives and the changelog notes worth reading.
