You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 5 minutes
Key takeaways:
- 81% of teams give AI-coding agents write access; only 7% keep it read-only. That’s what Shai-Hulud exploited.
- Nearly a quarter reuse human credentials for agents, only 7% manage agent identity properly.
- AI security policies are rising, but core controls (rotation, monitoring, revocation) remain rare.
The recent Shai-Hulud campaign, a self-propagating malicious software program, targeted an increasingly common part of the software development workflow: AI-coding assistants.
Microsoft’s analysis of the campaign showed attackers compromising the configuration files used by tools such as Claude Code to spread malicious instructions between developer environments. That’s a consequence of how AI-coding agents are evolving. They’re no longer limited to suggesting code; they’re increasingly trusted to modify it, execute commands, and work directly inside local development environments.
New data from LeadDev’s forthcoming AI Impact Report 2026, set to be released later this month, suggests many organizations are embracing that autonomy without comparable guardrails. Developers are giving AI agents permission to change code and interact with business systems before deciding how those identities should be managed.
More like this
The permissions already exist
Shai-Hulud is unlikely to be the last campaign to abuse AI-coding tools because the underlying conditions already exist inside many engineering organizations.
LeadDev’s survey found that 81% of respondents say their AI tools or agents have write access to code repositories, while 60% say those tools can modify cloud-based productivity and collaboration platforms. A third report write access to email, while more than a quarter say agents can interact directly with cloud infrastructure.
Only 7% say their agents operate with read-only access.
Those numbers reflect how engineering teams are using AI today. The goal isn’t simply to generate code suggestions anymore. Increasingly, organizations want agents that can make changes, update documentation, execute commands, and handle repetitive development work with minimal supervision.
Those same permissions also create new opportunities for attackers. If a compromised agent already has the ability to modify code or interact with trusted systems, an attacker doesn’t necessarily need to compromise the repository itself. Compromising the workflow around it may be enough.
That’s what makes campaigns like Shai-Hulud notable. Rather than attacking source code directly, they target the systems developers increasingly rely on to produce it.
The AI agent governance gap
Powerful permissions aren’t unusual in software engineering. Organizations have long managed service accounts, CI/CD pipelines, and other non-human identities with privileged access.
AI-coding agents introduce a different challenge because they increasingly operate much like developers while often inheriting developer privileges.
According to LeadDev’s forthcoming report, only 7% of organizations use a dedicated platform to manage non-human identities, while another 6% have built their own internal systems. A quarter say they haven’t addressed agent identity and access management (IAM) at all.
Reusing developer credentials is also common. Almost a quarter of respondents say agents use the same credentials and access controls as human developers. If one of those agents is compromised, it inherits the same permissions as the developer it’s acting for.
Even organizations that have taken some steps often haven’t gone much further: 18% say agents use separate service accounts but without any formal governance around them.
The governance gap extends to policy. Nearly one-third of respondents say they have no formal policy governing AI agents or other non-human actors, while another quarter describe their approach as informal or ad hoc.
Many of the operational controls that security teams would normally expect are also uncommon. Only 15% rotate or expire agent credentials on a defined schedule. Just 14% monitor for anomalous agent behavior, 10% automatically revoke access when an agent no longer needs it, while only 9% have a formal process for provisioning new agent identities.
Credential rotation, behavioral monitoring, and automated access revocation are standard security controls. Few organizations appear to have extended them to AI agents.
New York • September 15 & 16, 2026
The pace of change keeps accelerating. See what other leaders are doing about it, at LDX3 New York.
Security awareness isn’t the same as security maturity
The survey suggests engineering organizations understand that AI changes their security posture.
Around two in five respondents say they’ve introduced new security policies specifically because of AI-powered developer tools, more than a third say security policy rewrites can be directly attributed to AI adoption, and a similar number report growing concerns around data exposure and intellectual property leakage.
Organizations may recognize that AI changes their security posture, but many are still working through the consequences. A fifth of respondents say they have yet to assess the data security implications of AI tools, while 14% report that AI has made security reviews more difficult at scale.
The adoption data also points to an interesting pattern. Organizations that have rolled AI out broadly across engineering teams are the most likely to report both new security policies and new security risks. As AI becomes embedded in more engineering workflows, organizations appear to discover new problems rather than resolve the old ones.
Meanwhile, respondents at organizations still in the proof-of-concept stage were the most likely to say AI helps identify vulnerabilities earlier in the development process. That confidence drops among organizations that have already deployed AI widely.
Experience appears to temper optimism. Once agents begin interacting with production systems, repositories, and developer environments, the security discussion shifts from what the models can do to what they’re allowed to access.
The next engineering challenge
Much of the discussion around AI security has focused on prompt injection, insecure generated code, and model behavior. Those are all legitimate concerns.
Campaigns like Shai-Hulud point toward a different problem: the permissions engineering teams are giving the agents themselves.
Engineering organizations have spent years investing in repository security, branch protections, and supply chain defenses. AI-coding agents add another trusted participant to that ecosystem – one that increasingly has permission to modify code, execute commands, and interact directly with local development environments.
Those capabilities are what make coding agents valuable, and they’re also what make them attractive targets.
The next phase of AI adoption won’t be defined solely by how capable coding agents become. It will also depend on whether engineering teams apply the same discipline to governing those agents as they already do to the humans working alongside them.
