A delegated client is an application or platform that performs actions on behalf of a user after receiving permission. In this context, ChatGPT acts as a delegated client, which means governance must cover consent, token scope, and revocation across the full access path.
Expanded Definition
A delegated client is an application or platform that performs actions on behalf of a user after receiving permission. In NHI governance, the distinction is not the front-end app itself, but the authority it can exercise through tokens, consent grants, and downstream API calls. That makes delegated clients materially different from autonomous agents, which may initiate work without a user present, and from service accounts, which usually act under machine-owned privileges.
Definitions vary across vendors when “delegated client” is used loosely to describe any app with API access, but in security practice the term should be reserved for a user-consented actor with a bounded authorization context. The relevant control question is whether the delegated client can only do what the user explicitly allowed, for how long, and in which resource boundaries. This aligns closely with NIST Cybersecurity Framework 2.0 principles around access governance and continuous risk management, even when the implementation sits in OAuth or another authorization layer.
The most common misapplication is treating delegated access as equivalent to standing administrative access, which occurs when organisations ignore scope limits and consent expiry.
Examples and Use Cases
Implementing delegated client controls rigorously often introduces friction in user experience and application chaining, requiring organisations to weigh convenience against tighter consent and revocation handling.
- A collaboration app posts calendar updates on a user’s behalf after the user grants scoped access to read and write only calendar events, not mail or contacts.
- An AI assistant uses a delegated client pattern to draft messages and file tickets, but only within the user’s approved mailbox and service desk scope.
- A procurement portal calls a downstream ERP API with user-bound authorization, making sure the token cannot be reused for unrelated financial records.
- A SaaS integration is revoked when a user leaves the organisation, demonstrating why lifecycle management matters as much as initial consent.
- Research into real-world NHI failures shows how unchecked delegated pathways can become execution paths, as seen in the Gemini CLI Breach — Silent Code Execution, where tool-enabled access created security consequences beyond ordinary user intent.
OAuth-style delegated access is the most common technical model, and its security posture is strongly influenced by guidance in the NIST Cybersecurity Framework 2.0 around authorization, monitoring, and response.
Why It Matters in NHI Security
Delegated clients become an NHI concern because they often inherit trust from a human without inheriting the same review, challenge, and revocation discipline. When scopes are too broad, tokens live too long, or consent is never revalidated, the delegated client effectively becomes a durable identity path that attackers can abuse after a phishing event, token theft, or app compromise. This is especially dangerous in AI-enabled workflows, where a delegated client may be linked to tool use, inbox access, file systems, or SaaS automation.
NHI Mgmt Group research shows that 91.6% of secrets remain valid five days after an organisation is notified, and that lag is equally concerning for delegated tokens and grants because revocation delay extends exposure. The same body of research also shows that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong warning signal for delegated access lifecycle control. In practice, delegated clients should be governed as first-class NHI assets with auditability, expiry, and rapid withdrawal, not as a one-time app permission. The associated risk is discussed in NHI governance guidance from NHI Mgmt Group and reinforced by incident patterns in Gemini CLI Breach — Silent Code Execution.
Organisations typically encounter delegated client abuse only after a token leaks or a user loses access, at which point consent review and revocation become 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 CSF 2.0, NIST SP 800-63 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-01 | Delegated clients depend on scoped authorization and consent, a core NHI governance concern. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access authorization principles apply to user-consented delegated access. |
| NIST SP 800-63 | AAL2 | Assurance requirements help bound how much trust a delegated client should inherit. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero Trust requires continuous authorization of downstream access paths used by delegated clients. |
| OWASP Agentic AI Top 10 | A2 | Agentic and tool-enabled clients can exceed intended user authority if controls are weak. |
Verify delegated access is explicitly authorized, monitored, and removable across its lifecycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
