--- source_url: "https://www.darkreading.com/identity-access-management-security/ai-agents-new-kind-identity-most-organizations-not-ready" title: "AI Agents Are a New Kind of Identity — and Most Orgs Aren't Ready" mirrored_at: 2026-08-14T13:04:33.684Z host: www.darkreading.com cited_in_42a: true mirror_canonical: "https://index.42a.ai/www.darkreading.com/identity-access-management-security/ai-agents-new-kind-identity-most-organizations-not-ready" --- > **Original source:** https://www.darkreading.com/identity-access-management-security/ai-agents-new-kind-identity-most-organizations-not-ready 6 Min Read ![hand typing on keyboard with agentic AI icons on screen](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt64d615142d7be882/6882572f618f869f048e5227/Agentic_AI_\(1800\)_Pattara_Alamy.jpg?width=1280&auto=webp&quality=80&disable=upscale "hand typing on keyboard with agentic AI icons on screen") Source: Pattara via Alamy Stock Photo COMMENTARY I recently read an opinion piece on TechTarget by Todd Thiemann, a principal analyst at Omdia, on [identity security for AI agents](https://www.techtarget.com/searchsecurity/opinion/Identity-security-for-AI-agents-The-proliferation-challenge). It is one of the clearest articlesI have read on this topic. But it also made me think about something that I want to dig into further because it's the most important factor in enterprise security right now, and it's not getting the attention it deserves: the development environment. Thiemann makes a point that I have been making for a while now, and it's worth repeating loudly: AI agents are not just another type of nonhuman identity. They are fundamentally different. If you're still treating them like a service account or an API token, you are already behind. ## A Distinction That Changes Everything Think about every nonhuman identity you have ever had to manage. A service account. An API token. A bot. They all have one thing in common: You tell them what to do, and they do it. Consistently, predictably, and within defined boundaries. Related:[Cyera's Oasis Security Buy is All About AI Agent Control](https://www.darkreading.com/identity-access-management-security/cyera-oasis-security-acquisition-ai-agent-control) AI agents don't work that way. They are given a goal, and they figure out how to get there. They make decisions along the way. They adapt. And they don't stop at 5 p.m. They are running while your team is asleep, touching repositories, triggering pipelines, opening pull requests, and, in some cases, merging and deploying code, all without a human watching or audit trail that tells you what happened. That is not a variation of the service account problem; it's a fundamentally different class of risk. And it requires a fundamentally different approach to governance. AI agents are identities. They need to be provisioned, monitored, governed, and deprovisioned just like any human or nonhuman developer identity. The difference is that they operate at a speed and scale that breaks every governance model we have built to date. That isn't a reason to treat them differently. It's a reason to govern them better. AI agents are nonhuman identities with superhuman capabilities. That combination requires a governance approach that borrows from what we do for humans and what we do for machines, and then goes further than both. The governance models we built for human developers assumed human speed and human judgment. The models we built for nonhuman identities assumed deterministic, bounded behavior. AI agents break both assumptions simultaneously. That's why most security tools were simply not built to see them, let alone govern them. ## The SDLC Blind Spot The research is clear: Every organization has an average of 22 distinct AI agent projects, spanning IT, legal, compliance, sales, and more. That's a lot of autonomous activity with a lot of unanswered questions about who is governing it. Related:[USA Fencing Lunges Into the Hidden Identity Challenge in Amateur Sports](https://www.darkreading.com/identity-access-management-security/usa-fencing-hidden-identity-challenge-amateur-sports) And while AI agents are showing up everywhere across the enterprise, the development environment is where they are most embedded, most autonomous, and, in my view, most ungoverned right now. That is the conversation I want to have. We need to be clear about what is really happening inside engineering teams today because there are two very different types of AI in play, and they carry very different risk profiles. Most organizations are now in the coding-assistant phase. GitHub Copilot, Cursor, and Claude help developers write faster, suggest better code, and catch issues earlier. Humans are still in the loop. The developer writes, the AI suggests, and the developer decides. That is one risk profile, and most security teams are at least beginning to think about the implications. Autonomous agents are a different story entirely. These agents write code, run tests, open pull requests, approve merges, and trigger pipeline deployments, sometimes without a single human reviewing what they did. Not every organization is here yet, but this is where we are heading, and it's happening faster than most security and governance teams are prepared for. Related:[Flaws in Passkey Implementation Show Old Attacks Still Work](https://www.darkreading.com/identity-access-management-security/flaws-passkeys-implementation-old-attacks-work) Here is what I find most striking about both scenarios: Security teams are worried about vulnerable code getting through, which is a legitimate concern. But the questions most organizations cannot answer are more fundamental: Which AI agent introduced the code? What did it have access to? Was there a human anywhere in that loop? The code is the symptom. The ungoverned AI identity behind it is the cause. And without knowing the cause, you are patching symptoms forever. The gap is not just about malicious activity. In most environments we look at, what we find is not malicious. It's just ungoverned, and being ungoverned is the risk. ## What You Actually Need Omdia's Thiemann outlines four core capabilities for AI agent identity security, and they map directly to what we see organizations struggling with in the development environment. - You need to know every AI agent operating in your environment—not just the ones you approved. All of them. The ones your developers spun up on personal accounts, the ones nobody reviewed, the ones that have been quietly accumulating access for months. - You need to know what these agents can access and what they have used. You need behavioral baselines so you know what normal looks like and can spot when something has gone wrong. And you need life cycle controls so that when a project ends, the access ends with it. None of this is new thinking. We've been applying these principles to human identities for years. AI agents in the development environment are still new territory, and the frameworks to govern them are still catching up. That is just where we are. The organizations that start building that foundation now will be well ahead of the curve. ## Why This Is Urgent Right Now The capabilities being developed and released in the AI space are advancing faster than most security and engineering teams can absorb. Tools that can find vulnerabilities at machine speed across entire codebases are already in the hands of the largest enterprises. That is not a future scenario; it's the present. Here is the question worth sitting with: If something went wrong in your development environment today (such as an unauthorized change, a vulnerability introduced by an AI agent, or a pipeline triggered without approval), could you reconstruct exactly what happened, which identity was responsible, and whether a human was involved? This isn't hypothetical. Auditors and regulators have been asking for a version of it for over 20 years under the Sarbanes-Oxley Act and other frameworks. What's new is that AI agents have made it exponentially harder to answer. The audit trail that compliance teams depend on simply does not exist for most AI agent activity today. The issue isn't whether your development environment has exposure. It almost certainly does. You need to know who and what introduced it, whether you have the foundation to act on it proactively, and whether you can demonstrate control to the people who will eventually ask. Most organizations are not there yet, but the window to get ahead of it is open right now. ## The Opportunity Thiemann ends his piece by noting that identity teams have historically had the reputation of being Team No. The opportunity now is to be Team Yes, to build the governance foundation that lets AI adoption accelerate safely rather than becoming the reason it stalls. Here is some important context: Identity teams have traditionally focused at the enterprise level, on single sign-on, access management, and provisioning. The development environment — with all its complexity, developer identities, nonhuman identities, AI agents, and CI/CD pipelines — has largely been outside their scope. The opportunity Thiemann describes is really one for security and engineering teams to own together. They understand the development environment. They see the risk every day. And when they work together with the right foundation beneath them, governance stops being a blocker and starts being what makes safe AI adoption possible. If you don't know what your AI agents can access inside your development environment, you aren't ready for what is coming. ## About the Author VP of Strategy, BlueFlag Security Mora is a veteran cybersecurity professional with a strong track record in technology strategy and go-to-market execution. She’s led global initiatives and built high performing teams across leaders in markets including cloud security, identity and software development. She was instrumental in creating the Cloud Infrastructure Entitlement Management (CIEM) category at CloudKnox Security, leading the company’s product positioning that was integral in its acquisition by Microsoft. Mora most recently led product initiatives at Laminar Security, where her product leadership helped to drive the company's acquisition by Rubrik. She also held security product and marketing roles at Orca Security, Hytrust, Juniper and CA.