Notifications
Clear all
Topic starter
24/06/2026 8:42 pm
TL;DR: Engineering-led automation and AI-assisted development are pushing access decisions beyond the assumptions built into standard IAM and IGA tools, according to Opal Security. The governance gap is no longer about reviewing static access; it is about explaining, bounding, and auditing identities that emerge inside workflows and change with runtime behaviour.
NHIMG editorial — based on content published by Opal Security: Back's Next Chapter, a conversation with CEO Howard Ting
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map workflow-generated access paths Identify where repositories, CI/CD jobs, cloud roles, and internal services create access automatically.
- 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.
- 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.
What's in the full article
Opal Security's full article covers the operational detail this post intentionally leaves for the source:
- Howard Ting’s own account of how engineering workflows are changing access expectations inside fast-growing organisations.
- His perspective on how Opal models humans, services, and agents in one framework rather than treating them separately.
- The product and operating assumptions behind access being explainable, time-bound, and tied to real usage.
- The leadership priorities he sets out for scaling the platform as customers adopt more automation and AI-driven development.
👉 Read Opal Security's conversation on identity governance for AI coding agents →
AI coding agents and identity governance: what changes for teams?
Explore further
25/06/2026 5:26 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Identity governance for AI coding agents is outgrowing legacy IAM
