The short version: On November 5, 2026, Microsoft Threat Intelligence and GitGuardian published research on ARTEX, an open-source agentic AI framework that threat actors are using to scan GitHub for exposed credentials and automatically turn them into cloud access. In one documented case, an agent went from a GitHub search to pulling data out of an Azure Key Vault in five minutes. ARTEX didn't invent credential leakage — it automates what used to take a skilled human hours of manual recon and exploitation. The underlying problem is the same one security teams have had for a decade: standing API keys and secrets sitting in source code and environment variables, just now with a much faster, tireless attacker on the other end.
What Microsoft and GitGuardian actually found
Microsoft's research describes threat actors using ARTEX, a framework it calls an "agentic offensive security framework," built to search GitHub for OAuth application secrets that can be used to compromise the associated application and perform authenticated actions inside its tenant. That's a narrower, more precise description than "AI hacking tool" — ARTEX is purpose-built to find a specific class of leaked credential and immediately test what it unlocks.
GitGuardian's companion write-up adds the detail that made this story travel fast: the agents found OAuth application secrets, signed in as service principals, and moved through Azure and Microsoft 365 tenants, and in one case an agent went from scanning GitHub to exfiltrating data from Azure Key Vault in five minutes. Five minutes is roughly the time it takes a human analyst to finish reading the alert, let alone respond to it.
Microsoft describes the reconnaissance pattern as high-volume and targeted at once, with agents sending large volumes of GitHub queries that combine a target company name, secret keywords, and cloud or AI service names. That's not a generic sweep of public repos — it's an agent building a query strategy per target, the way a human red-teamer would, but at a pace no human team sustains.
How ARTEX chains a leaked key into cloud access
What gets attackers from "found a secret" to "sitting in Key Vault" isn't a novel exploit — it's an agent executing the same chain a human attacker would, without the downtime between steps. Once ARTEX locates a credential, researchers describe the agent testing whether it's live, signing in as the associated service principal, and then mapping what that identity can reach. Targets reported in related campaign writeups include storage account keys, App Service settings, connection strings, publishing credentials, machine learning connections, and Azure Kubernetes Service user credentials, with attackers enumerating Azure subscriptions, resource groups, and AI deployments once inside.
This is the part worth sitting with: the agent isn't just stealing the one key it found. It's using that key as a foothold to enumerate everything else the compromised identity can touch, then pivoting again. A single exposed OAuth secret in a GitHub repo becomes a map of an organization's Azure tenant in the time it takes to brew coffee.
Who's behind it, and how far it's spread
ARTEX itself is not malware in the traditional sense. Researchers tracking it describe an open-source, AI-model-driven, autonomous penetration testing framework released on GitHub by a user known as "Autumn-27" in July 2026 — a multiagent system written in Go with a Next.js front end that can work with multiple AI models. It was meant, at least nominally, for authorized penetration testing.
That didn't last. The original GitHub repository for ARTEX was taken down by its creator in October 2026 due to widespread threat actor abuse, with the author maintaining the tool was never meant to power real attacks. Removing the repo didn't remove the tool: community forks keep it spreading, including localized versions such as ScopeWeaver and a commercial version called ARTEX PRO.
Microsoft has separately tied ARTEX use to Storm-0940, a China-state-aligned actor that used the framework to automate attacks against hundreds of organizations across the globe, in a campaign connected to a ConnectWise Cloud Backup supply-chain compromise reported in late October 2026. CrowdStrike separately attributed a related campaign, which it calls VAPOR PANDA, to ARTEX-driven activity against more than 200 organizations in at least 14 countries. Independent telemetry from Censys shows the tooling proliferating beyond any single group: as of November 4, 2026, Censys detected 1,465 hosts running an exposed ARTEX console, a framework it links to malicious activity from multiple, unrelated threat groups.
1 · July 2026
ARTEX is published on GitHub by its creator, pitched as an autonomous penetration-testing framework.
2 · August 2026
Earliest GitHub secret-scanning activity later attributed to ARTEX-style agents begins, according to Microsoft's timeline of the campaign.
3 · September–October 2026
Storm-0940, a China-state-aligned actor, is observed using ARTEX in a supply-chain campaign touching ConnectWise Cloud Backup and Microsoft 365 tenants; CrowdStrike tracks a separate 11-day, 200+ organization campaign it calls VAPOR PANDA.
4 · Mid-October 2026
ARTEX's creator pulls the original repository after widespread abuse. Forks and a commercial "ARTEX PRO" version keep circulating.
5 · November 4–6, 2026
Censys and Check Point publish instance counts for exposed ARTEX consoles; Microsoft Threat Intelligence and GitGuardian publish their research within a day of each other, and coverage spreads across security trade press.
Why signature-based secret scanners can't keep the same pace
Secret scanners — including good ones — are built to answer a narrower question than the one ARTEX is now exploiting. A scanner finds a pattern that looks like a key, flags it, and at best files a ticket or fires a webhook. That workflow assumes a human reviews the finding, confirms it's live, figures out what it touches, and rotates it. Microsoft's and GitGuardian's research describes an adversary that has collapsed that entire human-paced workflow into an automated loop running in minutes, not days.
This isn't an argument against scanning — GitGuardian's own data makes the case for why scanning still matters: secrets sprawl surged in 2025, with 28.65 million hardcoded secrets exposed on public GitHub, a 34% single-year rise, and leaks tied specifically to AI services grew even faster. The point is narrower: detection that depends on a human in the loop to triage and revoke is now racing against a tool that doesn't sleep, doesn't take lunch, and doesn't wait for a ticket to be assigned. The gap between "scanner flags a leaked key" and "someone revokes it" is exactly the window ARTEX is built to exploit.
It's also worth noting that leaked secrets aren't a new problem feeding a new campaign — they're often the same secrets. Recent worm-style supply-chain incidents have fed this hunting ground directly: campaigns like Shai-Hulud 2.0 dumped large volumes of stolen secrets onto public GitHub, the same hunting ground ARTEX now searches with an agent instead of a human. KnoxCall covered that dynamic in more depth in Shai-Hulud: Why a Secrets Manager Can't Save You From a Poisoned Dependency.
What this means for how organizations hold credentials
The uncomfortable truth in this research isn't that a new tool exists — it's that the tool only works because the raw material is already sitting there. ARTEX doesn't break encryption or exploit a zero-day. It finds credentials that were never supposed to be exposed in the first place, confirms they still work, and uses them. That's the same attack surface KnoxCall's architecture exists to shrink: standing, long-lived API keys sitting in application code, CI configuration, and .env files, available to anyone or anything that can read the repo.
KnoxCall's model is to inject the real third-party API credential at the egress wire, so the application process, the CI runner, and any AI agent calling out through the gateway never actually hold the plaintext key. To be precise about what that does and doesn't address here: it doesn't stop a developer from committing a key to GitHub, and it wouldn't have prevented the initial exposure Microsoft describes. What it changes is the blast radius after exposure — there's no long-lived secret sitting in the codebase for a scanner, human or agentic, to find in the first place, because the credential was never placed there. That's a different failure mode than "we scanned and caught it faster."
The broader shift this research signals is one worth taking seriously regardless of which vendor's tooling you run: agentic AI is now operating on both sides of the credential lifecycle. The same automation that helps defenders triage alerts is available to attackers deciding which of an organization's leaked keys to try first. For more on reducing the standing-secret surface this kind of tooling depends on, see 5 API Key Security Mistakes That Put Your Business at Risk and Your Secrets Live in Cleartext: The Credential Attacks No Checklist Can Stop.
What to do if you think a secret is exposed
- Treat any committed secret as compromised, immediately. GitGuardian's incident guidance is to remove every client secret, certificate, and federated credential on the affected app, including any an attacker may have added, because tokens already issued stay valid until they expire even after rotation.
- Prioritize by privilege, not by discovery order. Microsoft's guidance is to start revocation with valid, high-privilege credentials — especially OAuth application and service principal secrets that provide access to sensitive cloud resources, data, or other credentials.
- Check what the compromised identity could reach, not just what was leaked — ARTEX's value to an attacker comes from enumeration, not the initial key.
- Turn on push protection and secret scanning at the platform level so commits with recognizable key patterns are blocked before they land in history, not just flagged after the fact.
- Reduce the number of long-lived secrets that exist to be found. Managed identities, short-lived tokens, and gateway-mediated credential injection all shrink the set of things an agent like ARTEX can go looking for.
What's still unconfirmed
A few things remain genuinely unresolved as of this writing. Instance counts for exposed ARTEX consoles differ by methodology and measurement date — Censys and Check Point published different totals within a day of each other using different detection methods — and both caution their numbers are an incomplete view, since ARTEX's management console doesn't need to be publicly exposed to be in use. Attribution is also not singular: Microsoft ties one campaign to the China-aligned Storm-0940, while CrowdStrike and other researchers have linked separate ARTEX-driven activity to different actors entirely, which is consistent with an open-source tool anyone can run rather than one group's private infrastructure. Readers should treat ARTEX as a tool in use by multiple, unrelated actors, not evidence of a single coordinated campaign.
For teams evaluating how their own API key handling holds up against this kind of tooling, KnoxCall's security overview and AI gateway documentation cover how credential injection at the edge changes what's available to be leaked in the first place. See also how KnoxCall compares to running a traditional secrets manager alongside your existing stack.