Accountable identity for AI coding agents depends on user-scoped delegation

At a glance

What this is: This is a product-era identity design analysis showing how an AI coding agent can act on behalf of a human while preserving attribution, scope, and revocation.

Why it matters: It matters because IAM, PAM, and NHI programmes need patterns for agentic access that keep human accountability intact without creating shared credential sprawl.

👉 Read Descope's account of accountable identity for its AI coding agent

Context

AI coding agents change the identity problem because they can take real actions in third-party systems on behalf of a person, not just assist them. In that model, the core question is no longer whether the agent can authenticate, but whether the delegation chain preserves scope, accountability, and revocation across human IAM, NHI controls, and emerging agentic workflows.

Descope’s example is useful because it shows a practical boundary pattern for agentic identity: authenticate the human first, issue a short-lived scoped credential at request time, and ensure the downstream system records who authorised the action. That architecture is relevant wherever agents touch GitHub, SaaS platforms, internal APIs, or other systems that already depend on access governance.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Govern them as delegated identities, not as independent privileged actors. The safest pattern is to authenticate the human first, issue a short-lived scoped token at request time, and bind every action back to the delegating user. That keeps the agent inside the user’s existing permissions and makes review, rollback, and offboarding much clearer.

Q: When does an AI agent become a governance problem instead of a productivity tool?

A: It becomes a governance problem when it can act without a clear human delegation chain or when it relies on shared credentials that outlive the request. At that point, attribution weakens, scope broadens, and revocation becomes manual cleanup. The control question is whether the agent can be stopped everywhere in one action.

Q: What do organisations get wrong about AI agent access control?

A: They often try to manage the agent as if it were a new person or a generic service account. That misses the real issue, which is whether the agent’s authority is inherited from a specific human principal and bounded by that principal’s permissions. Without that model, the access design drifts toward privilege sprawl.

Q: How can teams tell whether agentic identity revocation actually works?

A: A real test is whether removing the human connection immediately removes the agent’s ability to act across every connected system. If any repository, API, or SaaS connection still works after offboarding, the lifecycle control has failed. Effective revocation should leave no orphaned access paths behind.

Technical breakdown

User-scoped OAuth delegation for AI coding agents

The central mechanism is delegated access rather than autonomous possession of privilege. The agent does not hold a shared bot credential. Instead, it requests a short-lived OAuth token tied to the triggering user, with explicit scopes and an expiry that bounds the session. That means the downstream service enforces the user’s own permissions, while the agent simply acts within them. This differs from classic service-account design because the identity boundary is the human grant, not the bot account. The architecture also preserves inspectability because the token grant and the runtime action can be correlated in logs.

Practical implication: treat agent access as delegated user identity, not as a new privileged service account.

Authentication, authorisation, and attribution are separate controls

Agentic identity fails when teams collapse who triggered the agent, what it can do, and how the action is recorded into one control. In this pattern, the front door authenticates the human first, then a separate authorisation step issues scoped access, and finally the audit trail binds the action back to that delegation. This is the right separation because a bot may execute work, but it should never be the only system that knows who asked for it. The result is stronger forensic value and clearer accountability when a generated change must be reviewed or rolled back.

Practical implication: design three distinct checkpoints for agentic workflows, then verify each one independently.

Revocation needs to be immediate and structurally complete

The strongest control in the design is not creation of access but clean removal of it. If the human connection is revoked centrally, the agent immediately loses the ability to act on that person’s behalf across repositories and services. That matters because agentic access often spans multiple third-party systems, and scattered tokens create orphaned privilege. Short-lived credentials reduce exposure, but revocation completeness is what keeps offboarding from becoming a manual cleanup exercise. In practice, this shifts identity governance from token hunting to delegation lifecycle control.

Practical implication: test whether one offboarding action actually removes agent reach everywhere the delegation was used.

NHI Mgmt Group analysis

Agentic identity breaks the assumption that access can be governed without preserving the human delegation chain. The design problem is not simply securing a new kind of bot credential. It is proving who authorised the action, what scope was inherited, and how that delegation can be revoked without residue. Traditional IAM often treats human and non-human access as separate domains, but agentic workflows collapse that separation into one operating model. Practitioners should therefore evaluate whether their identity architecture can preserve the delegation chain end to end.

User-scoped delegation is the right control pattern because it ties agent capability to existing human permissions. That means the agent cannot exceed the authoriser’s own repository or system access, which keeps privilege aligned with the human principal rather than the workflow. This aligns with NIST CSF access control expectations and the broader Zero Trust principle that access should be continuously bounded, not assumed persistent. Practitioners should stop asking whether the agent is powerful enough and start asking whether the authoriser’s scope is the correct ceiling.

