Agentic AI Attacks Turn Leaked GitHub Secrets Into Breaches

Estimated reading time: 8 minutes · Last updated: 6 November 2026

Agentic AI attacks are making an old, slow technique fast. Microsoft Threat Intelligence says threat actors have used an AI offensive framework, with tooling such as ARTEX, to search public GitHub repositories for leaked credentials, cloud keys and AI service API keys, then let the agents act on whatever they find. In one case the team tracked, an agent moved from a GitHub search to pulling data out of Azure Key Vault in five minutes. The searches began in August 2026. A follow-on campaign using stolen application credentials, seen from 28 October 2026, reached Entra ID tenants, SharePoint, OneDrive and Azure AI resources. For defenders the lesson is blunt: a secret pushed to a public repository should be treated as already stolen.

Why Leaked Secrets Now Get Used in Minutes

Hunting public code for passwords and keys is not new. What held it back was human effort: somebody had to locate repositories, read through them and work out how to use any credential that turned up. The team says agentic frameworks strip out most of that labour. The agents scan many repositories quickly, interpret the results themselves and launch the next stage, so the operator rarely needs to touch a keyboard.

Agentic AI means software that plans and carries out multi-step tasks on its own instead of waiting for a person to issue each command. Starting in August 2026, the team saw such a framework fire large volumes of searches at GitHub. A typical query paired a target organisation's name with secret-related keywords, plus a term tied to a cloud service or another AI provider.

Speed matters because the exposure does not end when the file is fixed. The team notes that a published credential keeps working until it is revoked or rotated, and copies can survive in edit history, caches, archives and logs. Deleting the commit is not a fix.

How Stolen App Credentials Opened Entra ID Tenants

From 28 October 2026, the team recorded successful service principal sign-ins mainly from 199.19.77[.]84 and 199.19.77[.]18, the second being a Tor exit node that may also carry unrelated traffic. A service principal is the identity an application uses to authenticate, giving it programmatic access to whatever the app is permitted to reach. The agent signed in as dozens of applications across multiple tenants, and in some cases a multitenant credential stolen from a vendor-owned app opened several downstream customer tenants.

Inside, the actor chased operations that hand back more credentials: connection strings, storage account keys, publishing credentials, App Service settings, AI and machine learning datastores, and Azure Kubernetes Service user credentials. Compromised apps downloaded SharePoint and OneDrive files, touched mailbox items and ran Graph searches for useful content.

The team tied two more addresses to the campaign with less certainty. Traffic from 65.87.223[.]26 carried shell commands hidden in a user agent and tried to obtain App Service tokens, while 157.22.126[.]128 probed AI workloads on Azure AI services. Todyl separately reported a similar campaign involving the same IPs.

An Agent That Debugs Its Own Failed Requests

One detail separates this from a scripted attack. On a victim's Azure Resource Manager instance, the control plane through which Azure resources are created and managed, the team watched the agent fail, adjust and try again.

A batch of calls listing secret metadata across several Key Vaults returned HTTP 400 because they used a data-plane API version against the control plane. About 28 seconds later the same paths were retried with API version 1 July 2023 and returned HTTP 200. A request for an Azure SQL server's firewall rules failed on an outdated version and worked about 60 seconds later, with only the api-version parameter changed. An Application Insights query recovered the same way roughly 80 seconds after its error.

That is what a junior engineer reading error messages would do, squeezed into seconds. It is also why the threat intelligence team treats fixed indicators as weak protection: the actors can change IP addresses, user agents and other fingerprints whenever they like.

Why AI Service Keys Were a Priority Target

In several cases the same tools got hold of a token for a single-tenant OAuth app inside the target organisation and used it to enumerate other cloud resources. Some agents took secrets from Azure Key Vault and searched Azure DevOps for more. Others invoked Run Command, the Azure feature that executes scripts on virtual machines, which the team warns can expose stored credentials and give an attacker persistence or lateral movement.

Throughout, the agents showed a marked appetite for keys that unlock AI services: API keys for major AI providers and OAuth apps that can reach Foundry Tools, previously named Azure Cognitive Services. The team says the actor appeared to test stolen Azure AI resources and may have tried to use them to support the wider operation.

The team also points to multiple public reports of attackers seizing AI credentials, sometimes to run the same agentic workflow. That loop is the worrying part: one stolen key can pay for the compute behind the next round of scanning.

What Microsoft Tells Defenders to Do First

Containment starts with the confirmed address. The team advises adding 199.19.77[.]84/32 to Conditional Access as a blocked named location, in a policy for workload identities and a user-scoped one for replayed sessions, blocking that exact IP rather than the whole ASN, the address block run by one network operator. That control requires a Workload ID Premium licence and only applies to single-tenant applications registered in the organisation's own tenant. Affected apps should lose every client secret, certificate and federated credential, and anything in a Key Vault they could read should be rotated.

For hunting, sign-in error AADSTS7000215 signals an invalid secret and AADSTS7000222 an expired one; either means somebody holds a credential for the app, and a failure followed by success is urgent. The team also suggests watching for a single address signing in as three or more service principals, some attempts failing.

ARTEX defaults include headless Chromium driven by Playwright, Nmap, wget, curl, Norma SDK WebFetch and Python HTTP clients, whose default user agents can tip defenders off. The team says honeypots, tarpits and fake wins reduced traffic reaching real assets in its own testing.

Where defenders gain and lose ground

The bottom line

The campaign the team describes needs no new vulnerability. It feeds on secrets developers leave in code, often to get an OAuth app working quickly, and on agents that exploit them faster than most security teams can notice. Its advice, to scan repositories, rotate anything exposed and replace client secrets with managed identities, is familiar. What has changed is the window. When a leaked key can become a Key Vault breach in five minutes, rotation after discovery is damage control rather than prevention. Two questions stay open: the team has not attributed the 28 October sign-ins to a named group, and it describes two of the related addresses as only potentially tied to the campaign.

What to watch

• Watch for Microsoft or Todyl to attribute the 28 October sign-in activity to a named group; no date has been given.
• Watch for updates to Microsoft's threat analytics reports in the Defender portal on whether 65.87.223[.]26 and 157.22.126[.]128 are confirmed as part of the campaign; no timetable has been set.
• Watch for further reports of stolen AI service keys being used to run agentic attack tooling; no date has been set.