Notifications
Clear all
Topic starter
06/07/2026 9:35 am
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.
NHIMG editorial — based on content published by Descope: How We Built Accountable Identity for Shuni, Our AI Coding Agent
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Eliminate shared bot credentials from agent workflows Do not place broadly scoped service accounts inside agent runtimes.
- 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.
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.
👉 Read Descope's account of accountable identity for its AI coding agent →
AI coding agents and delegated identity: what IAM teams need to know?
Explore further
06/07/2026 9:50 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Accountable identity for AI coding agents depends on user-scoped delegation
