Three Things That Broke When Attackers Gave Their Secret-Hunting a Brain

The dominant reading of the agentic-AI-meets-secrets story is that your detection window collapsed, so you need to rotate leaked credentials faster. I think that advice is going to get people hurt, because it keeps them playing a game they’ve already lost.

Let me steelman the panic first, because it’s not stupid. Pull the attack apart and every step is something a human operator already does by hand: scrape a secret out of a public log or a misconfigured endpoint, call an Azure API to see if it’s live, enumerate what that identity can touch, find the juicy adjacent resource, establish persistence. None of it is novel. What is new is what sits between the steps, nothing. Wire that chain into a reasoning loop and the work that used to cost an analyst an afternoon of az commands and coffee now finishes in the time it takes your SIEM to batch its first ingestion. You don’t need a dated vendor report to believe the compression from hours to minutes; it falls straight out of removing the human from the loop. And if your mental model of “I’ll rotate that key next sprint” survived that realisation, you weren’t paying attention.

Here’s where I get off the bus. The entire “collapsed detection window” framing assumes the fight is about speed, their speed of exploitation versus your speed of rotation. But you cannot out-rotate an autonomous agent. It validates faster than your alert fires, pivots faster than your on-call acknowledges the page, and it doesn’t sleep through your change-freeze weekend. Betting your posture on winning a reaction-time contest against software is like trying to out-sprint a car. The only move that works is to not be on the road.

The thing being hunted has to stop existing

A long-lived secret is a bearer token for your infrastructure. Whoever holds the string is you. That property, copyable, replayable, valid until someone remembers to kill it, is exactly what makes it automatable. An agent loves a service principal client secret precisely because a secret has no context: it doesn’t care who’s presenting it, from where, or whether that caller just exfiltrated it from a Log Analytics table.

Workload Identity Federation breaks that. There is no standing credential to steal, because the trust is established at runtime from a short-lived OIDC token issued by a provider you trust, GitHub, Azure DevOps, or any external OIDC issuer, and exchanged for an Entra token scoped to one identity. The agent can scrape your entire pipeline config and find nothing to replay. You didn’t make the secret harder to find. You deleted the category.

This is the part the “rotate faster” crowd skips, and it’s the only part with real leverage. Every federated identity you stand up removes an attack surface that can’t be automated away, because there’s nothing durable sitting in a variable waiting to be discovered.

The worked example: a GitHub deploy that an agent can’t loot

The classic sin is a service principal client secret stored as a GitHub Actions secret for deployments. Delete it. Federate instead. First, the federated credential on a user-assigned managed identity, in Bicep:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

resource uami 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
  name: 'uami-deploy-prod'
  location: location
}
​
resource fic 'Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials@2023-01-31' = {
  parent: uami
  name: 'gh-main-branch'
  properties: {
    issuer: 'https://token.actions.githubusercontent.com'
    // Scope the subject tightly. Branch, not wildcard.
    subject: 'repo:contoso/platform:ref:refs/heads/main'
    audiences: [ 'api://AzureADTokenExchange' ]
  }
}

Or the same intent in Terraform against an app registration, if that’s your model:

1
2
3
4
5
6
7

resource "azuread_application_federated_identity_credential" "gh_main" {
  application_id = azuread_application.deploy.id
  display_name   = "gh-main-branch"
  issuer         = "https://token.actions.githubusercontent.com"
  audiences      = ["api://AzureADTokenExchange"]
  subject        = "repo:contoso/platform:ref:refs/heads/main"
}

The subject is where people get lazy and where blast radius lives. repo:contoso/platform:* means any branch, any PR from a fork, any workflow can assume this identity. Pin it to the branch or the environment. A federated identity scoped to a wildcard is just a long-lived secret that takes one extra hop to abuse.

What breaks, and in what order

So, three things that actually broke when attackers gave their tooling a brain, and none of them is “rotation got slower.”

One: your mean-time-to-remediate stopped being a sprint metric. The window between exposure and exploitation is now plausibly shorter than most organisations’ time-to-acknowledge. That doesn’t mean rotate faster. It means the secrets that still exist need to be the ones you’ve consciously decided to keep, each with soft-delete and purge protection on so a compromise-and-delete can’t be permanent. If you’re running Key Vault without purge protection in 2026, fix that before you read further. Purge protection is one-way by design, once it’s on you cannot turn it off, and an attacker can’t either, which is the entire point. Enable it deliberately, not reflexively:

1
2
3
4
5

# Inventory vaults missing purge protection
az keyvault list --query "[?properties.enablePurgeProtection != \`true\`].{name:name, rg:resourceGroup}" -o table
​
# Enable it (irreversible, by design). Soft-delete is already on by default.
az keyvault update --name kv-prod-01 --enable-purge-protection true

Two: detection shifted from “was it leaked” to “is someone validating it right now.” Defender for Cloud’s secret scanning still earns its keep for finding plaintext secrets in code, VM disks, and IaC, turn it on, it’s table stakes. But the agentic behaviour has a different signature: rapid, sequential enumeration. A legitimate app gets one secret it already knows the name of. An agent lists everything and tries doors. Hunt for the fan-out in your Key Vault audit logs:

1
2
3
4
5
6
7
8
9

AzureDiagnostics
| where ResourceType == "VAULTS" and Category == "AuditEvent"
| where OperationName in ("SecretGet", "SecretList", "KeyList", "CertificateList")
| summarize ops = count(),
            distinctSecrets = dcount(id_s),
            listOps = countif(OperationName endswith "List")
          by CallerIPAddress, identity_claim_oid_g, bin(TimeGenerated, 5m)
| where listOps > 0 and distinctSecrets > 10
| order by distinctSecrets desc

Pair it with a Sentinel analytics rule watching for the validation step, the same credential or IP probing resource providers across multiple subscriptions in a tight window. Enumeration across subscription boundaries from one identity is not a thing your workloads do. It’s an attacker mapping its blast radius, whether a human is typing or not.

Three: secret sprawl became a liability you can measure in minutes. Every connection string in an App Configuration store, every storage account key in an environment variable, every SAS token pasted into a runbook is now a node in a graph something will traverse automatically. Stop the sprawl at admission with Policy, deny storage keys where identity-based access will do, and keep auditing for the stragglers:

1
2
3
4
5
6

# Built-in: disallow storage account key access, force Entra auth
az policy assignment create \
  --name 'deny-storage-shared-key' \
  --policy '8c6a50c6-9ffd-4ae7-986f-5fa6111f9a54' \
  --scope '/subscriptions/00000000-0000-0000-0000-000000000000' \
  --params '{"effect":{"value":"Deny"}}'

Run it as Audit first, read the non-compliance report, then flip to Deny once you know what you’ll break. Flipping it blind on a Friday is its own incident.

Concede the obvious: you can’t federate everything tomorrow. Third-party SaaS that only speaks API keys, legacy systems, the storage account that six teams depend on, those secrets stay, and for them, faster rotation and tighter detection are exactly right. The panic crowd isn’t wrong about the residue. They’re wrong about treating the residue as the whole problem.

The agents didn’t invent a new attack. They removed the human bottleneck from an old one, which means every long-lived secret you were tolerating because “nobody’s gotten around to abusing it yet” just lost its last line of defence. The deadline isn’t your rotation SLA. It’s how many secrets you can delete before something with a reasoning loop finds the ones you kept.