Microsoft: AI agents search GitHub for leaked cloud keys and can reach Azure Key Vault in minutes

Microsoft says attackers are using the agentic AI framework ARTEX to search public GitHub for leaked cloud credentials. The agents then sign in to Microsoft Entra ID and Azure as the owning application and steal data. In one case, five minutes passed between the GitHub search and data leaving an Azure Key Vault. Any organization whose code has ever exposed an app secret, API key or token should revoke and rotate it now. Then check sign-in logs for the IP addresses Microsoft published on November 5, 2026.

What happened, in plain English

Applications that talk to cloud services prove who they are with secrets: passwords for software, such as a "client secret" for an app registered in Microsoft Entra ID (formerly Azure Active Directory), an API key for an AI service, or a personal access token (PAT) for Azure DevOps. Developers sometimes paste these into code or configuration files by mistake, and the files end up in a public GitHub repository.

On November 5, 2026, Microsoft Threat Intelligence reported that attackers are searching for those leaks with ARTEX. ARTEX is an "agentic" attack framework: AI agents plan and carry out steps by themselves, with little human typing. Starting in August 2026, the agents sent large numbers of GitHub searches that combined target company names with words like "secret" and the names of cloud and AI services. When they found a working credential, they signed in as that application and went looking for more: passwords stored in Azure Key Vault, files in storage accounts, SharePoint and OneDrive documents, and mailbox items.

If a cloud request failed, the agent read the error, fixed the request, and tried again. Retries came between about 28 and 80 seconds later. Microsoft saw the first successful sign-ins on October 28, 2026.

Think of a house key accidentally posted in a public photo. The new part is that a robot is now looking at every photo on the internet, and it walks to the door within minutes.

Are you affected? What to do now

You should act if your organization uses Azure or Microsoft 365, and especially if your developers, contractors or vendors push code to public GitHub. Managed service providers (MSPs) should act too: in one case Microsoft describes, a vendor's multi-tenant app credential was used against its customers' tenants.

Contain first

• Treat any secret that has ever been public as compromised. Microsoft is explicit that publicly exposed credentials "remain usable until revoked or rotated." Deleting the file or rewriting Git history does not make them safe.
• For each exposed app, remove all client secrets, certificates and federated credentials, including any the attacker may have added. Disable the service principal if needed.
• Rotate everything stored in any Key Vault that the affected app could read, plus any credentials found in documents it accessed.
• Revoke Entra sessions, Azure DevOps PATs and SSH keys for the affected identities.
• MSPs: review Partner Center access and GDAP (granular delegated admin privileges) relationships, and notify customers as your contracts require.

Check your logs. Microsoft published these IP addresses (defanged):

• 199.19.77[.]84: the main source of app sign-ins and Azure Resource Manager activity

• 199.19.77[.]18: sign-ins; Microsoft identifies it as a Tor exit node

• 65.87.223[.]26: malicious operations, including shell commands hidden in the user-agent string

• 157.22.126[.]128: reconnaissance against AI workloads on Azure AI services

• Search Entra service principal and non-interactive sign-in logs for these IPs, including failed attempts. Sign-in errors AADSTS7000215 or AADSTS7000222 mean someone is holding a credential for that app. In Microsoft's words, "a failure followed by a success is urgent."

• Check Azure Activity, Key Vault and Storage diagnostics, Entra audit, Azure DevOps audit, and the Microsoft 365 unified audit log. In Azure DevOps, look at PAT creation and first use, pipeline edits, and unfamiliar user agents. Turn on auditing if it is off.

• Don't rely on IPs alone. The attackers can change addresses and fingerprints. Hunt for behavior too, such as one address signing in to three or more service principals, or one app requesting tokens for Resource Manager, Key Vault, Storage and Graph within a short window.

• If you have Workload ID Premium licensing, Microsoft suggests blocking 199.19.77[.]84/32 in a Conditional Access policy for workload identities. Block that exact address, not the whole network.

Harden over the next weeks

• Turn on secret scanning with push protection, for example GitHub Secret Protection or GitHub Advanced Security for Azure DevOps.
• Move apps from client secrets to managed identities wherever possible.
• Give service principals only the permissions they need, and restrict who can register new applications.
• Remind developers in awareness training: never put keys in code, and report an accidental push right away so the key can be rotated.

The expert view

Most of the techniques here are old. Leaked keys on GitHub have caused cloud breaches for over a decade, and attackers have long run automated scanners against public commits. What changes is the dwell time between leak and full exploitation. A traditional scanner finds the key and hands it to a person. Here the agent does the triage itself: it validates the credential, maps subscriptions, role assignments and AI model deployments, picks the operations most likely to return more secrets, and moves sideways into Graph, Key Vault, Storage and Azure DevOps. Microsoft's "five minutes from GitHub search to Key Vault exfiltration" case shows how small the response window has become.

The adaptive retry behavior matters for defenders. Detection logic that treats repeated HTTP 400 errors as noise from a broken script can miss an agent that is reading error messages and fixing its own requests. A run of failed calls followed by a correct one from the same workload identity is the pattern to alert on.

Several details fit trends we have been tracking. ARTEX already appeared in Microsoft's Storm-0940 ConnectWise report and in Check Point's look at exposed ARTEX servers. The agents explicitly searched for AI-provider keys and validated compromised Azure AI services, echoing Google and Mandiant's findings on stolen cloud AI access being resold. Microsoft says the actor may have used those AI services to support the attack itself. If so, a victim's own AI quota would be powering the intrusion.

Microsoft also says deception helped. In its testing, decoys and honey tokens reduced the attack traffic reaching real assets. That makes sense: an agent that methodically tries every credential it finds is more likely than a cautious human to trip a planted fake one.

What is still unknown. Microsoft does not attribute this campaign to a named group. It links its separate Storm-0940 report only as related ARTEX use, and notes that Todyl reported a similar campaign from the same IP addresses. The post gives no count of victim organizations, only "dozens of associated applications across multiple tenants." It also does not say how long the abused secrets had been public. Because ARTEX is a framework that more than one operator appears to use, these IPs will likely go stale quickly. The durable defenses are short-lived credentials, managed identities and scanning before code is pushed.

Official sources

• Microsoft Threat Intelligence: "Threat actors use agentic AI tooling to find and abuse exposed secrets" (November 5, 2026)
• Microsoft Threat Intelligence: Storm-0940 uses ARTEX agentic AI in ConnectWise supply-chain compromise (October 21, 2026)
• Coverage: GitGuardian: "The agents have now found your secrets on GitHub" (November 6, 2026; vendor blog)