Per-user OAuth identity means each AI action is executed under the authenticated user’s own account, not a shared service identity. This preserves native access controls, supports auditability, and prevents an agent from inheriting broader permissions than the person or workload behind the request.
Expanded Definition
Per-user OAuth identity is an execution pattern in which an AI agent or automated workflow acts with the authenticated user’s OAuth grant, rather than with a shared application token or service account. In practical NHI governance, that means the agent inherits only the scopes and consent that the user has explicitly approved, preserving native access boundaries and making downstream actions attributable to a person. This model is closely related to delegated authorization in NIST SP 800-53 Rev 5 Security and Privacy Controls, but it is not the same as blanket delegation across all systems because OAuth scopes, refresh behavior, and consent lifecycles still constrain what the agent can do. Definitions vary across vendors on whether a “per-user” model includes long-lived refresh tokens or requires short-lived, step-up authorized access, so governance teams should document the exact trust boundary. The most common misapplication is treating a shared OAuth client as if it were per-user identity, which occurs when multiple users’ actions are routed through one broad token and audit trails collapse into a single principal.
Examples and Use Cases
Implementing per-user OAuth identity rigorously often introduces consent and token-lifecycle overhead, requiring organisations to weigh finer-grained attribution against more complex revocation and monitoring.
- An AI scheduling assistant books meetings in the user’s calendar only after the user signs in and grants calendar-specific scopes, rather than using a department-wide mailbox token.
- A sales copilot reads CRM records and drafts updates under the salesperson’s identity, so field-level access rules and record ownership still apply.
- A support agent automates ticket lookups with the analyst’s OAuth grant, which keeps customer data access tied to the person handling the case.
- An enterprise app integrates with Microsoft 365 through a user-consented OAuth flow, reducing the risk of a shared connector overreaching beyond intended access. See the NHIMG analysis of the Microsoft OAuth Breach for a real-world example of token abuse.
- Security teams compare per-user consent patterns against OAuth guidance in RFC 6749 when deciding whether an agent needs delegated access or a separate service principal.
When organisations review app sprawl, the Ultimate Guide to NHIs is useful for framing lifecycle controls around offboarding, rotation, and visibility. Per-user identity is also central in incidents like the Salesloft OAuth token breach, where token misuse turned delegated access into broad exposure.
Why It Matters in NHI Security
Per-user OAuth identity matters because it limits how far an AI agent can move if a token is stolen, mis-scoped, or reused outside the intended workflow. It also improves auditability by tying each action to a specific user context, which is critical when reviewing access to sensitive systems, customer records, or code repositories. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and another 47% only partial visibility, making identity attribution and consent governance especially important. That visibility gap is echoed in the broader NHI landscape, where only 5.7% of organisations have full visibility into service accounts according to the Ultimate Guide to NHIs. Per-user OAuth identity should be paired with strong token hygiene, consent reviews, and scoped monitoring, as recommended by NIST SP 800-53 Rev 5 Security and Privacy Controls. Organisations typically encounter the operational need for this model only after a compromised token or overbroad app permission exposes data, at which point per-user OAuth identity becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Per-user OAuth depends on tight secret and token handling to prevent shared-identity overreach. |
| NIST SP 800-63 | User-authenticated delegation relies on assurance in the human identity session and its binding to the OAuth grant. | |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication underpin whether delegated user identity is trustworthy. |
| NIST Zero Trust (SP 800-207) | PA-1 | Zero Trust requires each access decision to be explicitly authenticated and authorized per request. |
| OWASP Agentic AI Top 10 | A1 | Agentic systems often fail when identity delegation is ambiguous or overly broad. |
Bind each agent action to scoped, user-consented credentials and review token storage and rotation regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
