Identity governance for AI coding agents is outgrowing legacy IAM

At a glance

What this is: Opal Security’s conversation with its new CEO argues that identity governance now has to handle cloud roles, services, and AI coding agents as first-class access subjects.

Why it matters: IAM, IGA, PAM, and NHI programmes now need a common governance model for humans, services, and agentic workflows because the access boundary is changing inside engineering operations.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Opal Security's conversation on identity governance for AI coding agents

Context

Identity governance is being pulled into engineering workflows that generate access continuously rather than at a single provisioning moment. That shift matters because standard IAM and IGA models assume stable identities, slower change, and cleaner approval boundaries than modern cloud and AI-assisted development actually produce.

In practice, this is no longer just a human access problem. Cloud roles, internal services, SaaS entitlements, and AI coding agents now sit in the same operational path, which means governance teams need to reason about human IAM, NHI control, and emerging agentic behaviour together rather than as separate stacks.

The article reflects a typical pattern for fast-growing engineering-heavy organisations: access complexity is rising faster than governance workflows were designed to absorb. That makes the issue less about tool selection and more about whether the organisation can explain and audit access as it is being created inside production-adjacent systems.

Key questions

Q: How should security teams govern AI coding agents that can interact with production systems?

A: Treat the agent as an access subject, not just a productivity feature. Define who owns it, what systems it may reach, what actions it can trigger, and how those actions are logged and reviewed. If the agent can change code or infrastructure, it needs identity governance boundaries before broad deployment.

Q: Why do standard IAM and IGA tools struggle in engineering-heavy environments?

A: They assume access is requested, approved, and reviewed through slower workflows than modern engineering actually uses. Automation, infrastructure as code, and AI-assisted development create permissions inside runtime paths, which makes static role logic and periodic certification too blunt to capture the real control state.

Q: What do security teams get wrong about AI agents and access control?

A: They often treat the agent as a tool layered onto existing IAM. In practice, once an agent reads repositories, updates infrastructure, or triggers workflows, it can create and consume access in ways that require ownership, auditability, and scope control. The governance model has to match that behaviour.

Q: Who should be accountable for access created by automation and AI-assisted development?

A: Accountability should sit with the team that deploys and operates the workflow, not with a generic platform owner alone. When access is created by code, pipelines, or agent-driven actions, the organisation needs a named owner who can explain the access path, its duration, and its business purpose.

Technical breakdown

Why standard IAM breaks in engineering workflows

Traditional IAM and IGA were built around relatively static identities, ticket-based requests, and periodic review cycles. Engineering environments behave differently because infrastructure as code, ephemeral cloud roles, and automated build or deployment paths can create access as part of normal execution. That means the governing object is no longer just a person with a role assignment. It is often a system-generated permission path that appears, is used, and may disappear within a short operational window. The key technical problem is not visibility alone. It is that the access event is embedded in the workflow itself, so control points must understand the runtime context that created it.

Practical implication: inventory where access is created by code or automation, not by manual request flow, and treat those paths as governance-critical.

How AI coding agents change access governance

AI coding agents alter the identity problem because they can interact with repositories, infrastructure, and downstream workflows as part of ordinary development. Even when they are not fully autonomous in the strict sense, they can still generate new access paths, consume secrets, and trigger actions that were previously tied to named human operators. That creates a governance challenge around ownership, scope, and auditability. The important distinction is between a tool that assists a person and a workflow component that can exercise access in ways the team did not explicitly enumerate at design time. Existing IAM models struggle when the subject of governance is a semi-structured operational actor inside the engineering toolchain.

Practical implication: define ownership, scope, and audit expectations for every coding agent before it is allowed into repositories or deployment paths.

Explainable, time-bound access as the new control baseline

The article points toward a more precise access model where permissions need to be explainable, time-bound, tied to real usage, and informed by risk. Those attributes are becoming baseline requirements because static access grants create too much uncertainty in environments where identities multiply quickly. In governance terms, this shifts control quality from approval alone to verifiability. Teams need to know why access exists, when it should expire, what behaviour justifies continuation, and how it is observed in operation. That is a stronger standard than legacy role assignment and is especially relevant for NHI and engineering-adjacent access paths.

Practical implication: align access decisions to expiry, usage evidence, and business justification rather than relying on standing grants and periodic clean-up.

NHI Mgmt Group analysis

