AI coding agents are changing engineering roles and identity control

At a glance

What this is: This is WorkOS’s summary of Boris Cherny’s view that AI coding tools are shifting engineers from writing code to orchestrating agent loops, with major productivity gains and role changes.

Why it matters: It matters because AI-assisted engineering introduces agentic behaviour into software delivery, forcing IAM, PAM, and lifecycle controls to account for tool use, delegated actions, and accountability across human and non-human actors.

By the numbers:

• 200%.

👉 Read WorkOS’s summary of Boris Cherny’s Claude Code interview

Context

AI coding tools are no longer just productivity aids. In this case, the primary shift is from individual code authoring to agent orchestration, which changes how engineering work is controlled, reviewed, and attributed across human and non-human participants.

For identity teams, that matters because the control point moves upstream. Access, approval, and accountability are no longer limited to the person typing code, but extend to the workflows, prompts, and delegated actions that shape what the AI system can do next.

Key questions

Q: How should teams govern AI-assisted development workflows that use coding agents?

A: Treat them as identity-governed execution paths, not just productivity tools. Define who can start the workflow, which tools and data sources it can reach, what evidence is required for review, and how access is revoked if the workflow expands beyond its intended scope. The key is to govern the chain of delegated action, not only the final code output.

Q: Why do AI coding agents increase the blast radius of developer access?

A: Because a single developer account can now trigger fast, iterative actions across repositories, build systems, and internal data sources. That multiplies the effect of each entitlement and makes over-permissioned access more consequential. The practical risk is not that the agent replaces the developer, but that it amplifies what the developer’s credentials can reach.

Q: What do identity teams get wrong about AI coding tools and autonomy?

A: They often treat any AI-powered workflow as autonomous when many are still bounded automation. The real question is whether the system can independently choose actions, tools, and timing without approval. If it cannot, the governance focus should stay on NHI controls, workflow boundaries, and accountability rather than assuming full agent autonomy.

Q: How should organisations adjust access reviews for AI-assisted engineering?

A: Access reviews should look beyond the human role title and inspect the effective permissions behind the workflow. That includes secrets, build permissions, data access, and any service accounts used by the tooling. Reviews should answer whether the combined human-plus-tool path still matches the task being performed.

Technical breakdown

Agent orchestration changes the control plane for software delivery

When engineers stop acting as the sole authors of code and start coordinating loops that prompt an AI system, the effective control plane shifts from manual editing to workflow design. The important question becomes not just who can commit code, but who can initiate, scope, and constrain the sequence of actions an agent may take. That creates a governance layer around prompts, tool access, and execution context, even when the underlying model is not autonomous in the strict identity sense.

Practical implication: Treat AI-assisted development workflows as governed execution paths, not simple productivity features.

Code generation at scale increases the need for identity-aware review

If a large share of code is produced with AI assistance, then review, attribution, and change management need to account for machine-generated output and delegated action chains. Traditional engineering controls assume a human author with a clear intent trail. In agent-heavy workflows, intent may be distributed across a user, a prompt, a tool, and a model response, which complicates accountability and makes access boundaries more important than ever.

Practical implication: Tie code review and deployment approvals to the identities and tools involved in generation, not just the final commit author.

AI-assisted engineering still depends on NHI governance

AI coding tools usually sit on top of service credentials, API access, and workspace permissions, which makes them a non-human identity problem even before they become an autonomy problem. The governance challenge is to distinguish bounded automation from true runtime autonomy, then apply the right controls to each. That distinction matters because a workflow that can invoke tools on behalf of a developer is already expanding the blast radius of that developer's access.

Practical implication: Inventory the secrets, tokens, and service accounts that support AI coding workflows and govern them as NHIs.

NHI Mgmt Group analysis

Agent-assisted engineering is becoming an identity governance problem before it becomes an autonomy problem. The article describes engineers moving from direct coding to writing loops that delegate work to Claude Code, which means the real control surface is now the workflow around the model. That changes access, approval, and accountability even if the system is not fully autonomous. Practitioners should treat these environments as governed NHI-enabled execution paths.

