On November 5, 2026, Microsoft Threat Intelligence reported that threat actors had used ARTEX to search public GitHub repositories for exposed credentials. Microsoft said it observed those searches beginning in August and related successful service-principal sign-ins as early as October 28. In one case, the path from GitHub scanning to Azure Key Vault data exfiltration took five minutes.
If a credential is exposed, revoke or rotate it, then investigate how it was used. Removing the public file does not invalidate the credential.
How Microsoft says ARTEX reached cloud resources
Microsoft described ARTEX as an agentic AI framework that searched for secrets, analyzed results and carried out follow-up actions. The searches reportedly combined organization names with terms related to secrets, cloud services or AI providers.
A service principal is an identity an application uses to authenticate to services. Microsoft reported successful sign-ins involving dozens of associated applications and multiple tenants. In some cases, a multitenant application's credential was compromised at its vendor-owned source and then used against downstream tenants.
The reported activity included searches for or access to storage-account keys, App Service settings, connection strings, AI and machine-learning data connections, and Azure Kubernetes Service credentials. Microsoft also described access involving Azure Key Vault, Storage Accounts, Azure AI, Azure DevOps, SharePoint and OneDrive. SharePoint and OneDrive activity included file downloads and mailbox-item access; some Microsoft Graph requests mainly searched for relevant content.
For a broader look at tool access, permissions and other agent risks, see NeoTeo's overview of autonomous-agent risks. Microsoft's account here centers on exposed credentials and the cloud activity that followed.
Three separate Azure API retries
Microsoft described three distinct request sequences. In each, an initial request returned HTTP 400; a modified request later returned HTTP 200.
| Request | Approximate interval before retry | Initial result | Modified retry |
| Key Vault metadata | 28 seconds | HTTP 400 | HTTP 200 |
| Azure SQL firewall rule | 60 seconds | HTTP 400 | HTTP 200 |
| Application Insights query | 80 seconds | HTTP 400 | HTTP 200 |
The successful Key Vault retry used Azure Resource Manager API version 2023-07-01. The intervals belong to separate requests, not one combined sequence.
What Microsoft recommends defenders do
Microsoft recommends revoking or rotating an exposed credential immediately and reviewing its historical use. Teams should also remove application secrets, certificates or federated credentials that an attacker may have added, rotate secrets in Key Vaults reachable by affected applications, and limit service-principal permissions to what each workload needs.
For detection, Microsoft points to service-principal and non-interactive sign-in records, Azure Activity, Key Vault and Storage diagnostics, Entra audit logs, Azure DevOps audit logs and Microsoft 365 unified audit logs. It recommends examining behavior as well as fixed indicators. One suggested heuristic is to investigate an IP address authenticating to three or more service principals with a mix of successes and failures; an application requesting tokens across multiple cloud services in a short period is another behavior to review.
Microsoft identified 199.19.77[.]84 and 199.19.77[.]18 as primary sign-in sources, while noting that the second address is a Tor exit node that may be associated with unrelated activity. The suggested Conditional Access block for 199.19.77[.]84/32 requires Workload ID Premium and applies to single-tenant apps registered in the tenant. Microsoft also advises blocking the exact IP rather than its entire autonomous system number. Tokens issued before a credential is removed remain valid until they expire.
A separate exposure path: Claude Code
A different case involved local configuration files rather than agents searching public repositories for credentials. In a November 7 video, SavvyNik described Apiiro research about Claude Code's “Don't Ask Again” permission behavior: commands containing secrets could be saved in local JSON settings and later exposed when those files were committed to public GitHub repositories. SavvyNik attributed to Apiiro more than 1,100 public copies containing at least one secret, and 2,539 real secrets across around 2,000 repositories.
The Claude Code account concerns secrets saved locally and then published; Microsoft's ARTEX account concerns agents finding credentials already exposed in public repositories.
