TL;DR: An AI coding agent can stay accountable when every action is tied to the human who triggered it, using short-lived user-scoped OAuth grants instead of shared bot credentials, according to Descope. That breaks the assumption that agent access can be governed like static service accounts and pushes identity teams toward delegation-first design.
At a glance
What this is: This Descope article explains how its AI coding agent uses user-scoped OAuth delegation, short-lived tokens, and revocation to keep each action attributable to the human who triggered it.
Why it matters: IAM teams need this pattern because AI coding agents blur human and non-human access unless delegation, attribution, and offboarding are built into the identity layer from the start.
Context
AI coding agents create a delegation problem, not just an automation problem. The identity question is who can invoke the agent, whose permissions it uses, and how the system preserves accountability after the action is taken.
Descope frames its internal coding agent around that gap: if an agent acts in third-party systems on behalf of users, the user-scoped grant becomes the control point. That matters for NHI governance because the agent is not the principal in isolation; it is a delegated executor whose scope should inherit from a real human identity.
The article argues that shared bot accounts, user PATs, and per-user service principals each fail in different ways. The central design issue is whether identity can remain attributable, revocable, and least-privileged when the agent operates across GitHub, MCP tools, and memory services.
Key questions
Q: What breaks when AI agents are connected through personal accounts or shared credentials?
A: Shared or personal credentials break accountability, lifecycle control, and revocation. If an agent inherits a human account, security teams lose clean ownership and cannot reliably attest what the identity can do or when it should be disabled. That creates an unmanaged backdoor into systems that may persist after the original setup is forgotten.
Q: Why do user-scoped OAuth grants improve accountability for AI agents?
A: They keep the human principal inside the delegation chain, so every action can be traced to the person who authorised it. That matters because the agent is only acting within a live grant, not as an independent identity. The result is cleaner auditability, narrower scope, and faster revocation when access must end.
Q: When should security teams choose delegation over long-lived service accounts for agents?
A: Choose delegation when the agent acts on behalf of a person, the required permissions vary by request, or immediate offboarding matters. Long-lived service accounts are better suited to stable machine tasks with fixed scope. For AI coding agents, the article shows that request-time delegation is the safer governance model.
Q: How should IAM teams govern AI coding agents across GitHub, MCP tools, and other systems?
A: Govern them as delegated executors, not as standalone users. That means proving the human at invocation, issuing only the scopes needed for that run, logging both the grant and the action, and revoking the connection when access should end. The control objective is accountability across the entire delegation chain.
Technical breakdown
User-scoped delegation for AI coding agents
The core mechanism is delegated identity: the agent does not own a standing credential, it requests a short-lived token tied to the human who triggered the run. In this model, authentication answers who invoked the agent, while authorization answers what that person is allowed to do in the downstream system. That separation matters because the token, not the agent runtime, becomes the proof of intent and the boundary for scope. The result is closer to federated action than machine autonomy. The agent can push commits, open pull requests, or comment, but only inside the permissions inherited from the user grant.
Practical implication: design agent access so every downstream action is issued from a user-scoped grant, not from a shared machine identity.
Why shared bot accounts and personal tokens fail
A shared bot account erases provenance, so every action looks the same regardless of who initiated it. A personal token stored inside the agent preserves attribution, but it turns a human credential into a long-lived secret inside an autonomous workflow. That raises blast radius because compromise of the token exposes the user’s full permissions. The article’s middle ground is to keep the credential outside the agent runtime and fetch it at request time. That preserves traceability without turning the agent into a secret vault.
Practical implication: eliminate both shared bot credentials and cached personal tokens from agent workflows.
Revocation and offboarding as an identity control
Revocation is built into the delegation model itself. When a user’s connection is removed, the agent loses the ability to act for that person across every connected service without hunting for orphaned accounts or rotating multiple secrets. That is a governance advantage because offboarding becomes a single identity event rather than a cleanup project across systems. It also narrows the window in which a departed employee or stale delegation can keep producing valid agent actions. In practice, lifecycle management becomes part of the control plane, not an afterthought.
Practical implication: treat user connection revocation as the primary offboarding control for delegated agents.
Threat narrative
Attacker objective: The attacker objective in this pattern would be to make agent actions look legitimate while expanding the usable scope beyond the rightful human delegation.
- Entry occurs when a user invokes the agent through an authenticated GitHub interaction, so the system must prove who is asking before any work begins.
- Credential access happens when Descope returns a short-lived GitHub OAuth token tied to that user instead of storing a reusable bot secret inside the agent.
- Escalation is prevented by scope inheritance, because the agent can only act within the permissions already granted to the human principal.
- Impact is controlled through revocation, because removing the user connection immediately cuts off the agent’s ability to act on that person’s behalf.
Breaches seen in the wild
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
- PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Delegation-first identity is the right baseline for AI coding agents: The article shows that the agent is not the principal, the human is. That distinction matters because accountability collapses when the system treats an agent as a standalone account instead of a delegated executor. The practical conclusion is that identity architecture must preserve the human principal through every downstream action.
Static service-account thinking breaks for agentic workflows: The assumption that a credential can be provisioned once and reused safely was designed for stable machine identities, not for agents that act on behalf of different users across different sessions. That assumption fails when scope must vary per invocation and revocation must be immediate. The implication is that governance must move from persistent identity to request-time delegation.
Short-lived grants are an accountability mechanism, not just a security hygiene measure: If every action is tied to a live OAuth grant, attribution, revocation, and least privilege become structural properties rather than policy aspirations. That is why user-scoped delegation matters more than whether the agent is labelled autonomous or assisted. Practitioners should evaluate agent identity by how tightly the action trail follows the human trigger.
Agent identity and human identity now need one governance model: Traditional IAM separates people and machines too cleanly for this use case. The article shows a hybrid reality where a human delegates and a non-human executor acts, but the control objective remains the same: preserve accountability, constrain scope, and make offboarding decisive. IAM teams should treat that as a single lifecycle problem.
Identity blast radius is the concept this article sharpens: The dangerous unit is no longer the account itself, but how far an agent can act before the delegation ends. When a user-scoped grant is the boundary, blast radius shrinks to the permissions already held by the human rather than the agent accumulating its own reach. That framing should guide agent governance reviews.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Authorisation Guide
What this signals
Identity blast radius is the useful planning concept here: AI coding agents should not be measured by how much they can do, but by how far their delegated reach extends before the grant expires or is revoked. For IAM and PAM teams, that makes issuance time and offboarding time the two places where control really matters.
The article also shows why agent governance cannot be bolted onto human IAM after the fact. If authentication, scope issuance, audit logging, and revocation are not designed as one chain, the organisation gets either weak attribution or excessive standing access, and neither outcome is acceptable for third-party actions.
For practitioners
- Adopt user-scoped delegation for agent runs Tie each agent action to the human who triggered it and fetch downstream credentials only at request time.
- Remove shared bot credentials from agent workflows Do not let the agent hold a reusable bot account, cached PAT, or other standing credential that outlives the invocation.
- Separate authentication from authorization checks Verify who invoked the agent before deciding what the agent is allowed to do in GitHub, MCP tools, or other third-party systems.
- Build offboarding around connection revocation Make revoking the user connection the single step that removes the agent’s ability to act for that person across every connected service.
Key takeaways
- This article shows that accountable AI coding agents depend on delegation that keeps the human principal visible at every step.
- Its central governance lesson is that shared bot accounts and stored personal tokens both create avoidable identity risk.
- The control that matters most is request-time issuance plus immediate revocation, because those two points define the agent’s effective blast radius.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on authenticating who may invoke the agent and tying action to that identity. |
| NHI-05 — Overprivileged NHI | The article rejects shared bot accounts and broad standing credentials for the agent. | |
| NHI-07 — Long-Lived Secrets | The article explicitly prefers short-lived tokens over stored reusable credentials inside the agent. | |
| Recommendation — Require authenticated invocation for every agent run and reject unauthorised trigger attempts. Constrain agent permissions to the exact user grant and remove standing overprivilege. Replace long-lived agent secrets with request-time credentials that expire after the run. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article addresses how an agent can abuse delegated privilege if identity is not bound tightly. |
| Recommendation — Bind agent actions to the delegated human identity and prevent privilege drift across runs. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is fundamentally about scoped entitlement and authorisation for agent actions. |
| Recommendation — Apply scoped authorisation so each agent request inherits only the permissions the user already has. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived token handling and revocation map directly to authenticator lifecycle governance. |
| Recommendation — Manage agent authenticators as short-lived issuances with immediate revocation when access ends. | ||
Key terms
- User-Scoped Delegation: A control model where an agent acts using a credential tied to the human who triggered the request. The agent inherits only that person’s downstream permissions, so accountability, scope, and revocation follow the user rather than a shared machine account.
- Delegated Executor: A non-human actor that performs work on behalf of a person or organisation without becoming the ultimate identity principal. In agentic systems, the executor can act only within the rights borrowed for a specific run, which makes attribution and offboarding part of identity design.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Request-Time Credential Issuance: A pattern in which credentials are created or retrieved only when a task begins, then expire shortly after use. For agents, this avoids caching reusable secrets in runtime and shifts control to the identity provider, where scope and lifecycle are easier to govern.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org