Microsoft says attackers are running the ARTEX agentic framework to search public GitHub repositories for OAuth application secrets, then using those secrets to read Azure Key Vault, download files and run scripts on VMs. In a report published November 5, 2026, Microsoft Threat Intelligence describes at least one case in which an AI agent moved from scanning GitHub to exfiltrating Key Vault data in five minutes. Anyone who has ever committed a client secret, storage key or AI provider API key to a public repository is exposed, and deleting the commit does not undo it. Cyber Security News summarized the report on November 6.
| Question | Short answer |
|---|---|
| Am I affected? | If a secret for an Azure/Entra app, storage account or AI provider was ever pushed to a public repo, assume yes. Vendor-owned multitenant apps put downstream customers at risk too |
| Is there a patch? | No. This is credential abuse, not a software bug. The fix is revocation, rotation and tighter identity controls |
| Is it exploited? | Yes. Microsoft observed GitHub scanning from August 2026 and tenant access from October 28, 2026 |
| Does deleting the commit help? | No. Microsoft says exposed credentials stay usable until revoked or rotated |
| Does data leave my machine? | Not from a local coding agent. The data theft happens in cloud tenants |
What Microsoft observed
Searching public repositories for leaked credentials is an old technique. What changed, per Microsoft, is that the human bottleneck is gone: ARTEX agents run the searches, read the results and carry out follow-on attacks without a hands-on-keyboard operator at each step. Beam has covered the framework from several angles, including CrowdStrike's South Korea bank case, Vapor Panda's 200-organization campaign, Microsoft's Storm-0940 findings and Google and Mandiant's five defense layers. This report adds a concrete, secret-to-cloud chain.
The attack chain, step by step
- Search GitHub at volume. From August 2026, the agents submitted many queries combining a target organization's name, keywords for secrets, a keyword linked to cloud services, or a keyword for another AI provider. They found application credentials and AI inference API keys committed to scripts, configuration files and source code.
- Get a token for the OAuth application. In multiple cases the agents obtained a token for a single-tenant OAuth application in the target organization using the leaked client secret.
- Enumerate the cloud. With that identity the agents mapped subscriptions, permissions, resource groups and AI deployments. Microsoft notes a repeated focus on credentials that open AI services, including API keys for major providers and OAuth apps with access to Foundry Tools.
- Read secrets. The agents exfiltrated secrets from Azure Key Vault and searched Azure DevOps for more credentials. Microsoft also lists storage keys, connection strings, App Service settings, publishing credentials and Azure Kubernetes Service credentials as targets.
- Collect and execute. Compromised apps accessed SharePoint and OneDrive, and the agents used Azure VM Run Command to execute scripts inside virtual machines. On a VM, an attacker can reach unsecured credentials, compromise workload identities, or plant persistence and move laterally.
Machine-speed retries
Microsoft included a detail that shows the agent nature of the activity. A batch of requests to several Key Vault resources returned HTTP 400 because they mixed Key Vault data-plane API versions with Azure Resource Manager (control-plane) endpoints. About 28 seconds later, a rerun against the same vault paths used ARM API version 2023-07-01 and returned HTTP 200. A similar fix followed an outdated API version on an Azure SQL firewall-rules request after roughly 60 seconds, and on an Application Insights query after roughly 80 seconds. The URLs changed only in the api-version parameter. A human might make the same correction, but not that consistently across services.
Timeline
| Date | Event |
|---|---|
| August 2026 | Microsoft first sees large-volume GitHub secret searches by the agentic framework |
| October 28, 2026 | Earliest successful service-principal sign-ins from 199.19.77[.]84 against Entra ID tenants |
| November 5, 2026 | Microsoft publishes its report and detections |
| November 6, 2026 | Secondary coverage appears |
Microsoft also notes that a similar campaign using the same IP addresses was reported by Todyl, and that activity from 65.87.223[.]26 included embedded shell commands in a user agent, which suggests attempted vulnerability exploitation, plus attempts to obtain App Service authentication tokens.
Who is affected
The exposure is organizational, not tied to a product version. You are in scope if you have OAuth applications or service principals whose client secrets were ever committed publicly, if you rely on a vendor whose multitenant application secret leaked (the vendor's mistake becomes your tenant's breach), or if you run Azure workloads with AI service keys in code. Microsoft says the agent signed in to "dozens of associated applications across multiple tenants"; treat that as a hint at the blast radius, not a count of victims.
What this means if you run AI coding agents
ARTEX is not aimed at coding agents, but the lesson transfers directly. The secrets in this story are the ones developers and agents routinely handle: .env files, client secrets in config, API keys for model providers. Beam has previously documented how API keys leak through logs and environment variables and 26,400 live cloud and AI credentials found in public repos. Practical steps, following Microsoft's guidance:
- Search your own repos first. Look for client secrets, storage keys, connection strings and AI provider keys in current files and in history. Enable GitHub secret scanning and push protection. Microsoft also points to public monitoring, which can find your organization's secrets leaked into secondary public repositories.
- Treat any exposed secret as compromised. Revoke or rotate it and review its historical use. Removing the file does not remove copies in history, caches or archives.
- For an affected application, remove all client secrets, certificates and federated credentials, including any the attacker added, and disable the service principal if needed. Tokens already issued remain valid until they expire.
- Rotate everything stored in any Key Vault the application could read, plus credentials found in documents it accessed.
- Hunt in logs. Review Entra service principal and non-interactive sign-ins for the listed IPs back to October 28 or as far as retention allows. Microsoft says errors AADSTS7000215 (invalid secret) or AADSTS7000222 (expired secret) mean someone holds a credential for your app, and a failure followed by a success is urgent. Also check Azure Activity, Key Vault diagnostics, storage logs and Microsoft 365 audit data.
- Contain first, then investigate. Microsoft's containment guidance includes blocking the exact source IP in Conditional Access and revoking sessions and tokens for the affected application, alongside removing its secrets and certificates, so the attacker cannot keep using access already granted.
- Look at behavior, not just IPs. Microsoft suggests flagging one address authenticating to three or more service principals with mixed success, or one app requesting tokens for ARM, Key Vault, Storage and Graph in a short window.
- Reduce what a stolen secret can do. Move to managed identities where possible, apply least privilege to service principals, and restrict who can register applications.
- Keep agent sessions clean. Do not paste secrets into prompts, and keep credentials out of repositories an agent edits and pushes.
Indicators Microsoft published
| Indicator | Context |
|---|---|
199.19.77[.]84 | Successful application sign-ins; discovery and credential abuse |
199.19.77[.]18 | Sign-in source; a Tor exit node, so it may carry unrelated traffic |
65.87.223[.]26 | Possibly associated malicious operations; App Service token attempts |
157.22.126[.]128 | Separate reconnaissance against Azure AI workloads |
Microsoft cautions that attackers change source IPs and user agents, so blocking addresses alone will not stop the agents. It also notes that ARTEX by default uses tools such as Nmap, curl, wget, Python HTTP clients and headless Chromium through Playwright (Microsoft also lists a WebFetch tool from the Norma SDK), whose default user agents can still be useful alerts. Microsoft further suggests decoys, tarpits and "fake wins" to pull autonomous attacks away from real assets.
What Beam can and cannot do here
Beam is local security and observability for coding agents; it does not monitor Azure, Entra or GitHub, and it would not have seen this campaign. Where it overlaps is the developer-side half: it flags credential exposure in agent actions, and redacts known secret formats before storing events, so secrets that pass through an agent session are less likely to sit in plain text in logs. Its checks are heuristic and hook-based rather than a kernel sandbox, and it cannot revoke a secret that is already public. If a key has leaked, rotation is the only remedy. See how Beam works and what it watches.
What developers should remember
Three things stand out. First, the speed: five minutes from search to Key Vault theft leaves no window for a slow cleanup after a leak, so push protection beats later rotation. Second, the identity is the perimeter: a single leaked client secret was enough to pivot into storage, DevOps and VMs. Third, vendor risk is real: a leaked secret on a multitenant application extends to every customer tenant that consented to it. Microsoft's headline recommendation, moving away from long-lived secrets, removes the thing the agents are hunting for.
Frequently asked questions
What did Microsoft report about ARTEX and GitHub secrets?
Microsoft Threat Intelligence says that since August 2026 attackers have used the agentic framework ARTEX to run large volumes of GitHub searches for exposed secrets, then used compromised OAuth applications to reach Azure Key Vault, storage, Azure DevOps and VMs. In at least one case an agent went from GitHub search to Key Vault exfiltration in five minutes.
Does deleting a leaked secret from GitHub fix it?
No. Microsoft says publicly exposed credentials must be treated as compromised even if the content is later edited or deleted, because copies remain in history, caches, archives and logs. Revoke or rotate the credential and review its past use.
Which indicators did Microsoft publish?
Microsoft lists the IP addresses 199.19.77[.]84 (successful application sign-ins), 199.19.77[.]18 (a Tor exit node), 65.87.223[.]26 (App Service token attempts) and 157.22.126[.]128 (reconnaissance against Azure AI workloads). It warns that attackers can change IPs and user agents, so behavior matters more than any single address.
Does this affect people who run AI coding agents?
Indirectly. ARTEX does not attack coding agents. But it harvests the same kind of secrets that end up in repos and agent sessions: client secrets, storage keys, connection strings and AI provider API keys. Keeping them out of code, prompts and logs is the shared defense.
What is the most durable fix?
Microsoft recommends moving OAuth applications away from secret-based authentication to managed identities, enforcing least privilege on service principals, and enabling GitHub secret scanning with push protection so supported secrets are blocked before they are pushed.
Related reading
- ARTEX and Friends: what Google and Mandiant saw
- Storm-0940 ARTEX agents and the ConnectWise supply-chain compromise
- Wiz: seven fingerprints of agentic attacks
- November 2026 attacks timeline
Details reflect Microsoft's report of November 5, 2026 and may change as the investigation continues. Beam is a local prototype; check the linked sources for the latest.