Legacy IAM assumptions are colliding with engineering reality. Standard access governance was built for slower-moving human workflows, not for environments where automation, cloud roles, and AI-assisted development can generate permissions inside the work itself. That mismatch means the control model is increasingly out of phase with how access is actually created and consumed. Practitioners should treat engineering workflow access as a distinct governance plane, not a variant of the old ticket-and-review model.

Explainable access is becoming the real governance test. The article signals a shift from approving access once to defending access continuously through context, usage, and risk. That is a materially different operating model for IAM and IGA teams because the question is no longer only who asked for access, but whether the access path still makes sense in runtime. Practitioners need to re-evaluate how much of their programme depends on static entitlement logic versus behaviour-aware controls.

AI coding agents are governed as access subjects, not just tools. Once an agent can read repositories, modify infrastructure, or trigger workflows, it participates in identity governance even if the organisation still describes it as productivity software. That puts ownership, scope, and auditability at the centre of the control model. The practitioner conclusion is straightforward: if a system can exercise access, it belongs in identity governance.

Identity governance is moving from workflow compliance to operational trust. The article’s core message is that organisations now need governance that fits directly into engineering execution, not governance that interrupts it after the fact. This is where NHI, human IAM, and emerging agentic use cases converge. The field should expect more programmes to collapse access review, auditability, and runtime policy into one operating layer rather than three separate processes.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Use Top 10 NHI Issues to connect this access problem to the broader governance and lifecycle controls that engineering teams usually inherit too late.

What this signals

Access governance is shifting from review cadence to runtime proof. Engineering teams that still depend on periodic certification will miss the access events that are now being generated inside automation and AI-assisted workflows. The practical signal is that identity programmes need evidence from execution, not just approval artefacts, and they need it before the workflow becomes production critical.

AI coding agents expand the surface area of NHI-style governance. As more engineering tasks are delegated to systems that can touch repositories and infrastructure, the line between human access and machine access becomes operationally thin. Teams should expect more pressure to unify service identities, cloud permissions, and agent-driven access in one control view rather than maintaining separate exceptions.

The governance issue is no longer whether an identity is human or non-human in a narrow taxonomy. It is whether the organisation can explain and expire access that emerges at runtime, especially when development velocity is high and the workflow itself is the source of privilege creation.

For practitioners

• Map workflow-generated access paths Identify where repositories, CI/CD jobs, cloud roles, and internal services create access automatically. Flag any path that bypasses normal approval and review flows so it can be governed as an identity issue rather than a tooling side effect.
• Assign explicit ownership to AI coding agents Require a named business and technical owner for every coding agent that can read code, update infrastructure, or trigger workflows. Ownership should include scope boundaries, logging expectations, and an approval path for expansion.
• Move from standing grants to expiring access Replace persistent access where possible with time-bound permissions tied to real usage and a documented reason for continuation. Use renewal logic that depends on current need, not historical convenience.
• Review engineering-adjacent identities in one governance model Bring cloud roles, service identities, SaaS entitlements, and AI-assisted development accounts into the same recertification and audit process so teams can compare them under one policy standard.

Key takeaways

• Identity governance is moving into engineering workflows where permissions are created dynamically and are harder to review after the fact.
• AI coding agents are not merely tools in the access model; they are governance subjects once they can read, change, or trigger systems.
• Teams need expiring, explainable, usage-backed access decisions if they want IAM and IGA to keep pace with modern development.

Key terms

• Engineering workflow identity: An identity created or exercised inside development, build, deployment, or infrastructure workflows rather than through a separate access request process. It can be human or non-human, but the governance challenge is the same: the workflow itself is generating privilege, so review must account for runtime context as well as assignment.
• AI coding agent: A software actor that can read code, modify infrastructure, or trigger workflow actions as part of development work. In governance terms, it behaves like a non-human identity when it can exercise access, so ownership, scope, logging, and expiration need to be defined before broad use.
• Explainable access: Access that can be justified in plain terms and linked to a current operational need. In mature identity programmes, explainability means the organisation can show why the access exists, who owns it, how long it should remain valid, and what evidence supports continuation.
• Time-bound privilege: Privilege that expires after a defined period or task instead of remaining in place indefinitely. This matters in modern engineering and NHI governance because standing access becomes hard to defend when automation creates and uses permissions inside short-lived workflows.

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 governance maturity, it is worth exploring.

This post draws on content published by Opal Security: Back's Next Chapter, a conversation with CEO Howard Ting. Read the original.