An AI agent went from searching GitHub for secrets to pulling data out of an Azure Key Vault in five minutes, and Microsoft watched it happen. That number is not a vulnerability report — it is a budget, and every secret-leak runbook written for a human adversary now exceeds it before the first human reads the alert.
What Microsoft reported
On 5 November 2026, Microsoft Threat Intelligence published an account of threat actors using an agentic offensive framework called ARTEX to find and abuse secrets left in public code. The framework drives ordinary tooling — Nmap, curl, wget, Python HTTP clients, a fetch tool, and headless Chromium through Playwright — and analyses what comes back well enough to pick its own next step with, in Microsoft's words, limited human intervention.
| Element | What Microsoft reports | Why it matters |
|---|---|---|
| Framework | ARTEX, an agentic offensive framework over commodity tools | No novel exploit; the novelty is the loop |
| Reconnaissance | Queries to GitHub for secrets observed from August 2026 | The search half has been running for months |
| First use | Successful service-principal sign-ins as early as 28 October 2026 | Discovery and use are now one pipeline |
| Fastest observed | GitHub search to Key Vault exfiltration in five minutes | This is the number your runbook competes with |
| Reach | Key Vaults, storage keys, App Service settings and publishing credentials, ML datastores, AKS user credentials, VM Run Command, Microsoft 365 through Graph | One app secret enumerates the tenant |
| Spread | Dozens of associated applications across multiple tenants; vendor multitenant credentials used to reach downstream customers | Your exposure includes your suppliers' |
One sentence in the post carries more weight than the five minutes does: “Removing the content does not invalidate the credential.” That is not a new fact about git — it has always been true that deleting a file leaves the token alive — but it is the hinge on which the whole timing argument turns, because the remediation most teams actually perform first is the one that does nothing.
Why five minutes retires detect-and-rotate
Put the two sequences side by side and the problem is structural rather than operational. A credential-exposure response has four serial stages, and three of them require a human: something notices, somebody confirms the finding is a live secret rather than one of the day's false positives, somebody locates the system that owns it, and somebody rotates it without breaking the consumers that read it at start-up. Teams that measure this honestly report hours for the good cases. Nobody reports five minutes, because no part of that chain is designed to run unattended — confirming and rotating are exactly the steps organisations deliberately gate behind review.
So the arithmetic is not close, and it does not become close by trying harder. Halving your detection latency against a five-minute loop changes the outcome in approximately none of the cases, because the agent has finished before your first stage completes. This is the same structural point as time-of-check to time-of-use, run in reverse: there, adding a reviewer widens the window an attacker can act inside. Here, adding a reviewer to the response widens the window too — and the window is already longer than the attack.
What follows is narrower than “everything is broken”. Detection is still worth having; it is what tells you the scope of an incident that already happened, and scope is what you need for incident response and for notifying the customers downstream. What it is no longer is a control. A control changes whether the bad outcome occurs. Detect-and-rotate, against a five-minute adversary, changes only how quickly you learn what you lost.
Microsoft's own list splits in two
The remediation guidance in the post is long, and it is worth reading as two lists rather than one. Several items — scan the repositories, remove the secrets from code, rotate or revoke exposed keys immediately, treat publicly exposed credentials as compromised — sit inside the race and depend on winning it. Several others do not run against the attacker's clock at all:
- Migrate OAuth applications away from secret-based authentication to managed identities. This is the only measure on the list that removes the asset. There is no string to commit, so the five minutes never start. It is also the hardest item, which is why it is usually last in a programme and first in a post-mortem.
- Enable push protection. A gate in front of the write means the secret is not in a public repository to be found. It is prevention with no detection step, and GitHub ships it free on public repositories — the exact population ARTEX was querying.
- Block the attacker's address in Conditional Access for workload identities. Narrow and reactive, but it is a property of the token's usability rather than of your reaction speed: a credential that only works from a known path is worth less to whoever holds it.
- Consider honeypots, decoys and tarpits to divert autonomous agents. Microsoft's phrasing is the tell — autonomous. A human operator weighs whether a juicy-looking key is bait. A loop that advances on whatever the last tool call returned does not, and its speed becomes the signal: nothing legitimate reaches a decoy credential, and nothing human reaches it eleven seconds after finding it. This is the deception argument in honeytokens for agent systems, and this report is the first large vendor account that recommends it specifically because the adversary is automated.
Read that way, the finding is less about AI than it sounds. The agent did not invent a technique. It removed the slack that every detect-and-respond programme was quietly spending — and the controls that survive are the ones whose effectiveness was never a function of how fast you noticed.
The retry gaps are the second finding
Buried in the report's behavioural detail is something more uncomfortable than the headline. Microsoft describes adaptive troubleshooting with retry gaps of roughly 28, 60 and 80 seconds — the agent hit an error, waited, changed its approach and tried again.
That retires a defence nobody writes down but everybody relies on: partial misconfiguration. A great deal of real-world safety comes from the attacker giving up. The key had the wrong audience, the role was scoped oddly, the endpoint 403'd on the first shape of the request — and the intruder moved to an easier target, because their time is expensive. An agent's time is not expensive. It reads the error, reformulates, and the awkwardness that used to function as a deterrent becomes a minute of latency.
The practical consequence is a change in what counts as a finding. “This service principal has broad permissions but the credential is hard to use correctly” was, in practice, treated as low severity. It is now just broad permissions. Scoping that actually denies — a role that cannot read the vault, not one that makes reading it fiddly — is the only version that holds, and the same inversion appears in escalation under refusal: a refusal is a token in a loop, not a stopping condition.
What one app secret reaches
The resource list in the report is the part to show an executive, because it is the blast-radius argument with specifics attached. From a service-principal sign-in, the agents were observed going after Key Vaults and storage accounts; storage account keys, App Service settings, connection strings and publishing credentials; AI and machine-learning connections and datastores; AKS user credentials; Azure SQL firewall rules; virtual machines via Run Command; and Microsoft 365 content — SharePoint, OneDrive, mailboxes — through Graph.
Two of those deserve naming separately. Run Command turns a control-plane credential into code execution on a VM, which is the step where a read-only incident becomes a persistence incident. And connection strings in App Service settings are the canonical second-order leak: the thing the vault was protecting is often sitting in plain configuration next to it, which is why “rotate the Key Vault contents the apps could read” appears in the guidance and why rotation scope is nearly always underestimated. The structural version of this is in blast radius, and the audit that finds it before an attacker does is an access review of agent credentials.
The multitenant note is the one to carry to your vendors: Microsoft observed compromised vendor-owned multitenant application credentials being used to reach downstream customer tenants. If you have granted admin consent to a third-party application, your exposure is their secret hygiene, on their clock, with no signal on your side except sign-in logs you probably are not reading for service principals.
What to change this week
Ranked by how much of the five minutes each one takes away:
- Turn on push protection everywhere it is free or already paid for. It is the only item here that can be done in an afternoon and prevents rather than detects. The trade-offs between the gates and the scanners — and the bypasses every one of them documents — are the subject of our comparison of the four tools teams actually deploy.
- Count your long-lived application secrets, then set a date for the count to reach zero. Workload identity federation and managed identities are a migration, not a setting, and the programme takes quarters. Starting it is the only item on the list that removes the asset instead of shortening the fuse; the argument for short lifetimes over careful handling is in credential lifetime.
- Plant one honeytoken per environment and alert on first use. An unattached credential in a plausible location costs nothing and is the cheapest detector you will ever deploy against an adversary whose distinguishing feature is that it does not pause to think.
- Re-grade every “broad permissions, awkward to exploit” finding. The second half of that sentence no longer carries weight.
- Read your service-principal sign-in logs. Not as a control — as the thing that tells you the scope when the control failed, which is the job detection still has. Detecting agent compromise covers what to look for.
None of this is new advice. What is new is the ordering, and that the ordering is now forced: the measures that depend on your reaction time have been priced out of the market by an adversary that finished before you were paged.
FAQ
Does this mean secret scanning is pointless?
No — it means scanning is an inventory and incident-scoping tool rather than a control. You still need to know which secrets were exposed and for how long, because that determines what you tell customers. Just do not expect finding a secret to be the thing that prevents its use.
Is five minutes typical, or a worst case?
Microsoft presents it as one observed case — “in at least one case” — not a median. Treat it as a demonstrated lower bound on what the tooling can do, which is the number a control has to beat, rather than an average you can plan around.
Does rotating the exposed key finish the job?
Rarely. The guidance in the report also says to remove client secrets and certificates from affected applications and to rotate the Key Vault contents those applications could read, because anything the compromised identity could fetch during its window should be assumed fetched. Rotation scope follows reachability, not the single leaked string.
Was a specific threat actor named?
Not in this post. It describes the tooling and the behaviour without attributing the activity to a named group, which is the right level of confidence for defenders to act on anyway — the controls that work do not depend on who is holding the framework.
Would push protection have stopped this?
For the leaks it catches, yes, by construction: a secret that never reaches a public repository cannot be found in one. But every gate has documented exceptions — size thresholds, bypass options, pattern coverage — so the honest claim is that push protection removes a large, well-understood fraction of the exposure and leaves a residue you should monitor rather than assume away.
Further reading
On this wiki:
- Secrets management for agents — the reference-never-value rule and why a better vault is not the fix.
- Credential lifetime — why the time a credential stays valid dominates how carefully it is handled.
- Honeytokens for agent systems — deception as a detector when the adversary does not pause.
- Attacker-operated agents — the threat model this report instantiates.
- Secret-scanning and rotation agents — building the defensive side of the same loop.
Sources:
- Microsoft Threat Intelligence, “Threat actors use agentic AI tooling to find and abuse exposed secrets” (5 November 2026)
- GitHub Advanced Security plans — push protection availability on public repositories