Service-account sprawl becomes the wrong default the moment an agent can act on behalf of a person. A shared bot account gives up attribution, broadens privilege, and complicates revocation, which makes it a poor fit for workflows that need accountability. The better pattern is to make the identity provider the place where refresh, expiry, and revocation are managed, not the agent runtime. Practitioners should treat shared bot credentials as a governance debt that compounds as agent adoption expands.

Provable attribution is the named concept that matters here: every agent action must remain traceable to the human who delegated it. That concept is stronger than simple audit logging because it binds identity, scope, and intent into one reviewable record. Without that link, agent output can be technically correct but governance-poor, because no one can confidently answer who authorised the action or under what entitlement. Practitioners should make traceability a design requirement, not a post-incident hope.

Offboarding parity is now a non-negotiable identity property for agentic systems. If removing a human does not automatically remove the agent’s ability to act for them, the lifecycle model is incomplete. This is where identity governance, PAM oversight, and NHI lifecycle discipline converge: the agent must lose access when the human relationship ends. Practitioners should validate revocation behaviour as part of every access review and leaver process.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• For the broader control model, see OWASP Agentic Applications Top 10 for the risks that emerge when agent actions are allowed to drift beyond human review.

What this signals

Identity governance for AI agents is moving from account management to delegation management. As more teams introduce agents that act across SaaS, code, and internal systems, the question becomes whether the authorising human can be traced, the scope can be bounded, and revocation can be executed cleanly. The governance model has to follow the delegation chain, not the bot label. For teams building that model, the Ultimate Guide to NHIs remains the best baseline for lifecycle thinking.

98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, so the control gap is already operational. That combination means the programme risk is not speculative adoption but scale without lifecycle discipline. Teams should expect pressure to prove who authorised each run, what scope was inherited, and whether offboarding removes the agent’s reach everywhere it exists.

Provable attribution is becoming the dividing line between manageable and ungoverned agentic systems. If the identity provider can explain both the human grant and the runtime scope, the audit trail is usable. If it cannot, the organisation inherits a forensics problem as well as an access problem. For teams comparing control patterns, the NIST AI Risk Management Framework provides a useful governance lens even when the implementation is rooted in identity.

For practitioners

• Separate the human trigger from the agent permission grant Require a distinct authentication step for the person invoking the agent, then issue a scoped runtime credential only after that identity is verified. Keep the request identity, the downstream authorisation scope, and the execution logs separately inspectable.
• Eliminate shared bot credentials from agent workflows Do not place broadly scoped service accounts inside agent runtimes. Use user-scoped or tenant-scoped delegation so the downstream system enforces the caller’s ceiling instead of the agent inventing one.
• Make revocation a single control-plane action Test whether one offboarding or access-removal action actually cuts off all third-party reach the agent inherited from that human. If any token, connection, or repository path survives, the lifecycle model is incomplete.
• Log identity provenance alongside agent output Record who authorised the run, which scopes were granted, what tools were invoked, and what system accepted the result. Action logs alone are not sufficient for review, rollback, or accountability.

Key takeaways

• AI coding agents should be governed through delegated human identity, because shared bot credentials destroy attribution and broaden blast radius.
• Short-lived, user-scoped credentials make agent actions auditable and revocable, but only if the identity provider owns refresh and expiry.
• Offboarding is the litmus test: if removing the human does not immediately remove the agent’s reach, the governance model is incomplete.

Key terms

• Delegated Identity: A delegated identity is an access pattern where one principal acts on behalf of another principal under explicit scope and accountability. In agentic systems, the agent should inherit permissions from the human who authorised the task, rather than holding broad standing privilege of its own.
• Scoped Runtime Credential: A scoped runtime credential is a short-lived token or key issued for a specific task, with limited permissions and a defined expiry. It reduces standing exposure by ensuring the agent can only do what the request allows, and only for as long as the delegation remains valid.
• Provable Attribution: Provable attribution means an organisation can tie every action back to the principal who authorised it, with supporting identity and audit evidence. For AI agents, this requires more than action logs. It needs a clear link between the human grant, the token scope, and the executed operation.
• Offboarding Parity: Offboarding parity means removing a human’s access also removes any agent access that depended on that human’s delegation. In practice, the identity lifecycle must close every downstream path the agent used, so revocation is complete rather than partial or manual.

What's in the full article

Descope's full blog post covers the operational detail this post intentionally leaves for the source:

• The GitHub App, GitHub Action, and memory-service flow that makes the agent’s delegated access work end to end.
• The token result structure, including how short-lived OAuth grants are returned, rejected, and logged in runtime.
• The exact offboarding behaviour when a user connection is revoked and the agent loses access across repositories.
• The planned MCP server and policy-engine integration for securing internal tools with the same identity pattern.

👉 Descope's full post covers the identity flow, revocation model, and planned MCP-secured extensions in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.