ARTEX AI Agents Turn Leaked GitHub Secrets Into Azure Key Vault Theft in Five Minutes

If you run Azure, Entra ID, Microsoft 365 or Azure DevOps, this one is worth reading closely. The underlying technique is old. The pace is new, and the gap between "someone committed a secret" and "someone is reading your Key Vault" has become very short.

What Microsoft observed​

Microsoft says the activity began in August 2026. The agentic framework sent large volumes of search queries to GitHub. Those queries often combined a target organization's name with secret-related keywords, cloud-service terms, or the name of another AI service provider.

The targets included:

• Ordinary credentials and application credentials (client secrets for OAuth apps and service principals)
• API keys for AI inference services
• Credentials for OAuth applications with access to Foundry Tools, the service formerly called Azure Cognitive Services

Microsoft says the agents repeatedly favored credentials that unlock AI services. It also notes that several public reports describe attackers stealing AI-service credentials, sometimes to run the same agentic workflows. In plain terms, a stolen AI key can pay for the next round of the attack.

Microsoft's conclusion is blunt: an organization that finds its secrets exposed in a public repository should assume the secrets and the applications they belong to are compromised.

Section summary: Since August 2026, an AI framework has been mining GitHub for credentials, with a clear focus on AI-service keys and Foundry-connected OAuth apps.

The October 28 wave: service principals across tenants​

The second part of the report covers follow-on credential abuse that began as early as October 28, 2026. An agentic framework used valid leaked or stolen application credentials to sign in to Entra ID tenants as service principals. From there it reached connected Azure and Microsoft 365 resources. Microsoft says the agent completed successful service principal sign-ins for dozens of applications across multiple tenants.

Some cases involved a multitenant application credential stolen from the vendor that owns the app. The attacker then used that one credential to get into several downstream customer tenants. A secret leaked by one vendor can become an incident for every customer that has consented to the vendor's app.

Indicators Microsoft published​

Microsoft says Todyl reported a similar campaign involving the same IP addresses. Treat these as hunting leads, not proof. Activity from a Tor exit node could come from anyone.

What the attacker went after​

Once signed in, the attacker focused on Azure operations that return credentials, including:

• Storage account keys
• App Service settings, connection strings and publishing credentials
• AI/ML connections and datastores
• Azure Kubernetes Service (AKS) user credentials

The compromised applications then accessed SharePoint and OneDrive, including file downloads and mailbox items. In some tenants the attacker ran Microsoft Graph searches for interesting content. It also listed subscriptions, resource groups, permissions, AI model deployments and service configurations to map each environment.

Microsoft also says the attacker tried to validate stolen Azure AI resources, which Defender for Cloud's AI threat protection flagged. Microsoft's wording here is careful: the activity suggests the attacker may have tried to use those AI resources in the broader attack. It does not claim that every resource was successfully abused.

Section summary: Leaked app secrets became service principal sign-ins, then credential harvesting, then SharePoint, OneDrive and mailbox access. One vendor's leak could expose many customer tenants.

A machine that fixes its own mistakes​

The most telling detail in the report is not the speed. It is the way the agent corrected its own errors. Microsoft describes three Azure Resource Manager request sequences from 199.19.77[.]84 that failed with HTTP 400 and then succeeded after a quick adjustment:

1. Key Vault secret metadata: a batch of requests used an API version meant for Key Vault's data plane against ARM control-plane paths. About 28 seconds after the first failure, a rerun against the same vault paths used ARM API version 2023-07-01 and returned HTTP 200.
2. Azure SQL firewall rules: a GET request with an outdated API version failed. About 60 seconds later, the same request with only the api-version parameter changed succeeded.
3. Application Insights query: a POST request with an outdated API version failed. About 80 seconds later, a retry with a supported version returned HTTP 200.

A human operator would probably need a few minutes and a documentation lookup to make each of those fixes. The agent made them in under a minute and a half. These are three documented sequences, not proof that every agent behaves this way. They do give defenders a pattern to look for: a run of 400 errors, a parameter change, and then success.

OAuth apps, Run Command and Azure DevOps​

In several cases, Microsoft says the same tools obtained a token for a single-tenant OAuth application in the target organization and then used it to explore other cloud resources. In some cases they took secrets from Azure Key Vault. After authenticating, the agents also searched Azure DevOps for more secrets, using each secret to find the next one.

The agents also used the compromised OAuth app to call Run Command, which runs scripts on Azure VMs. That access lets an attacker read credentials stored on the VM, compromise the VM's workload identities, or install persistence and move laterally. Microsoft also warns that until exposed secrets are revoked or rotated, the attacker can keep coming back.

Containment: what to do now​

Microsoft's containment steps are specific. Here they are in order, with notes on the important caveats:

1. Block 199.19.77[.]84/32 as a named location in a Conditional Access policy that targets workload identities and is assigned directly to service principals. Add it to a user-scoped block policy too, to cover replayed sessions. Block the exact IP, not the whole ASN.
2. For affected users, revoke Entra sessions, Azure DevOps personal access tokens (PATs) and SSH keys.
3. For affected applications, remove all client secrets, certificates and federated credentials, including any the attacker added. Disable the service principal if needed. Tokens that were already issued stay valid until they expire.
4. Rotate everything in any Key Vault the affected application could read, plus any credentials found in documents the attacker accessed.
5. MSPs: review Partner Center access, GDAP relationships and customer tenants, and notify affected customers as your agreements require.

