Notifications
Clear all
Topic starter
06/06/2026 1:52 am
TL;DR: AI native engineering teams can move faster, but the shift also exposes identity sprawl, shadow access, and weaker visibility into who or what is acting on behalf of the organisation, according to Oasis Security. The governance break is that static roles and periodic reviews assume stable identities, while AI-native workflows create dynamic access paths that outpace them.
NHIMG editorial — based on content published by Oasis Security: Building an AI Native Engineering Organization: Lessons in Speed, Culture, and Security
Questions worth separating out
A: Security teams should govern AI native environments by treating every identity as dynamic and continuously verifiable.
Q: Why do AI native workflows create more identity risk than traditional engineering models?
A: AI native workflows increase identity risk because they multiply the number of identities and shorten the time access remains stable.
Q: What breaks when access reviews are used for ephemeral machine identities?
A: Access reviews break down when identities are created and used faster than the review cycle can observe them.
Practitioner guidance
- Build continuous identity discovery across delivery pipelines Inventory every human, service, and agent identity that can touch code, prompts, deployments, or data.
- Map access to live workflow context Tie entitlements to current task state, deployment stage, and runtime behaviour instead of relying only on role assignments.
- Automate drift detection for machine-speed change Monitor for new permissions, new integrations, and sudden usage spikes, then trigger controls before access proliferates across prompts and pipelines.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How the team reworked engineering workflows around an AI native IDE and changed collaboration patterns across product, UX, and engineering.
- The specific identity and security questions the organisation could no longer answer once tools, services, and agents became more fluid.
- The four capabilities the author says are required for governance in high-velocity environments, including identity discovery and drift detection.
- The leadership lessons behind the transition, including what broke when speed outpaced visibility.
👉 Read Oasis Security's analysis of AI native engineering, speed, and security →
AI native engineering: what it means for IAM and security controls?
Explore further
06/06/2026 3:14 am
AI native engineering turns identity from a support function into the primary control surface. When workflows become more fluid, the question is no longer whether security exists, but whether identity governance can keep pace with the pace of work. The strongest programmes will treat every identity as dynamic, whether human, machine, or agent, and anchor control decisions in real-time context rather than static assumptions. Practitioners should expect identity to become the organising layer for security in AI-native delivery.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: How can teams tell whether identity controls are keeping up with AI native change?
A: Teams can tell by measuring whether they can answer who acted, what they accessed, and whether the access still matched the task in real time. If those answers depend on manual reconstruction after the fact, the control model is behind the operating model. Drift, shadow access, and ownership gaps are the warning signs.
👉 Read our full editorial: AI native engineering exposes identity sprawl and access control gaps
