Topic starter
27/08/2025 10:25 am
As enterprises accelerate toward an AI-native future, engineering organizations are undergoing one of the most profound transformations since the rise of DevOps. Traditional development models—built on rigid handoffs, static roles, and manual governance, are breaking down. In their place, teams are adopting AI-native engineering practices that prioritize speed, autonomy, and collaboration between humans and AI agents.
This shift unlocks enormous productivity gains but also creates new risks around identity sprawl, access control, and security posture. Without new guardrails, the same systems that drive autonomy can quickly erode visibility and trust.
What Does “AI-Native” Engineering Mean?
An AI-native engineering organization doesn’t simply add AI tools on top of existing workflows. Instead, it redesigns processes around AI as an embedded partner.
Key characteristics include:
- AI-embedded development - Teams use AI-native IDEs to accelerate coding, reviews, and architectural planning.
- Integrated collaboration - Design, product, and engineering work in parallel, with AI systems turning prototypes into code and prompts into design components.
- Outcome-driven metrics - Traditional measures like story points or cycle time are replaced with clarity-focused metrics—such as time to ramp into a domain, reliability of AI outputs, and speed to resolution.
This represents a cultural reset: AI is no longer an assistant but a core participant in the software loop.
The Challenge: Speed Without Losing Security
The move to AI-native development exposes critical weaknesses in legacy identity and access models. As AI agents spin up services, deploy code, and connect to APIs autonomously, organizations face questions they can’t always answer:
- Who owns a specific deployment, an engineer or an AI agent?
- Is a credential being passed through a prompt?
- Is this integration reviewed or is it shadow access?
- Are dormant or orphaned identities still active?
Static roles, quarterly access reviews, and centralized IAM cannot keep up with ephemeral identities and non-deterministic workflows. The result is a growing visibility gap and expanded attack surface.
Four Pillars of a Modern Identity and Security Model
To secure AI-native engineering without slowing it down, organizations must adopt an identity-first security model built on continuous governance. Four core capabilities define this model:
- Comprehensive identity discovery - Detect and catalog every identity, human, service account, CI/CD job, or AI agent—across all environments.
- Context-aware access mapping - Understand what each identity can access, and whether that access aligns with its actual behavior.
- Automated drift detection - Continuously monitor changes in permissions, usage, and anomalies in real time.
- Policy-driven governance - Replace static permissions with dynamic, policy-based access controls that enforce least privilege automatically.
This approach ensures organizations can move at AI speed without sacrificing control or auditability.
Key Lessons for AI-Native Teams
Organizations building AI-native engineering capabilities should learn from early adopters:
- Don’t retrofit AI into broken processes—redesign the process from the ground up.
- Empower teams, but establish adaptive guardrails that evolve with workflows.
- Treat every identity—human or non-human—as dynamic and governable.
- Prioritize visibility across the entire access chain, from user instruction to agent execution.
- Make security part of the system itself, not an afterthought layered on top.
Final Takeaway
Building an AI-native engineering organization is as much about culture and governance as it is about tools. It demands a rethink of how teams collaborate, how identities are secured, and how risks are managed in real time.
The organizations that succeed will balance speed with control by adopting identity-first, policy-driven, AI-aware security practices. Those that wait risk ceding control to opaque, unmonitored AI agents, turning velocity into vulnerability.
06/10/2026 9:35 pm
AI agent governance fails when organisations keep applying human lifecycle assumptions to non-human executors. Human IAM assumes stable ownership, predictable approval flows, and a clean offboarding event. The article shows that an agent can create, use, and abandon NHIs within the same operational arc, which means the lifecycle boundary itself has shifted. The implication is that governance must be anchored to execution behaviour, not to employee-style administration.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
- Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
A question worth separating out:
Q: What is the difference between AI agent governance and traditional IAM?
A: Traditional IAM focuses on human users and static entitlements, while AI agent governance must handle autonomous execution, tool access, and rapidly changing context. The difference is operational as much as technical. AI agents can keep acting after the original task ends, so teams need continuous controls, not just periodic access reviews.
👉 Read our full editorial: AI agent governance is colliding with non-human identity sprawl