The assumption that one human equals one bounded development action is already breaking down. That assumption was designed for individual contributors whose intent, tools, and timing were visible in normal development workflows. It fails when one engineer can trigger iterative AI-driven work that expands across code generation, data lookup, and product iteration inside a single operating loop. The implication is that identity programmes need to re-evaluate where accountability actually resides in agent-mediated delivery.

AI coding tools widen the identity blast radius of ordinary developer permissions. A developer with access to repositories, build systems, and data sources can now use an AI workflow to exercise those permissions at greater speed and scale than a manual workflow. That does not mean the tool is autonomous, but it does mean the practical impact of a compromised developer identity is larger. The practitioner conclusion is that least privilege must be applied to the workflow, not only to the person.

Runtime governance gap: organisations are adding AI to engineering faster than they are defining who controls the agents, the prompts, and the connected credentials. The article’s core signal is not that engineers will disappear, but that roles will fragment across scoping, prompting, review, and orchestration. That fragmentation creates governance blind spots across IAM, PAM, and NHI lifecycle controls. Practitioners should expect current approval chains to lag behind the way AI-assisted teams actually work.

Generalist operating models will intensify pressure on identity lifecycle processes. When one person can scope work, query systems, build interfaces, and ship changes with AI assistance, role boundaries become less stable and access reviews become harder to interpret. The governance challenge is not job title change alone, but the way delegated technical capability expands the meaning of each role. Practitioners should prepare for broader entitlement reviews and tighter separation between human authority and machine execution.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot confidently map the identities supporting AI-assisted workflows.
• For a broader baseline, read the Ultimate Guide to NHIs for lifecycle, rotation, and visibility guidance that applies directly to machine-mediated engineering.

What this signals

Runtime governance gap: as AI-assisted engineering becomes normal, identity teams will need to govern the workflow as a first-class access surface. The practical challenge is not only whether a person is authorised, but whether the prompts, tools, and credentials behind the workflow are appropriately scoped and reviewable.

The teams most exposed will be those that still separate IAM, PAM, and developer productivity into different operating models. AI coding agents collapse those boundaries, so governance needs to follow the actual execution chain rather than the org chart.

With 97% of NHIs carrying excessive privileges, the likelihood of over-broad access in AI-assisted development is not a corner case. The reader takeaway is to inventory the hidden machine identities behind development workflows before they become the easiest path to unreviewed change.

For practitioners

• Map AI-assisted development workflows as identity-bearing systems Document which prompts, tools, repositories, build systems, and data sources are touched when engineers use AI coding agents. Identify where human approval ends and machine execution begins, then assign an owner for each step in the chain.
• Review developer entitlements for workflow blast radius Limit the permissions that AI-assisted workflows can reach through a developer account, especially access to source control, CI/CD, secrets, and production-adjacent data. Treat broad developer access as a multiplier when paired with delegated agent loops.
• Separate human review from machine generation in change management Require teams to distinguish between the person accountable for the change and the system that generated or transformed the code. Preserve traceability for prompts, tool calls, and delegated actions so review evidence survives beyond the final commit.
• Inventory secrets used by coding agents Identify every token, API key, and service account that supports AI coding workflows, then decide whether those credentials belong in short-lived, task-scoped access or need stronger containment. This is especially important where agents can query internal systems or generate deployment-ready output.

Key takeaways

• AI coding agents are changing engineering work from direct authoring to delegated orchestration, which expands the identity surface that IAM and PAM must govern.
• Productivity gains do not remove governance risk. They increase the need to control prompts, tools, secrets, and review paths around machine-assisted work.
• Identity teams should review the workflow, not just the user, because the real blast radius sits in the permissions and credentials the workflow can reach.

Key terms

• Agent orchestration: The coordination of prompts, tools, and execution steps so an AI system can complete work on behalf of a human. In engineering workflows, it shifts control from direct manual editing to managing the sequence and scope of delegated actions.
• Identity blast radius: The amount of damage that can follow from a single identity being over-permissioned or misused. In AI-assisted engineering, the blast radius grows when one developer account can drive repositories, build systems, data sources, and credentials through delegated workflows.
• Workflow-bound access: Access that is limited by the task flow rather than by a static role alone. This matters for AI-assisted work because the effective privileges are defined by the connected tools, credentials, and review gates that the workflow can reach.

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.

This post draws on content published by WorkOS: key takeaways from Boris Cherny on building Claude Code. Read the original.