Agentic AI framework used to exploit exposed credentials in cloud environments

Threat actors are using an agentic AI framework called ARTEX to locate exposed secrets in public GitHub repositories and, in some cases, use them to access cloud resources, Microsoft Threat Intelligence reports. The activity illustrates how automation can compress credential discovery and follow-on cloud operations into minutes, increasing the importance of secret scanning, credential rotation and behavioral monitoring.

Microsoft said it observed the framework submitting large volumes of GitHub queries beginning in August 2026. Searches combined organization names with terms associated with secrets, cloud services or other AI providers. The exposed material included credentials, application secrets and API keys used with AI inference services. In one observed case, an agent moved from searching GitHub to exfiltrating data from Azure Key Vault in five minutes.

From exposed secrets to cloud access

Microsoft described ARTEX as more than a high-volume search tool: agents can also analyze findings and conduct follow-on activity, reducing the need for continuous hands-on operation. The company observed the misuse of valid application credentials to sign in to Microsoft Entra ID tenants and reach connected Azure and Microsoft 365 resources.

In activity observed as early as October 28, 2026, service-principal sign-ins came from 199.19.77[.]84 and 199.19.77[.]18. Microsoft noted that the latter address is a Tor exit node and may be associated with unrelated activity. The activity involved multiple application IDs and tenants. In some cases, credentials for a multitenant application were compromised at the vendor, creating potential access across downstream customer tenants.

After authentication, the actors enumerated cloud subscriptions, resource groups, permissions, AI model deployments and service configurations. They sought sensitive information such as storage account keys, App Service settings, connection strings, publishing credentials, AI and machine-learning connections, and Azure Kubernetes Service user credentials. Microsoft also observed access to SharePoint and OneDrive, including file downloads and mailbox-item access, as well as searches through Microsoft Graph.

Some compromised applications were used to access Azure Key Vault and Storage accounts, Azure DevOps, and Azure AI services. Microsoft also saw use of Azure virtual-machine Run Command functionality. Such access can expose stored credentials or data and create opportunities to compromise associated workload identities. The company said activity against AI resources appeared consistent with attempts to validate or potentially abuse those resources.

Behavioral signals for security teams

Microsoft observed sequences in which failed cloud API requests were followed shortly afterward by successful retries using different methods or supported API versions. The pattern included requests to Azure Resource Manager, Key Vault-related resources, SQL firewall rules and Application Insights endpoints. Rapid retries that adjust request parameters can be a useful hunting signal, particularly when paired with unusual service-principal sign-ins and requests spanning several cloud services.

Network indicators alone may not provide durable protection: Microsoft cautioned that operators can change IP addresses, user-agent strings and other fingerprints. The company recommended looking for behavior, including one address authenticating to several service principals with mixed success, or an application requesting tokens for services such as Azure Resource Manager, Key Vault, Storage and Graph within a short period. Relevant evidence may be spread across Entra sign-in and audit logs, Azure Activity logs, Key Vault and Storage diagnostics, Azure DevOps auditing, and Microsoft 365 unified audit logs.

Microsoft identified 65.87.223[.]26 in malicious operations that included indications of exploitation through shell commands embedded in a user agent and attempts to obtain App Service authentication tokens. It separately reported reconnaissance against Azure AI workloads from 157.22.126[.]128. These addresses are investigation leads, not a substitute for checking identity and resource activity across the environment.

Containment and prevention priorities

• Scan public repositories for exposed secrets, including repositories the organization does not own where platform monitoring is available. Remove disclosures, but treat the credentials as compromised: editing or deleting code does not invalidate a secret.
• Revoke or rotate exposed credentials promptly, and assess what the associated application could access. Rotate secrets stored in any Key Vault the application could read, along with credentials found in accessed documents.
• Review service-principal permissions and apply least privilege. Restrict who can register applications, manage application credentials or assign permissions, and consider disabling an affected service principal during investigation.
• Prefer managed identities or other supported approaches that avoid long-lived application secrets. Use secret-scanning and push-protection capabilities to catch supported credentials before they enter repositories.
• Enable relevant cloud workload protections and audit logging, and monitor changes to applications, permissions, pipelines, recovery resources and credentials.

For Microsoft Sentinel and other security analytics teams, the incident reinforces the value of correlating identity events with cloud control-plane and data-access logs. Detection should focus not only on known infrastructure but also on sequences: credential-related failures followed by success, rapid cross-service enumeration, and secret reads or downloads after an unusual application sign-in. Organizations that find a public secret should investigate its historical use and rotate it even if the repository content has already been removed.