Skip to content

Microsoft: AI agents turn leaked app secrets into access

Microsoft Threat Intelligence reported on 5 November 2026 that threat actors use "an agentic AI offensive framework" to find client secrets on GitHub and, from 28 October 2026, signed in as service principals "on dozens of associated applications across multiple tenants". Entra admins, MSPs and vendors of multitenant apps should check service principal sign-ins from the published IPs now and rotate any secret that has ever been in a repository.

Runbook card

What changes: Microsoft reports a campaign from the same IPs as the one Todyl reported on 3 November: leaked app secrets are found by an AI agent and used for service principal sign-ins, in at least one case reaching Azure Key Vault data "in five minutes".
Who: Entra and Azure admins, MSPs (multitenant and GDAP apps) and ISVs whose multitenant app credential could reach "multiple downstream tenants".
By when: now. Microsoft saw successful sign-ins "As early as October 28, 2026".
Do this: 1. Search service principal sign-ins since 28 October for the four IPs below. 2. Block 199.19.77.84/32 with Conditional Access (workload identity policy, needs Workload ID Premium, plus a user policy). 3. Rotate every client secret that has been in source code, even if it was deleted. 4. On any hit, remove the app's secrets, certificates and federated credentials and rotate what its Key Vaults hold.
Check: Entra admin center > Monitoring & health > Sign-in logs > Service principal sign-ins, filter IP address 199.19.77.84 (then the other three).
Source: Microsoft Security blog, 5 November 2026.

What Microsoft says

The post, "Threat actors use agentic AI tooling to find and abuse exposed secrets", is by Microsoft Threat Intelligence and Microsoft Security Research. The facts it states:

  • "Starting in August 2026, Microsoft observed threat actors using an agentic AI offensive framework to submit large volumes of queries to GitHub for secrets."
  • "As early as October 28, 2026, Microsoft began observing successful service principal sign-ins from the IP address 199.19.77[.]84 involving multiple application IDs", "including cases where a multitenant application credential was compromised at the source (vendor-owned application) and used to access multiple downstream tenants."
  • "In one observed case, an AI agent progressed from searching for the client secrets in GitHub to exfiltrating data from Azure Key Vault in five minutes."
  • "A similar campaign involving the same IPs addressed was also reported by Todyl." Todyl's 3 November post described an operator signing in to MSPs' Entra ID and Azure DevOps as their own workloads.
  • The post does not name a threat actor for this activity. Don't treat it as the earlier ConnectWise campaign; that one has its own brief.

The IP addresses in the post (defanged as Microsoft wrote them):

IP What Microsoft says
199.19.77[.]84 successful service principal sign-ins
199.19.77[.]18 "a Tor exit node"
65.87.223[.]26 "indications of vulnerability exploitation by embedded shell commands in a user agent and attempts to obtain App Service authentication tokens"
157.22.126[.]128 "reconnaissance operations" "targeting AI workloads"

The Conditional Access limit to know

Microsoft's containment step: "Block 199.19.77[.]84/32 as a named location in a Conditional Access policy targeting workload identities, assigned directly to service principals, and in a user-scoped block policy to cover replayed sessions." It adds: "workload identity policies require Workload ID Premium licensing and cover only single-tenant apps registered in your tenant. Block the exact IP rather than the whole ASN."

So a CA policy will not cover a vendor's multitenant app in your tenant. For those, the controls are the vendor's secret hygiene, your consent and permission reviews, and disabling the service principal if it is abused.

How to check

Read-only. In the Entra admin center: Monitoring & health > Sign-in logs > Service principal sign-ins, date range from 28 October 2026, filter on each of the four IPs. In Microsoft Sentinel or Log Analytics:

// Read-only: sign-ins from the IPs in Microsoft's 5 Nov 2026 post
let iocs = dynamic(["199.19.77.84","199.19.77.18","65.87.223.26","157.22.126.128"]);
union AADServicePrincipalSignInLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > datetime(2026-10-28)
| where IPAddress in (iocs)
| summarize count(), Results = make_set(ResultType) by AppId, ServicePrincipalName, IPAddress

Count failures too: a failed sign-in with a valid app ID means someone tried a secret. In Defender advanced hunting, Microsoft's post points to the EntraIdSpnSignInEvents, GraphAPIAuditEvents, CloudAppEvents, CloudAuditEvents and CloudStorageAggregatedEvents tables.

To find secrets that should be rotated, list apps with client secrets (read-only, Microsoft Graph PowerShell):

Get-MgApplication -All -Property AppId,DisplayName,PasswordCredentials |
  Where-Object { $_.PasswordCredentials.Count -gt 0 } |
  Select-Object DisplayName, AppId, @{n='Secrets';e={$_.PasswordCredentials.Count}}

If you find something

From Microsoft's post: "For any affected application, remove all client secrets, certificates and federated credentials, including those added by the threat actor and disable the service principal if needed. Tokens already issued remain valid until expiry." Then "Rotate everything stored in any Key Vault the affected application could read". Microsoft also says to "Treat credentials that have been publicly exposed as compromised, even if the original location has subsequently been edited or deleted", to apply least privilege to service principals, and to restrict who can register applications.

How to verify

After the block, rerun the sign-in query for 199.19.77.84: new attempts should show as failures blocked by Conditional Access. After rotation, confirm the old secret's key ID no longer appears in the app's credentials.

Impact and rollback

Removing secrets or disabling a service principal stops the integration that uses it until a new credential is deployed; plan the rotation with the app owner. A named-location block on one /32 address has no business impact for most tenants and can be removed at any time.

Related: the Conditional Access baseline guide, the Conditional Access kit, the privileged access guide and more Identity & access news.

Sources

Last reviewed: 6 November 2026. Runbook Lab is not affiliated with Microsoft.