Use separate policies for autonomous and user-steered modes, because the acceptable privilege set changes with context. A client_credentials flow should usually carry narrower authority than a user-backed authorization_code flow. The control objective is to prevent the same client from inheriting broad rights simply because it can operate in more than one mode.
Why one client needs two authorization profiles
The security question is not whether the client is trusted in the abstract, but what it is allowed to do in each mode. A client acting autonomously should usually be constrained to the minimum it needs for unattended work, while the same client acting with a user present can inherit only the rights that user is entitled to delegate. Treating those modes as equivalent creates privilege creep.
That distinction matters because the OAuth 2.0 authorization framework supports very different trust assumptions depending on how the client is obtaining access. A machine-to-machine flow is normally a client-only relationship, while a user-backed flow expresses a delegated human context. Security teams should model those as separate access cases, even if the same software component initiates both.
The practical outcome is simple: policy should be keyed to mode, not just to client name. That means the autonomy path and the user-present path should each have their own policy decision, token scope expectations, and review criteria.
What changes between client_credentials and authorization_code
The access model changes because the authority source changes. In a client_credentials flow, the client is authenticating as itself, so the privilege boundary should be narrow and service-specific. In an authorization_code flow, the client is carrying delegated user authority, so the acceptable scope can be broader only to the extent the user context justifies it. This is why a single broad token policy is usually the wrong abstraction.
That difference becomes more visible when you consider scope and audience control. The client should not be able to reuse a user-backed grant as a blanket excuse for machine-wide access, and it should not be able to escalate a user-present session into unattended autonomy without a fresh policy check. The token should reflect the mode that produced it, not the most permissive mode the client can ever enter.
For teams standardizing OAuth behavior, the RFC on resource indicators is useful because it reinforces audience restriction, while mutual-TLS client authentication and certificate-bound access tokens can help bind a client to the right runtime and reduce token reuse across contexts. Where stronger client assertion is needed, the JWT client authentication profile is another way to tighten how the autonomous mode proves itself.
How to keep a dual-mode client from becoming overprivileged
The governance pattern is to separate identity, policy, and approval logic by operating mode. That can mean distinct scopes, distinct audiences, distinct consent records, or even distinct registered client identities where the blast radius would otherwise be too large. If the same client can operate with and without a human, the safer design is to require the system to ask, on every authorization decision, which mode it is in and what authority is legitimate in that mode.
This is where AI Agent Authorisation Guide is a useful navigation point for least-privilege, task-scoped access, and per-action decisions when a client behaves like an agent. The same principle appears in Zero Trust for AI Agents, which emphasizes verifying the principal and request rather than trusting the client’s general reputation. When the client can switch modes, policy must follow the mode switch, not ignore it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Dual-mode clients need minimal rights in autonomous operation. |
| IA-5 — Authenticator Management | Mode-specific access depends on managing credentials and tokens by lifecycle and scope. | |
| AC-16 — Security and Privacy Attributes | Mode, user presence, and delegation context are attributes that should drive authorization decisions. | |
| Recommendation — Limit each client mode to the minimum permissions needed for that context. Bind token and credential handling to the operating mode and rotate or revoke unused secrets. Use contextual attributes such as mode and delegation state in authorization decisions. | ||
Practitioner Guidance
What to verify: Confirm that autonomous and user-backed sessions produce different tokens, scopes, or policy outcomes, and that a user-present grant cannot be silently reused for unattended operation.
Decision rule: If the action can still succeed without a human present, treat it as autonomous and keep the default privilege envelope narrow; only broaden access when the user context is real, current, and explicitly evaluated.
Common mistake: Registering one client and then letting operational convenience blur two different authority models. That usually turns a reasonable delegation design into a standing-privilege problem.
What good looks like: Each mode has a distinct access posture, a clear audit trail, and an authorization decision that can explain why the granted authority matched the mode at the time.
Practitioner takeaway: The client is not the policy unit, the operating mode is. If the mode changes, the authorization boundary must change with it.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org