A Quiet Shift in How Access Is Leaked
That familiarity is precisely why the current shift is so important. At first glance, the story still looks the same: a mistake is made, a fix is applied, and the system continues to operate. However, beneath that surface, there is a significant change in both the type of exposure and the way these leaks are being introduced. What appears to be a simple continuation of an old problem is, in reality, the emergence of a more impactful and systemic risk.
It Starts the Same Way
The workflow often looks efficient and modern. A developer is under delivery pressure and working quickly, frequently relying on AI to generate boilerplate code or accelerate development. Code is produced, validated, and committed in rapid succession. The commit message is structured, clean, and sometimes even includes emojis or phrasing that resembles documentation more than a human thought process. It feels polished, and in many cases, it reflects AI-assisted output rather than traditional manual effort.
Shortly after, a second commit appears. This time, it explicitly references the removal of sensitive data, with messages such as “redact exposed client secret” or “remove credentials from documentation”. The developer has identified the issue and corrected it almost immediately. From a workflow perspective, this looks like responsible behaviour. The problem is detected, acknowledged, and fixed with minimal delay.
However, the speed and structure of this process introduce a false sense of security. The correction does not undo the original mistake. The exposure has already occurred, and the way version control systems operate ensures that the impact does not simply disappear with a follow-up commit.
What it looks like in practice?
Here is a simple example of a GitHub search that revealed a client secret that was later removed through a commit generated by AI.
The Moment Everything Changed
During analysis of public repositories, a simple query revealed the scale of the issue. Searching for commits containing the phrase “remove client secret” returned approximately 124,000 results. This is not an anomaly or a handful of isolated mistakes. It represents a widespread pattern of behaviour that has become normalised across development workflows.
This volume highlights a critical point. Developers are not ignoring security practices. In fact, they are actively attempting to correct issues when they are identified. The problem is that the underlying system retains every change, meaning that even well-intentioned remediation efforts leave behind a permanent trace of the exposure.
The presence of such a large number of commits with similar patterns indicates that this is no longer an edge case. It is a systemic issue driven by modern development practices, rapid iteration cycles, and increasing reliance on automation and AI-generated code.
The Secret That Never Leaves
One of the most important aspects of this issue is the persistence of data in version control systems. When a secret is committed, it becomes part of the repository’s history. Removing it in a subsequent commit does not eliminate it from that history. Instead, it simply hides it from the most recent version of the code.
This distinction is critical because repository history remains accessible. Anyone with access to the repository can retrieve earlier versions of the files and extract the original secret. Attackers actively monitor these patterns and understand exactly how to exploit them.
In many cases, the commit that removes the secret provides additional context that simplifies exploitation. It signals that a secret existed, identifies where it was located, and narrows down the timeframe in which it may still be valid. Instead of reducing risk, the remediation commit can inadvertently highlight the exposure.
A New Kind of Access
The nature of the exposed data significantly increases the impact of these leaks. Azure application client secrets are not simple credentials tied to a single service. They represent an identity within the Azure ecosystem. When an attacker gains access to a client ID, tenant ID, and client secret, the attacker can authenticate as that application and inherit its permissions.
This means the attacker is not limited to a single resource. The application may already be trusted and granted access to critical services such as Microsoft Graph APIs, directory information, or messaging capabilities. In some cases, permissions include administrative consent at the tenant level, which broadens the potential impact even further.
As a result, these leaks provide a direct path into enterprise environments. They allow actions to be performed at scale, often without triggering traditional authentication alerts, because the activity appears to originate from a legitimate application identity.
Machine to machine authentication
In practice, abusing a leaked Azure application secret is surprisingly trivial. There is no need for user interaction, phishing, or complex exploitation chains. The attacker simply uses the OAuth 2.0 client credentials flow, which is designed for machine to machine authentication. In this flow, the application authenticates directly using its own credentials, namely the client ID and client secret, without any user context involved. Once those values are known, the attacker can send a single HTTP POST request to the Azure token endpoint and immediately obtain a valid access token for the tenant. This flow is also designed not to enforce multi-factor authentication because it is intended for machine-to-machine authentication.
POST https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token Content-Type: application/x-www-form-urlencoded client_id=CLIENT_ID &client_secret=CLIENT_SECRET &scope=https://graph.microsoft.com/.default &grant_type=client_credentials
The AI Factor
A notable characteristic of these exposures is the consistency in how they are introduced and corrected. Commit messages are often well structured, descriptive, and aligned with best practices for clarity. The presence of emojis, consistent formatting, and explicit language suggests that many of these commits are influenced by AI-assisted development tools.
AI is accelerating the development lifecycle by generating code, reducing manual effort, and enabling faster delivery. However, it also introduces risk when sensitive values are included in generated outputs or quickly integrated without proper validation. Developers relying on these tools may inadvertently commit secrets as part of generated configuration or example code.
The correction process is equally accelerated. The secret is identified and removed quickly, often within minutes. Despite this, the initial exposure remains embedded in the repository’s history, demonstrating that speed alone does not mitigate the underlying risk.
What Actually Works
Effective mitigation requires a shift in mindset. Removing a secret from code should not be considered the final step. Any secret that has been committed must be treated as compromised, regardless of how quickly it was removed. Immediate rotation of the affected credential is essential to prevent unauthorised access.
In addition, applications should follow a strict least privilege model. By limiting permissions to only what is strictly necessary, the potential impact of a leaked secret can be significantly reduced. Overly broad permissions increase the severity of any exposure and should be avoided wherever possible.
Long-term improvements involve reducing reliance on static secrets altogether. Approaches such as managed identities eliminate the need to store credentials in code and remove an entire class of risk associated with secret management. Preventative controls, such as pre-commit scanning and automated checks in CI pipelines, are also critical to ensuring that sensitive data is not introduced in the first place.
My Thoughts
The narrative around leaked keys has remained largely unchanged for years, but the underlying reality is evolving. AI-driven development is changing how code is produced and deployed, and with it, how secrets are handled. The combination of speed, automation, and persistent history creates a scenario where mistakes are quickly corrected but never truly erased.
This shift requires a new approach to security. It is no longer sufficient to focus solely on detecting exposed secrets. The focus must also include identifying patterns of exposure and addressing the workflows that enable them.
In this new reality, the problem is not just that secrets are leaked. It is that they are committed, fixed, and still fully available. Visibility is key to properly identifying potential leaks.