Microsoft: AI Agents Are Hunting GitHub for Exposed Secrets, and Reached Azure Key Vault in Five Minutes

A secret that sits in a public repository for an afternoon used to be a gamble on whether anyone was looking. Microsoft now says someone is always looking, and that the looking is done by software that does not get bored. In a research post published on 5 November, Microsoft Threat Intelligence describes threat actors using an agentic AI offensive framework to search public GitHub repositories for exposed secrets, then using what they found against Azure and Microsoft 365. In at least one case, an AI agent went from searching GitHub for client secrets to taking data out of Azure Key Vault in five minutes.

This is the other half of stories we have covered before: a vendor's application credential used to reach customer Microsoft 365 tenants and an actor who found and used service-principal secrets in Azure. Here the interesting part is the speed of the step before the break-in: finding the key.

What Microsoft reports

The research is first-party and recent. Microsoft does not name a threat group in this post. It says it has seen the GitHub searching since August 2026 and names the tooling as ARTEX, an agentic penetration-testing framework.

Where the search happens. Public GitHub repositories. The queries often contained the name of a target organisation together with keywords for secrets and for cloud or AI services. After getting in, the agents also searched Azure DevOps for secrets.
What they are after. Application client secrets, service-principal credentials, storage keys, connection strings, and API keys for AI services and OAuth applications with access to Azure AI tooling. Microsoft's explanation for why these are in code is mundane: developers store them in configuration files and scripts to get an application working quickly.
What happened next. In one follow-on attack that began as early as 28 October, an agentic framework used valid leaked or stolen application credentials to sign in as dozens of applications across multiple tenants. It then enumerated and exfiltrated Key Vault secrets, pulled credentials from storage accounts and App Service settings, and searched SharePoint, OneDrive and mailboxes through Microsoft Graph.
How fast. The five-minute GitHub-to-Key-Vault case. After a failed request caused by the wrong API version, the agent retried with a supported one in about 28 seconds in one case, 60 in another and 80 in a third. Microsoft's point is that the tooling adapts to errors at machine speed.
Why it lasts. Microsoft writes that until the secrets are revoked or rotated, they can let an attacker stay in, compromise further identities or hijack resources.

What independent reporting adds

Todyl, a managed-detection provider, published a separate and ongoing investigation on 3 November that Microsoft cites. It reports a single operator signing in as customers' own applications from 1 November, using stolen credentials that were still valid, and says some of the same IP addresses appear in Microsoft's report. Todyl counts about 45 app registrations at roughly 18 organisations targeted, more than 33 of which authenticated, with 27 organisations reached so far, including the clients of managed service providers. It says its figures are a floor, because they only cover customers that send logs to it.

Todyl is more cautious than the headline. It says no Microsoft vulnerability is involved, that how the actor first obtained the credentials is still unknown, and that some of the starting secrets had only ever been used from staff devices and office networks, which it reads as pointing to a file store or live backend rather than configurations crawled from the internet. It rates the possibility that an AI model is directing the activity as low confidence, and does not tie it to a specific framework. It also assesses the activity as unrelated to the October ConnectWise Cloud Backup compromise that Microsoft attributed to Storm-0940.

Separately, CyberScoop reported on 30 October, citing CrowdStrike, a different ARTEX campaign that CrowdStrike attributes to a China-backed group it calls Vapor Panda, with about 140 sensitive targets compromised in 11 days out of more than 200 targeted. CrowdStrike also counted roughly 45 agentic adversary attacks in September and 126 in October. That is a vendor's count, and a different matter from Microsoft's secrets research. It is useful here only as a signal of how quickly this style of tooling is spreading.

Confirmed, reported and unknown

Reported by Microsoft as observed: GitHub secret searches by an agentic framework from August 2026; valid-credential sign-ins from late October; the five-minute case; the Key Vault, storage and Graph activity.
Hedged by Microsoft itself: one of the two IP addresses is a Tor exit node that may be tied to unrelated activity; another is only “potentially associated”; and the suggestion that the actor tried to abuse compromised AI resources is worded as a possibility.
Unknown: who is behind it, how many repositories were scanned, how many secrets were found and how many victims there are beyond “dozens” of applications. Microsoft gives no totals. Whether Todyl's victims and Microsoft's are the same set is not stated.
Not established: that every stolen secret came from GitHub. Todyl's evidence points elsewhere for at least some of them.

What to do

Treat any secret that was ever public as compromised. Microsoft is explicit that removing the content does not invalidate the credential or erase copies in edit history, caches, archives or logs. Revoke and replace it, then look for use of the old one.
Scan before the attacker does. Turn on secret scanning with push protection for your GitHub and Azure DevOps repositories, search history as well as the current branch, and include forks and personal repositories of staff who work on your systems.
Find application secrets you do not know about. List every app registration and service principal with a client secret, who owns it and when it was last used. Remove the ones nobody owns.
Replace secrets with identities. Microsoft recommends moving OAuth applications off secret-based authentication and using managed identities, which removes the possibility of the secret leaking from code.
Shrink what one stolen secret can reach. Apply least privilege to service principals, and check what each can read in Key Vault. In an incident, rotate everything in any vault the application could read.
Watch for the early signals. Microsoft points to sign-in errors AADSTS7000215 (invalid secret) and AADSTS7000222 (expired secret), which mean someone holds a credential for your app, especially when a failure is followed by a success. One address signing in to several service principals, or one app requesting tokens for Resource Manager, Key Vault, Storage and Graph within a short window, is also worth an alert.
Block with Conditional Access, but do not rely on indicators. Workload-identity policies can block named IPs, but Microsoft notes they only cover single-tenant apps in your tenant and that attackers change addresses and user agents.
If you are a managed service provider, review Partner Center access and delegated administration relationships, and tell customers when their tenant is affected.
After you revoke, remove the secret from every document it travelled in. Replacement values often get pasted into the same ticket, chat or file that leaked the old one.

The handover after a rotation

A rotation produces new values that have to reach the engineers who configure services, often in a hurry and during an incident. That is the moment secrets get pasted into a channel, a ticket or a shared document that other people and tools can read. Send each new value once, to the single person who needs it, over a channel that does not keep it, and do not commit it to a repository on the way to the place it is used.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a secrets-management or code-scanning product. It cannot scan GitHub, revoke an Azure application secret, change a Conditional Access policy or hunt for sign-ins. Use your cloud provider and scanner for that, and a one-time link for the moment one person gives another a credential.