AI agents are operating inside development environments at most organizations without governance, audit trails, or clear ownership-and they represent a fundamentally different class of identity risk than anything security teams have managed before. New research shows an average of 22 distinct AI agent projects per organization spanning IT, legal, compliance, and sales, yet most companies cannot answer basic questions about what these agents can access or whether a human reviewed their actions.
If you are still treating AI agents like a service account or an API token, you are already behind. These agents are given a goal and they figure out how to get there-making decisions, adapting, and touching repositories, triggering pipelines, opening pull requests, and in some cases merging and deploying code without a human watching or an audit trail that tells you what happened.
"AI agents are non-human identities with superhuman capabilities," according to analysis from BlueFlag Security. That combination requires a governance approach that borrows from what organizations do for humans and what they do for machines, and then goes further than both.
Two kinds of AI, two risk profiles
Most organizations are in the coding assistant phase. Tools like GitHub Copilot, Cursor, and Claude help developers write faster and suggest better code. Humans stay in the loop-the developer writes, the AI suggests, the developer decides. Security teams are beginning to think through the implications of this model, and the risk profile is relatively contained.
Autonomous agents are a different story. These agents write code, run tests, open pull requests, approve merges, and trigger pipeline deployments, sometimes without a single human reviewing what they did. The shift toward AI Agents & Automation at this level is happening faster than most security and governance teams are prepared for. Not every organization is here yet, but this is where things are heading.
The most striking gap is not about vulnerable code getting through-though that concern is legitimate. 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.
What governance actually requires
Organizations need to know every AI agent operating in their environment-not just the approved ones. That includes agents developers spun up on personal accounts, the ones nobody reviewed, and the ones that have been quietly accumulating access for months. They need visibility into what these agents can access and what they have actually used. Behavioral baselines are necessary to spot when something has gone wrong. And lifecycle controls must ensure that when a project ends, the access ends with it.
None of this is new thinking. These principles have been applied to human identities for years. AI agents in the development environment are still new territory, and the frameworks to govern them are catching up. The organizations that start building that foundation now will be well ahead of the curve.
The compliance gap
The capabilities being 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. 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?
Auditors and regulators have been asking a version of that question for over 20 years under the Sarbanes-Oxley Act and other frameworks. 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 is not whether your development environment has exposure-it almost certainly does. The question is whether you have the foundation to act on it proactively and demonstrate control to the people who will eventually ask.
Security and engineering teams-who understand the development environment and see the risk every day-have an opportunity to own this problem together. AI for IT & Development governance stops being a blocker and starts being what makes safe AI adoption possible when the right foundation is underneath it.
Why this matters for management
Most security tools were not built to see AI agents, let alone govern them. The governance models built for human developers assumed human speed and human judgment. The models built for non-human identities assumed deterministic, bounded behavior. AI agents break both assumptions simultaneously. For managers overseeing engineering, security, or compliance functions, the immediate priority is closing the visibility gap-knowing what AI agents exist in your environment, what they can access, and whether a human is in the decision loop. Without that foundation, every code vulnerability, every unauthorized change, and every audit finding will trace back to an identity you cannot see.
Your membership also unlocks:
