Run an agent's downstream actions with the requesting user's identity and scope, not with one shared high privilege service account. Then the agent can never do more than the person could, and an injected instruction cannot borrow rights the user never had.
What OWASP recommends
In the excessive agency prevention list, OWASP says to run actions under the individual user's identity and scope, not a generic high privilege account. It pairs that with enforcing authorization in downstream systems instead of relying on the model.
The problem with a shared account
A shared service account makes the agent as powerful as the account, for every user, whatever they asked for. Three things go wrong.
- A user can get access they should not have, by asking the agent to fetch it.
- A prompt injection that reaches the agent inherits the account's full rights.
- Logs show the service account, so you cannot tell who triggered an action.
The last point links to the MCP security notes on audit trails, where blurred identities make investigation harder.
Building the per user path
- Authenticate the user to your application as usual.
- When the agent needs a downstream call, obtain a token for that user and that downstream service, using OAuth rather than a stored password. If the agent is acting for the user, a delegation style token keeps the agent visible too.
- Make the downstream system enforce its own authorization on that token.
- Request only the scopes the specific task needs, and elevate when needed.
- Keep tokens short lived, and do not log them.
For MCP servers, the authorization specification supports this shape. The server validates tokens issued for it, and uses a separate token issued by the upstream authorization server when calling upstream.
When a service account is still fine
Some jobs belong to no user, such as a scheduled report or a nightly scan. Use a dedicated identity for each such agent with the narrowest rights for that job. Avoid one account shared across many agents.
A migration checklist
- List every agent and the credential it uses.
- Mark where one credential is used for many users or many agents.
- Replace the highest risk ones first, which are those with write access.
- Test that a low privilege user cannot use the agent to read what they could not read directly.
Questions to ask a vendor or a platform team
- When the agent calls a downstream system, whose identity does that system see?
- Can a user cause the agent to read something the user cannot read directly?
- Are agent actions distinguishable from human actions in the downstream log?
- How are tokens stored, and how long do they live?
Clear answers to these four tell you most of what you need. Vague answers usually mean a shared account sits behind the scenes.
Where Safeguard fits
Safeguard includes agent identity and policies that help you give agents their own identities and constrain what they do. The per user token path in your own applications is still yours to implement.
Quick check
Is per user access slower to build than a service account?
Usually, yes, at first. The payoff is that the agent cannot exceed the user's rights and your logs show who acted.
Sources
Last reviewed: 19 October 2026.
