Developers, automated tools and AI coding agents hold permissions that can outlast the work they were granted for. Without access reviews, organizations can leave accounts able to copy or change company code after the work ends, according to BlueFlag Security’s The State of Developer Risk 2026 report.

Development accounts and tools create security blind spots

Software development spans code repositories, review systems, build pipelines and connected applications. Developers, contractors, service accounts, bots and AI coding agents use these systems with permissions that require ongoing oversight.

Access can accumulate when developers join projects, change teams or take on administrative tasks. Permissions granted for a contract or assignment may remain after the work ends.

The average developer had not used 61% of their granted permissions. Of the developers holding the most unused permissions, 88% could access repositories their organizations classified as business-critical, including those supporting production services, payment systems and regulated workloads.

Four in five organizations had developer identities that had been inactive for more than 90 days but retained administrator permissions. Compromised credentials for these accounts could give attackers access to repositories and their settings.

Non-human identities outnumber developers eight to one

Service accounts, bots, connected applications and access tokens allow tools to retrieve code, run builds and deploy software. Across the pooled dataset, non-human identities with repository access outnumbered human developers with repository access eight to one. The calculation includes access tokens as identities.

AI agents access risks

Source: BlueFlag Security

Of the repository-access tokens measured, 99% had no expiration date, 84% allowed code changes and 47% had been unused for more than 90 days without being revoked. These credentials can remain usable after a project or integration ends.

Unused permissions held by non-human identities also extended to business-critical repositories, increasing the potential consequences of credential theft.

AI coding agents gain access without oversight

A typical organization used about seven AI coding tools, with some using more than 30. Unapproved agents were present in 83% of the organizations measured. Most organizations lacked a list of approved tools.

Coding assistants work under a developer’s identity and inherit its permissions. Autonomous agents operate as separate identities and can write, review and merge code without a human approving each action.

Assistants can also operate under service account identities. Administrator permissions were held by 68% of the developer and service account identities that agents operated under, and 81% lacked behavioral monitoring. In six in ten organizations with AI activity, agents used tokens capable of cloning every repository.

Actions taken through a developer’s account may appear under that person’s name, making human and AI activity difficult to distinguish without commit tags or other metadata.

“They are the most powerful identities in the environment and fall into two categories: coding assistants, which work under a developer’s identity and inherit its access and permissions, and autonomous agents, which operate as their own identity and can write, review, and merge code with no human in the loop,” the company said.

Unusual activity and bypassed checks raise risks

Half of the organizations measured had at least one identity that showed a spike in code cloning compared with its previous activity. In 28%, an identity cloned at least 100 repositories it had never accessed before. These patterns can warrant investigation for credential misuse or code theft, though they do not prove either.

Four in ten repositories had unprotected main branches, and administrators bypassed code review in four in five organizations. Code was merged despite failed checks in 56% of organizations and with unresolved reviewer comments in two-thirds. Neither finding establishes that the changes were deployed or contained security flaws.

Private repositories became public in 28% of organizations, potentially exposing code, documentation and stored credentials.