The licensing and multitenant gap in step 1​

The Conditional Access block in step 1 has limits that matter for this campaign. Microsoft's own documentation says Workload Identities Premium licenses are required to create or modify Conditional Access policies scoped to service principals. Microsoft's Workload ID FAQ lists it as a standalone stock-keeping unit (SKU), $3 per workload identity per month, and not part of another SKU. The same FAQ says Microsoft apps and managed identities aren't eligible for Conditional Access.

The bigger problem is scope. These policies only cover single-tenant service principals registered in your tenant. In a Microsoft Q&A thread on this exact limit, the answer states that third party SaaS and multi-tenanted apps are out of scope.

So consider the downstream customer in the vendor scenario Microsoft described. The vendor's multitenant app credential was stolen at the source. That customer cannot use a workload identity Conditional Access policy to block the vendor's service principal by IP. Their realistic options are:

• Disable or remove the vendor app's service principal in their own tenant
• Revoke consent and review the app's permissions
• Push the vendor to rotate the credential at the source

Detection still works for these apps: Microsoft Entra ID Protection detects risk on single tenant, non-Microsoft SaaS, and multitenant apps, even though tenants cannot block those apps with Conditional Access. One more note on the "tokens stay valid until expiry" warning: continuous access evaluation for workload identities improves your organization's security by enforcing Conditional Access location and risk policies in real time. It has the same single-tenant limit.

Section summary: The IP block helps, but it needs a separate license and does nothing for multitenant vendor apps. For those, disable the app in your tenant, revoke its consent, and get the vendor to rotate the credential.

Detection and hunting checklist​

• Entra service principal and non-interactive sign-in logs: search for 199.19.77[.]84 and 199.19.77[.]18, including failed attempts.
• Error codes: AADSTS7000215 (invalid secret) and AADSTS7000222 (expired secret) mean someone has a credential for your app. A failure followed by a success is urgent.
• Wider logs: Azure Activity, Key Vault and Storage diagnostics, Entra audit, Azure DevOps audit and Microsoft 365 unified audit logs. Look for secret reads, blob and file downloads, and changes to apps, permissions or pipelines.
• Azure DevOps: PAT creation and first use, federated service connections, pipeline runs and edits, and unfamiliar user agents. Turn auditing on if it is off.
• Behavior, not just IPs: 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.
• Go back as far as retention allows. The GitHub scanning started in August.

Microsoft lists matching alerts across Defender XDR, Sentinel, Defender for Cloud Apps, Defender for Cloud (including Defender for Key Vault), Entra ID Protection and Defender for Identity. Examples include "Multiple Service Principal Sign-ins from Single IP" and "Suspicious secret listing and query in a key vault." The blog also includes advanced hunting queries with a start time of October 28.

Why IP blocking alone won't work​

Microsoft says the people running these tools can and do change source IPs, user agent strings and other fingerprints. ARTEX uses common tools by default: Nmap, curl, wget, Python HTTP clients, Norma SDK WebFetch and headless Chromium through Playwright. Their default user agents can alert you to activity, but an agent will swap them out quickly once blocked.

The behavioral signals are more useful: many different requests in a short time, rapid retries of variations on the same technique, and machine-speed jumps to the next stage. Microsoft also recommends deception. Honeypots and decoys such as Microsoft Sentinel Deception give the agent worthless targets. Tarpits use up its time and budget. "Fake wins" can convince it the job is done. Microsoft says these controls reduced attack traffic reaching real assets in its own testing. That result comes from the vendor that sells Sentinel, so verify it in your own environment, but the idea is reasonable: an agent that cannot tell a real result from a fake one is easy to mislead.

Fixing the root cause: stop putting secrets in code​

The long-term fix is to remove secrets that can be committed to a repository at all:

• Scan your repositories and turn on GitHub's public monitoring, which looks for your secrets in other people's public repositories. Push protection can block supported secrets before they are pushed. In Azure DevOps, this requires GitHub Advanced Security for Azure DevOps or GitHub Secret Protection for Azure DevOps.
• Deleting a secret does not fix it. The credential still works, and copies remain in commit history, caches, archives and logs. Rotate it and investigate how it was used.
• Move away from client secrets. Microsoft recommends managed identities for Azure-hosted workloads. Its app-registration guidance ranks managed identities first, then federated credentials from trusted platforms such as GitHub Actions, then certificates. Password secrets come last.
• Apply least privilege to service principals through Azure RBAC. Protect backup and recovery resources. Turn on the Defender for Cloud plans that match your workloads: Resource Manager, Storage, Key Vault, App Service and Databases.
• Restrict app creation. Set user app registration to "No" and limit the Application Developer role to privileged users.

The bottom line​

None of the techniques here are new: credential scanning, service principal abuse, Key Vault theft. What has changed is how fast they happen. A small mistake, like a client secret in a public repository, now gets found and exploited in minutes instead of days or weeks. The practical steps are to rotate anything that was ever exposed, replace client secrets with managed identities and federated credentials wherever possible, and hunt for behavior rather than relying on IP lists. If you consume multitenant vendor apps, ask those vendors how they store their credentials, because your Conditional Access policies can't block a stolen vendor credential.