Use user sign in, the authorization code flow, when the agent acts for a person and should be limited to that person's access. Use client credentials only when the agent is a service acting on its own behalf, with its own narrow scopes. OWASP advises running agent tools in the user's context where possible.
The two patterns
With user delegated access, a person signs in and approves scopes. The token represents that person and the agent together, so the downstream system can apply the person's permissions and log their name.
With client credentials, the agent authenticates as itself. There is no person in the flow. The token represents the agent only, and whatever the agent is allowed to do, it can do for anyone who triggers it.
The MCP authorization draft mentions both. It says clients acting on behalf of a user should attempt step up authorization when a scope is missing, while clients acting on their own behalf using client credentials may attempt step up or abort immediately.
Decision table
| Situation | Better fit | Why |
|---|---|---|
| Assistant reads a user's mail or files | User sign in | Must respect that user's access |
| Coding agent opens pull requests for a developer | User sign in | Attribution to the person |
| Scheduled job that rebuilds a report | Client credentials | No person present |
| Shared bot answering team questions from public data | Client credentials | Data is not user specific |
| Agent that changes production settings | User sign in plus approval | Needs a named accountable person |
Why OWASP leans toward the user
Among its excessive agency controls, OWASP says to execute extensions in the user's context, acting for the specific user with least privilege and user scoped authentication. A shared agent identity with broad rights turns every user into a user of the strongest account, which is the setup behind confused deputy problems.
If you must use client credentials
- Give the agent its own identity, never a human account.
- Use the smallest scope set that supports the job.
- Keep tokens short lived and store secrets in a vault.
- Log the triggering user on your side, since the token will not name them.
- Add approval for destructive actions.
- Use one identity per agent and per environment.
A mixed design
Many systems need both. A background job can use client credentials to read public data, and switch to user delegated tokens before touching anything personal. Token exchange can carry both the person and the agent in one token, which another post here explains.
Safeguard includes agent identity, which records which agent holds what access, and policies, gates and guardrails. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is client credentials less secure?
Not by itself. The risk is the breadth of access and the lack of a person in the log, so scope narrowly and record who triggered each action.
Can an agent hold both kinds of token?
Yes, as long as each is used for the right job and neither is passed through to systems it was not issued for.
Sources
Last reviewed: 19 October 2026.
