Access exercised by software or an AI agent from a user-controlled device using that user’s identity context or credentials. The security issue is not just execution, but the combination of local artefacts, identity scope, and the device that mediates trust.
What Delegated Access on Endpoint Means in Practice
delegated access on an endpoint is not just “someone logged in on a device.” It is a trust pattern in which software, scripts, or an AI agent operates from a user-controlled endpoint while inheriting or using that user’s identity context, so local device state becomes part of the security boundary.
That matters because the endpoint can hold browser sessions, refresh tokens, cached credentials, SSH material, or other artefacts that make delegation practical and also make compromise easier. When access is delegated, the device is no longer a neutral transport layer, it is part of how authority is expressed and trusted.
Why Endpoint Mediation Changes the Security Model
An endpoint can mediate trust in ways that server-side identity decisions alone cannot see. If a user’s device is healthy, managed, and locked down, delegated access can support convenience and legitimate automation; if the same endpoint is infected, rooted, or exposed to local malware, the attacker may inherit the same session and action surface that the legitimate user enjoys.
This is why delegated access is often discussed alongside user sessions, consent grants, and on-behalf-of flows. The access decision is not only “is this identity allowed?” but also “should this device and local execution context be trusted to exercise that identity right now?” For a deeper identity perspective, see Human vs Non-Human Identity, which frames where people, machine access, and shared credentials meet.
Common Delegation Patterns and Their Security Trade-offs
In practice, delegated access on an endpoint appears in several forms: a browser session reused by a local helper process, an AI assistant acting for a signed-in user, a token exchanged for an on-behalf-of call, or a desktop tool using the user’s existing authentication state. These patterns reduce friction, but they also compress separation between the user, the device, and the actor actually making requests.
The main trade-off is convenience versus containment. The more seamlessly software can act as the user, the harder it becomes to distinguish legitimate delegation from abuse, especially when the same endpoint also stores tokens, consent, or cached identity artefacts. OAuth-based delegation is a common mechanism here, and OAuth Token Exchange and Delegation Guide is useful background for the distinction between delegation and impersonation.
How to Evaluate Whether Delegated Access Is Acceptable
Evaluate delegated access by asking what the endpoint can touch, what identity material it can reuse, and how much authority is being inherited. The key question is not whether delegation is possible, but whether the device, local process, and scope of access are all tightly bounded enough for the risk of misuse to remain acceptable.
That assessment should include session lifetime, device posture, token audience, local malware exposure, and whether the delegated action is reversible or high impact. When the delegated path is too broad, a compromise of the endpoint becomes a compromise of the trust relationship itself. For policy and consent context, Identity Data Privacy and Consent Guide is a useful companion because delegated access often depends on both authorization and consent handling.
Delegated Access and Identity Governance
Delegated access on endpoint is easiest to govern when the organisation can answer three questions clearly: who is acting, on whose authority, and through which device state. That makes it an identity governance problem as much as an endpoint problem, because the access path often combines user identity, device trust, and local artefacts into one operational decision.
For that reason, delegated access should be mapped to the specific flows it enables, not treated as a generic remote-access pattern. In environments where users, helpers, and agents overlap, a good reference point is Customer IAM (CIAM) Guide, which covers delegated and agent access, recovery abuse, and the consent patterns that often sit behind user-mediated access.
Risk and Threat Considerations
Delegated access on an endpoint is risky because the device can become the weakest trust anchor in the chain. If local malware, browser session theft, or token replay succeeds, an attacker may be able to act with the same apparent legitimacy as the user, even if the backend authorization model looks sound.
Failure mechanism: Local compromise captures reusable identity artefacts or hijacks the live session, then uses the endpoint’s trusted context to perform actions on the user’s behalf.
Impact: The result can be unauthorized access, consent abuse, data exposure, privilege misuse, or persistence inside workflows that defenders mistake for legitimate delegated activity.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of credentials and session material used in delegated access. |
| IA-9 — Service Identification and Authentication | Applies when software or agents on the endpoint authenticate using non-human or delegated identities. | |
| AC-6 — Least Privilege | Directly limits what a delegated session can do on the endpoint and after delegation. | |
| Recommendation — Control token and credential lifetime so delegated endpoint sessions expire quickly and can be revoked. Authenticate endpoint-run services with scoped machine credentials rather than broad shared secrets. Restrict delegated sessions to the minimum actions and resources needed for the task. | ||
| OWASP ASVS | V7 — Session Management | Delegated access depends on secure session handling, expiry, and protection from hijack. |
| V10 — OAuth and OIDC | Delegation on endpoint often relies on token exchange, consent, and on-behalf-of flows. | |
| Recommendation — Harden session handling so delegated browser or app sessions cannot be replayed or extended unchecked. Use OAuth and OIDC delegation patterns that bind tokens to the right subject, audience, and scope. | ||
Practitioner Guidance
What to watch for: Treat delegated endpoint access as a bounded trust relationship, not a default convenience feature. The safest implementations keep delegated scope narrow, make token and session lifetimes intentionally short, and distinguish ordinary user action from software- or agent-driven action in logs and approvals.
Practitioner takeaway: If the endpoint can exercise the user’s authority, then endpoint hardening, identity scope, and delegation policy all need to be designed together rather than reviewed separately.
Related resources from NHI Mgmt Group
- How should identity and endpoint teams implement delegated access without creating a single point of failure?
- When does delegated access become too risky for AI agents?
- What is the difference between human delegated access and agentic access?
- How should security teams govern SaaS integrations that hold delegated access?