TL;DR: Claude Code has moved from writing 10% to over 90% of code for its team, while new-hire ramp-up fell from weeks to about two days, according to WorkOS’s summary of Boris Cherny’s Acquired Unplugged interview. The shift matters because engineering work is moving from direct authoring to orchestrating agent loops, which changes how identity, access, and accountability need to be governed.
At a glance
What this is: This is WorkOS’s summary of Boris Cherny’s view that AI coding agents are reshaping engineering from hands-on coding to workflow orchestration, with major changes in productivity and team structure.
Why it matters: For IAM and identity leaders, the article shows how AI coding agents change who initiates work, which actions are delegated, and where accountability and access boundaries need to be governed.
By the numbers:
- Per-engineer productivity increased 200% after adopting Claude Code internally.
Context
AI coding agents are changing engineering because they move work from manual authoring into delegated execution loops. In practical terms, the identity question is no longer only who can edit the codebase, but what the agent is allowed to do, when it may do it, and how that activity is attributed.
WorkOS summarises Boris Cherny’s account of Claude Code as a phase change, not a simple productivity boost. The broader governance implication is that engineering teams now need controls for agent-initiated actions, scoped access, and reviewable delegation chains, not just human developer permissions.
For AI-assisted software delivery, the central gap is accountability across a workflow that may be partially human and partially machine-driven. That makes identity governance, access policy, and change control part of the engineering operating model rather than a separate security concern.
Key questions
Q: What breaks when AI coding agents inherit a developer’s identity?
A: The main failure is that the agent is no longer operating as a separate principal. It can reach whatever the developer can reach, which collapses segmentation, attribution, and least-privilege assumptions. Security teams lose the ability to treat the model as a bounded tool, because its practical access is defined by the human session it inhabits.
Q: Why do AI agents change infrastructure identity governance?
A: AI agents change the model because they can take actions, call tools, and operate without a human approving each step. That means the identity is no longer just a credential holder. It becomes an execution authority that needs explicit scope, continuous monitoring, and a clean revocation path when behaviour drifts.
Q: How should security teams set access boundaries for AI agents?
A: Security teams should define agent boundaries around data sources, tools, and allowed actions before any production rollout. The boundary must be explicit enough to block unintended combinations of access, because agent value often comes from chaining capabilities across systems. Treat the boundary as a runtime control, not just a policy document.
Q: What should teams do when code is generated by an AI agent rather than a person?
A: Require traceability from prompt to merge. Teams should know who initiated the task, what context the agent used, which tools it touched, and what human review happened before the change was accepted. That evidence becomes essential when the same workflow can generate large amounts of code quickly and repeatedly.
Technical breakdown
Agentic coding loops and delegated execution
Claude Code in this account is not just a suggestion engine. Cherny describes writing loops that prompt the agent and decide what to build next, which shifts the human role from direct code author to orchestration layer. That matters because the meaningful control point moves from line-by-line authorisation to the permissions and context granted to the loop itself. When an agent can repeatedly act inside a development workflow, identity governance has to account for the session, the toolchain, and the scope of each delegated step, not only the user behind the keyboard.
Practical implication: Treat agent-driven development as a delegated execution problem and govern the loop, not just the developer account.
Identity control for AI-assisted software delivery
In AI-coded workflows, the control question is which credentials, repositories, build systems, and production-adjacent tools the agent can touch. That is classic non-human identity territory even when the human still supervises outcomes. The risk is not only overbroad access, but also ambiguous attribution when the same task may span prompts, tool calls, and human review. For identity teams, the interesting shift is that least privilege has to be expressed for the agent’s operating context, while the human keeps ownership of policy and approval boundaries.
Practical implication: Model AI coding agents as NHIs with their own entitlements, logging, and lifecycle controls.
Engineering productivity and control drift
The article links faster delivery, shorter ramp-up, and a larger engineering org to the same underlying pattern: software work becomes easier to scale when the agent absorbs context and repetitive action. That also creates control drift if organisations assume human workflows still apply. Traditional review cadences, onboarding assumptions, and code ownership models were built around slower, person-to-person work. Once an agent can answer codebase questions and generate changes on demand, governance has to keep pace with machine-mediated development rather than human throughput alone.
Practical implication: Re-check code review, onboarding, and access review assumptions against agent-paced delivery cycles.
Threat narrative
Attacker objective: To exploit delegated coding workflows and use trusted AI-assisted development paths to produce unauthorised or unsafe changes at scale.
- Entry occurs through legitimate developer access to the coding environment and the AI toolchain that the team already trusts.
- Credential or scope abuse can follow if the agent inherits broad repository, issue, or build permissions beyond the immediate task.
- Impact emerges when machine-generated changes, feedback loops, or unsafe outputs move too quickly for normal human review to catch.
Breaches seen in the wild
- Code Formatting Tools Credential Leaks: Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI coding agents turn development access into a delegated execution model: The important governance shift is not that developers are writing faster, but that an identity can now request, modify, and assemble work through a repeated agent loop. That breaks the old assumption that access is exercised directly and visibly by a human in a single interaction. Practitioners should now treat the coding environment as a governed delegation chain, not a person-only workstation.
Least privilege becomes harder to define when the executor is a loop rather than a user: A human developer can be assigned a role around expected tasks, but an agent can be reprompted, re-scoped, and re-used across tasks in ways that blur the intended boundary. The result is identity blast radius, where the real exposure is not one commit but the cumulative permissions embedded in the workflow. That is why the permission model has to follow execution context, not job title.
Engineering lifecycle governance now extends to non-human identities: Onboarding, offboarding, access review, and change accountability all start to change once code creation is partially automated. The same governance discipline used for service accounts applies here, but the operating model must include prompt context, tool access, and review evidence. Teams that keep treating AI coding agents as a productivity feature will miss the fact that they are also an identity surface.
Golden-age-of-the-generalist narratives should not obscure control concentration: WorkOS highlights broader role flexibility, but the security consequence is that fewer people may be able to do more through a single agent-mediated workflow. That concentrates operational power inside the tooling layer and increases the importance of logging, scoped access, and traceable approvals. The practitioner takeaway is to govern agent-mediated leverage as carefully as privileged human access.
AI-assisted development introduces trust debt faster than organisations can review it: When an agent can learn a codebase, generate changes, and answer questions about the system, the review burden shifts from creating code to validating what the agent assembled. That is a different control problem from conventional automation because the output is adaptive, not fixed. Teams need to recognise that this is not just a tooling upgrade, but a new identity and assurance boundary.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: AI Coding Agents Security Guide
What this signals
Governance teams should expect the review model to move closer to issuance time and further away from periodic access recertification. When an agent can create and modify code inside a short feedback loop, the important question is not whether access existed, but whether the delegated scope was narrow enough for that loop.
Delegated execution debt: AI coding agents create a new control burden where the organisation must account for what the agent was allowed to do, not only what the human intended. That means access review, offboarding, and audit evidence need to follow the agent lifecycle as much as the developer lifecycle.
The practical effect is that engineering, IAM, and security operations can no longer treat code assistants as a simple productivity layer. They now sit inside the identity plane, which makes scoped permissions, traceability, and review discipline part of software delivery governance.
For practitioners
- Define agent-specific access boundaries Separate the permissions needed for prompt execution, repository access, build actions, and release-related tooling so the agent does not inherit a human developer’s full operating range.
- Record prompt-to-change accountability Capture which human requested the work, which agent executed it, which tools were used, and what review occurred before merge or deployment.
- Review identity assumptions in onboarding and offboarding Ensure AI coding agents have explicit lifecycle ownership, disabled credentials, and revocation paths rather than being left as invisible standing collaborators.
- Limit agent access to task-scoped repositories and services Use task-scoped entitlements for code, tickets, and build systems so the agent cannot drift into unrelated environments or privileged paths.
- Rework code review for machine-generated changes Require stronger review evidence for agent-generated code in sensitive paths, including security-critical modules, secrets handling, and deployment pipelines.
Key takeaways
- AI coding agents shift engineering from direct authoring to orchestrated execution, which changes where identity controls need to sit.
- The article links agent-assisted development to faster onboarding, higher productivity, and a larger engineering organisation, showing why governance pressure increases as adoption grows.
- The control that matters most is task-scoped delegation with clear traceability from human request to machine-generated change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on AI coding agents inheriting and exercising developer-like privileges. |
| Recommendation — Constrain agent identity and privilege to the minimum scope needed for each coding task. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agentic coding workflows create non-human identities that can inherit excessive access. |
| NHI-10 — Human Use of NHI | The article shows humans directing tools that execute work on their behalf, creating delegated identity risk. | |
| Recommendation — Inventory AI coding agents as NHIs and remove any standing permissions beyond task scope. Track which human requested each agent action and preserve approval evidence for the resulting change. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Agent-driven workflows can widen access paths and increase the blast radius of privileged credentials. |
| Recommendation — Map agent-enabled development paths to credential access and lateral movement risks in your detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about changing access boundaries around AI-assisted engineering work. |
| Recommendation — Reassess entitlements for AI coding agents under PR.AA-05 and separate write, build, and release access. | ||
Key terms
- Agentic Loop: The execution cycle where an AI agent interprets a goal, chooses actions, calls tools, observes results, and continues until the task is complete. In governance terms, the loop matters because authority is exercised repeatedly at runtime, not just at initial approval.
- Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
- 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.
- Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 20, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org