Informa TechTarget | SearchSecurity Cybersecurity Dive InformationWeek Channel Dive Explore our brands Dark Reading Resource Library Black Hat News Omdia Cybersecurity Advertise NEWSLETTER SIGN-UP Cybersecurity Topics World The Edge DR Technology Events Resources IDENTITY & ACCESS MANAGEMENT SECURITY СLOUD SECURITY APPLICATION SECURITY COMMENTARY News, news analysis, and commentary on the latest trends in cybersecurity technology. AI Agents Are a New Kind of Identity & Most Organizations Aren't Ready If you're handling them like a service account or API token, consider yourself behind. AI agents need a fundamentally different approach. Mora Gozani,VP of Strategy,BlueFlag Security July 9, 2026 6 Min Read 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. It is one of the clearest things I 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 non-human identity. They are fundamentally different. If you're still treating them like a service account or an API token, you are already behind. LOADING... A Distinction That Changes Everything Think about every non-human 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:Cisco Adds NHI to Security Stack With Astrix, WideField Acquisitions 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 non-human 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 non-human 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 non-human 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. An average of 22 distinct AI agent projects per organization, 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:Google API Keys Remain Active After Deletion 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, Claude: tools that 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 things are heading, and it's happening faster than most security and governance teams are prepared for. Related:AI Agents Are Shifting Identity Security Budget Dynamics 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, and 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 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( an unauthorized change, a vulnerability introduced by an AI agent, 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 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, single sign-on, access management, provisioning. The development environment with all its complexity, developer identities, non-human identities, AI agents, 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 underneath 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 Mora Gozani 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. Want more Dark Reading stories in your Google search results? ADD US NOW More Insights Industry Reports The State of Cloud Security: The Latest Challenges The total economic impact™ of Snyk How Organizations Are Managing Incident Response How Enterprises Are Developing Secure Applications I