Microsoft just patched an Azure Automation flaw that, left alone, would have let an attacker in one tenant reach into another tenant’s identity, credentials, and cloud workloads. Not through a zero-day. Not through a phishing kit. Through a setting that shipped public by default and a chain of code flaws nobody had reason to suspect until someone went looking. That’s the story cybersecurity teams running anything in a shared cloud platform need to sit with this week, because the setting that failed wasn’t obscure. It was the one everybody assumed somebody else had already checked.

A Public Default Opened The Door Between Tenants

Azure Automation is the kind of service that gets set up once and forgotten. Runbooks execute in the background, automation accounts hold credentials, and the whole point is that nobody has to babysit it. That’s also exactly why the flaw mattered. Researchers found that a default configuration in the service was effectively public-by-default, and when chained with a series of code flaws, it opened a path for an attacker to seize another tenant’s identity entirely, and from there, reach that tenant’s data, credentials, and cloud workloads.

Cross-tenant identity takeover is about as bad as cloud security bugs get. It skips past the usual perimeter entirely. You can have a locked-down firewall, brute-force protections tuned to the millisecond, and threat detection watching every login, and none of it matters if the platform underneath your tenant boundary was never actually enforcing that boundary in the first place.

Microsoft addressed “a public-by-default configuration and chain of code flaws in Azure Automation that could have let attackers seize another tenant’s identity and access others’ data, credentials, and cloud workloads.”

Microsoft fixed it before anyone reported active exploitation, which is the best possible ending for a bug like this. But “fixed before exploitation” is a description of luck and researcher timing, not of a system that was designed to prevent this outcome. The setting existed as a default for however long the service has been generally available. Every tenant using it inherited the exposure without opting into anything.

Why Cybersecurity Programs Keep Trusting Cloud Defaults They Shouldn’t

There’s an uncomfortable pattern underneath this bug, and it shows up in more than just Azure. Cloud platforms ship with defaults optimized for adoption, not isolation. A setting that’s open by default gets more customers running automation successfully on day one. A setting that’s locked down by default generates support tickets and slows onboarding. Vendors know which one wins internal arguments.

That tradeoff gets defended as reasonable right up until a researcher demonstrates that “open by default” meant “one tenant’s automation account could be leveraged to reach another’s identity.” At that point the calculus changes, but only for the vendor. For the customer, the exposure was live the entire time the shared responsibility model assumed multi-tenant isolation was the platform’s job, full stop.

It’s worth putting this next to where the money is actually flowing in cyber security right now. AegisAI just raised $36 million for AI-powered email security, bringing its total to $49 million. That’s real capital chasing phishing detection at the inbox, and inbox threats are genuinely worth funding. But no amount of email filtering catches a platform-level identity boundary that was never enforced. Defense in depth is supposed to mean layered controls that don’t all fail the same way. A cross-tenant identity gap in the automation layer fails underneath every layer you’ve built on top of it, including the expensive AI-driven ones.

What Actually Closes This Gap On Your End

You can’t audit a SaaS provider’s source code, and you shouldn’t have to. What you can control is how much you trust default configurations in any service that touches identity, automation, or credential storage, and how fast you’d know if that trust turned out to be misplaced.

• Inventory every automation account, service principal, and managed identity in your tenant, and confirm none of them have broader scope than the specific runbook or task requires.
• Turn off or restrict any “public” or “shared” networking option on automation, orchestration, or scheduling services unless you have a documented reason it needs to stay open.
• Apply security hardening baselines to cloud automation services the same way you’d harden a server: least privilege by default, not convenience by default.
• Build incident response runbooks that specifically cover identity provider compromise and cross-tenant exposure, not just endpoint or network intrusion, since your existing playbook probably assumes the tenant boundary holds.
• Enable and actually review threat detection alerts tied to automation account activity, credential retrieval, and unusual cross-resource access, since this is exactly the telemetry that would surface an attack like this one.
• Subscribe to your cloud provider’s security advisory feed and treat “default configuration changed” notices as action items, not changelog noise.

None of this requires new tooling or a bigger budget. It requires someone on your team treating “that’s just how the platform ships” as a question instead of an answer. The Azure Automation fix means this specific hole is closed. It doesn’t mean the next shared service you’re relying on doesn’t have one just like it, quietly public by default, waiting for someone to notice before an attacker does.

Sources

• Default Azure Automation Setting Enables Cross-Tenant Identity Takeover
• AegisAI Raises $36 Million for AI-Powered Email Security